¿Qué partes de una aplicación Java deberían escribirse en Scala?

Question

Estoy escribiendo una aplicación Java usando Struts 2, pero ahora me gustaría hacer un proyecto híbrido Java & Scala en su lugar. No tengo mucha experiencia con Scala, pero conocí a Haskell hace años en la universidad. Me gustó mucho el paradigma funcional programado, pero por supuesto en clase solo nos daban problemas que eran supremamente adecuados para una solución funcional. En el mundo real, creo que algún código es más adecuado para un estilo imperativo, y quiero seguir usando Java para eso (sé que Scala admite la sintaxis imperativa, pero no estoy listo para ir en la dirección de un proyecto de Scala puro todavía).

En un proyecto híbrido, ¿cómo se decide qué codificar en Java y qué codificar en Scala?

Answer 1

Haga estas preguntas de su proyecto: "¿Qué operaciones necesitan efectos secundarios?" y "¿Qué funcionalidad ya está bien cubierta por las bibliotecas de Java?" Luego implementa el resto en Scala.

Sin embargo, me gustaría advertir que los proyectos híbridos son, por su propia naturaleza, más difíciles que los proyectos independientes ya que es necesario utilizar múltiples idiomas/entornos. Entonces, dado que no reclamas mucha experiencia con Scala, te recomendaría jugar primero con algunos proyectos de juguetes, quizás un subconjunto de tu objetivo completo. Eso también le dará una idea de dónde debería ocurrir la división.

Answer 2

dos cosas:

1. 99% de código Java se puede expresar de la Scala
2. Puede escribir proyectos compatibles con Java + mixta compilación Scala. Su código Scala puede llamar a su código Java y su código Java puede llamar a su código Scala. (Si desea hacer esto último, sugiero definir la interfaz en Java y luego implementarla en Scala. De lo contrario, llamar al código de Scala desde Java puede ser un poco feo.)

Así que la respuesta es: lo que sea partes que quieres Su código Scala no necesita ser puramente funcional. Su código Scala puede llamar a bibliotecas Java. Así que casi todas las partes que podrías escribir en Java también podrías escribir en Scala.

Ahora, algunas consideraciones más prácticas. Cuando intentan Scala por primera vez, algunas personas eligen partes de su programa relativamente aisladas y que no son de misión crítica para escribir en Scala. Las pruebas unitarias son un buen candidato si te gusta ese enfoque.

Si está familiarizado con Java y ha aprendido Haskell en el pasado, sugiero tratar a Scala como una "mejor Java". Fundamentalmente, Scala compila el bytecode de JVM que es muy, muy similar a lo que genera Java. La única diferencia es que Scala es más "productivo": produce más bytecode por línea de código que Java. Scala tiene muchas cosas en común con Haskell (las funciones de primera clase, las comprensiones son como la notación de Haskell, la inferencia de tipo limitado), pero también es muy diferente (no es perezoso por defecto, no es puro). Así que puedes usar algunas de tus ideas de Haskell para inspirar tu estilo Scala, pero "bajo el capó" es todo código byte de Java.

Answer 3

En el espíritu de su pregunta, le recomiendo que escriba en Scala cualquier código que implique una gran manipulación de colecciones o que maneje XML.

La biblioteca de colecciones de Scala es la principal característica funcional de Scala, y experimentará una gran reducción de LoC a través de su uso. Sí, hay alternativas de Java, como la biblioteca de colecciones de Google, pero preguntaste qué debes escribir en Scala. :-)

Scala también tiene un manejo nativo de XML.Es posible que encuentre difícil la transición si intenta tomar el código DOM y hacerlo funcionar en Scala. Pero si, en cambio, intentas abordar el problema y la perspectiva de Scala y escribirlo desde cero para Scala, obtendrás ganancias.

Aconsejo usar también actores, pero no estoy seguro de qué tan bien puede integrar eso con el código de Struts 2 en Java. Pero si tiene un código concurrente, piense en Actors in Scala.

Answer 4

Puede sonar tonto, pero ¿por qué no escribir su proyecto completo en Scala? Es un lenguaje maravilloso que es mucho más expresivo que Java al tiempo que mantiene el acceso compatible con binarios a las bibliotecas Java existentes.