it-swarm-es.com

¿Cómo anima a su organización a pasar de Java a Scala?

¿Alguna organización ha iniciado la migración de Java a Scala? Si es así, ¿cómo lo hace? ¿Qué puedo hacer para animar a mis colegas a hacer lo mismo?

15
nanda

Probablemente la forma más fácil es usar primero Scala solo para probar. En este caso, es posible que ni siquiera tenga que decirle a su jefe :-) Si él pregunta, dígale "esa es solo mi prueba privada caso, es mucho más fácil y rápido de usar Scala para él ". Una vez que usted (y su organización) tenga suficiente experiencia con Scala puede comenzar a usarlo para el código "real".

15
Thomas Mueller

Haz que tu jefe lea experiencias como esta:

  1. Actualmente estoy haciendo la mayoría de mis cosas en Scala ahora mismo. (Debo mencionar que creo que Scala es lo mejor desde la invención de la rueda hace algún tiempo. :-D)

    En mi humilde opinión, es el único lenguaje que realmente permite a las personas elegir el mejor enfoque para una tarea sin una división innecesaria entre enfoques (más) orientados a objetos y (más) funcionales.

    Al observar los lenguajes que afirmaron algo así antes, básicamente puedo ver dos campos de diseño de idiomas en competencia:

    • Los del lado orientado a objetos que vieron que la programación funcional ganó algo de tracción últimamente y pensaron "Bueno, realmente no entendemos esa cosa funcional, pero agreguemos un poco de azúcar sintáctico elegante a nuestro lenguaje, para que podamos afirmar que es funcional ¡también!" (ejemplos: Java, Python)

    • Luego, los del lado funcional, que pensaron: "Bueno, nuestro enfoque funcional es muy superior a cualquier otra cosa y esa tontería orientada a objetos es molesta, pero pongamos algunas palabras clave adicionales en nuestro lenguaje, que harán que nuestro lenguaje escape de la academia con seguridad". ! " (ejemplos: F #, OCaml)

    Los diseñadores de Scala unificaron muchos enfoques provenientes de ambos lados y crearon un lenguaje bien diseñado, que es, en mi humilde opinión, la mayor diferencia con otros lenguajes, que decidieron adoptar el enfoque "Frankenstein" para el diseño de lenguajes de programación.

  2. Habiendo hecho solo cosas más pequeñas con Lift y solo experiencia superficial con Rails y Django, tengo que admitir que la mayoría de las veces cuando me preguntaba por qué algo en Lift funcionaba de manera diferente a lo que esperaba, esto se debió al hecho de que mis expectativas eran erróneas y que el enfoque de Lift era superior.

    Ciertamente, Lift no es una "introducción fácil a Scala", pero aprender cómo funciona Lift fue casi tan gratificante como aprender Scala antes.

    La capacidad de tener una vista "limpia" sin ninguna lógica en ella es una gran mejora con respecto a otros marcos que afirmaron lo mismo, pero no lo alcanzaron. El soporte literal XML de Scala hace posible verificar que su respuesta esté bien formada: el compilador demostrará en el momento de la compilación que solo emite XML bien formado a un cliente.

  3. Lift es una tecnología viable y, en este momento, el único enfoque real si desea crear aplicaciones web que se vean, se sientan y se comporten como aplicaciones de escritorio "reales" sin escribir cantidades increíbles de código usted mismo.

[ Fuente ]

7
missingfaktor

Desde la perspectiva de las empresas, es mejor quedarse con Java si no hay una clara ventaja que obtendrán al migrar a Scala. Es más fácil para ellos contratar Java programadores para construir y mantener la aplicación. Puede irse después de implementar todo en Scala :-) Sin ofensas :-)

7
Geek

En los últimos dos años hemos progresado bastante en este viaje en guardian.co.uk: nuestra Plataforma abierta está construida en Scala, nuestro CMS central (originalmente en Java) está incorporando gradualmente más = Scala (pronto nos mudaremos de Maven a SBT para nuestra compilación) y ha sido una experiencia maravillosa - realmente vigorizante desarrolladores, algunos de los cuales estaban un poco hartos de Java :)

Te animo a leer estos dos artículos sobre nuestra transición, y tal vez los uses como evidencia de apoyo con tu pelo puntiagudo:

http://skillsmatter.com/podcast/home/how-we-moved-from-Java-to-scala

http://www.infoq.com/articles/guardian_scala

Algunos consejos rápidos:

  • Comience escribiendo sus pruebas en Scala - de esa manera puede familiarizarse con el idioma, aumentar su confianza en él y no tener que vencer los miedos que pueda tener acerca de agregar el tiempo de ejecución a su producción servidores de inmediato.

  • No pida permiso para probar nuevas tecnologías. Mejor pedir perdón si es necesario :-)

3
Roberto Tyley

Esta pregunta encaja en otra pregunta. Eso es para qué tipo de proyectos migrar a Scala proporciona valor agregado? Yo hago Java día mi trabajo diario, pero sueño con el día en que puedo usar = Scala "enfadado".

Un par de respuestas a mi propia pregunta:

  • Problemas para los que la concurrencia basada en actores proporcionaría un gran beneficio (Akka)

  • Aplicaciones web que tienen datos enviados a través de COMET (Lift)

¿Alguna otra idea o mejor aún, experiencias?

2
user3463

Estoy escribiendo pruebas para mis aplicaciones Java en Scala y estoy de acuerdo en que es un buen lugar para comenzar. Mi cobertura de pruebas es mejor porque es más rápida y fácil escribirlos (también desde que puedo usar Scala, me concentro voluntariamente en escribir más pruebas).

También comencé a hacer prototipos y POC desechables en Scala casi exclusivamente. Intento que los gerentes y supervisores sean lo más conscientes posible de que usé Scala para estos únicos y enfatizo que pude poner algo en funcionamiento rápidamente gracias a Scala. Necesitábamos (bueno, algo así como) una aplicación web para rastrear nuestro juego de elefantes blancos de fiesta navideña: 1,5 horas con Scalatra y MongoDB y mi todo el departamento está viendo esta aplicación y preguntando sobre ella. Seamos realistas, nunca llegará a ninguna parte describiendo a los gerentes cuánto más expresivo es el lenguaje o que su modelo de concurrencia es mucho mejor. Pero si les muestra, puede obtener más si lo haces más rápido, ganas terreno.

Pero creo que la pieza más importante es entusiasmar a los desarrolladores con Scala. Estoy seguro de que todos trabajamos con desarrolladores que no se mantienen al día activamente con la nueva tecnología y, a veces, es difícil entusiasmar a esa gente con hacer algo nuevo (por qué, realmente no lo entiendo). Mostrarle a esa gente algunos beneficios de Scala (pruebe el REPL) es clave. Si obtiene suficientes desarrolladores hablando sobre los mismos beneficios de productividad, entonces es mucho más probable que obtenga Scala adoptado oficialmente en su organización.

Difundir la palabra y poner en marcha ese esfuerzo de base es mi objetivo clave en 2011. Veremos cómo se resuelve, porque no puedo esperar el día en que pueda usar Scala para el volumen de mi trabajo.

1
Janx

Me pregunto por qué elegir uno u otro. ¿Por qué decidir tirar Java por la puerta e ir Scala hasta el final?)

No existe la herramienta perfecta para el trabajo. No hay razón para tirar por la puerta la experiencia en un idioma por completo y reemplazarlo por otro.

No querría trabajar (más) en una empresa que se centra en un idioma o entorno, tbh. Es mejor saber muchas cosas y elegir la herramienta adecuada para el trabajo.

Además, es difícil, si no imposible, hacer que su organización cambie a Scala por completo. En su lugar, trataría de hacer algunos proyectos (o incluso partes de proyectos) en Scala, en lugar de optar por el enfoque de todo o nada. Por ejemplo, puede optar por probar su código Java con Specs2, que tiene una sintaxis bastante agradable en comparación con el viejo JUnit simple y no es complejo, confuso y difícil Scala código y paradigmas tampoco, solo azúcar sintáctico para definir el comportamiento de su aplicación.

1
Cthulhu

Una buena forma es demostrar dos versiones del mismo programa. Al hacerlo, puede mostrar a sus colegas (en la práctica) la Expresividad de Scala. Hacer lo mismo para otros problemas (XML, concurrencia, etc.) puede demostrar los beneficios de usar Scala en lugar de Java para abordar problemas específicos.

Por supuesto, no espere que la migración ocurra en un día. Hay muchos problemas que podría subestimar: la curva de aprendizaje, el código base existente, etc.

0
sakisk