java - introduccion - scala software

Scala como el nuevo Java? (8)

Más allá de aprender un nuevo idioma, ¿cuál es la desventaja de cambiar a Scala?

Pensando, pensando, pensando ..... no, no hay ninguno :-)

Empecé a explorar Scala en mi tiempo libre.

Tengo que decir que hasta ahora estoy muy impresionado. Scala se encuentra en la parte superior de la JVM, se integra perfectamente con el código Java existente y tiene muchas características que Java no tiene.

Más allá de aprender un nuevo idioma, ¿cuál es la desventaja de cambiar a Scala?

Algunas de las desventajas de Scala no están relacionadas en absoluto con la relativa juventud del idioma. Después de todo, Scala tiene aproximadamente 5 años de edad, y Java fue muy diferente 5 años en su propia vida útil.

En particular, debido a que Scala no cuenta con el respaldo de una empresa que lo considera una prioridad estratégica, los recursos de soporte son bastante escasos. Por ejemplo:

La falta de tutoriales extensos
Calidad inferior de la documentación
Localización no existente de la documentación
Bibliotecas nativas (Scala usa bibliotecas Java o .NET como base para las suyas)

Otra diferencia importante se debe a cómo vio Sun que Java y EPFL ven a Scala. Sun vio Java como un producto para obtener clientes empresariales. EPFL ve Scala como un lenguaje destinado a ser un mejor lenguaje que los existentes, en algunos aspectos particulares (integración OOxFunctional, y el diseño del sistema de tipo, en su mayoría).

Como consecuencia, cuando Sun hizo que JVM fuera estable ante las glaciaciones y Java totalmente compatible con versiones anteriores, con una desaprobación muy lenta y la eliminación de características (en realidad, ¿eliminación?), Los archivos JAR generados con una versión de Scala no funcionarán en absoluto con otras versiones (un problema grave para las bibliotecas de terceros), y el lenguaje constantemente obtiene nuevas funciones y elimina las obsoletas, al igual que la biblioteca de Scala. El historial de revisión de Scala 2.x, que creo que tiene apenas 3 años, es impresionante.

Finalmente, debido a todo lo anterior, el soporte de terceros para Scala es incipient . Pero es importante señalar que JetBrains , que gana dinero vendiendo IntelliJ IDEA IDE, ha apoyado a Scala durante bastante tiempo y sigue mejorando su soporte. Eso significa, para mí, que existe una demanda de soporte de terceros, y el soporte aumentará.

Señalo la situación del libro. Hace un año no había un libro de Scala en el mercado. En este momento hay dos o tres libros introductorios de Scala en el mercado , aproximadamente la misma cantidad de libros debería estar disponible antes de fin de año, y hay un libro sobre un marco web muy importante basado en Scala, Lift .

Seguro que veremos un libro sobre ESME no muy lejos en el futuro, así como libros sobre Scala y concurrencia. El mercado editorial aparentemente ha alcanzado el punto de inflexión. Una vez que eso sucede, las empresas lo seguirán.

Bueno, la desventaja es que debes estar preparado para que Scala sea un poco rudo en los bordes:

obtendrás el extraño error interno críptico del compilador de Scala
el soporte IDE no es tan bueno como Java (tampoco es compatible con la depuración)
habrá saltos para compatibilidad hacia atrás en lanzamientos futuros (aunque estos serán limitados)

También debe correr el riesgo de que Scala se borre como un idioma.

Dicho eso, ¡no creo que mires atrás ! Mis experiencias son positivas en general; los IDE son utilizables, te acostumbras a lo que significan los crípticos errores del compilador y, aunque tu base de código de Scala es pequeña, una ruptura de compatibilidad con versiones anteriores no es una gran molestia.

Valdrá la pena para Option , la funcionalidad de mónada de las colecciones, los cierres , el modelo de actores , los extractores, los tipos covariantes, etc. Es un lenguaje asombroso.

También es de gran beneficio personal poder abordar los problemas desde un ángulo diferente, algo que los constructos anteriores permiten y alientan.

Constantemente rompe la compatibilidad hacia atrás. El tamaño de la comunidad es pequeño. El soporte de IDE aún no está allí.

De lo contrario está bien.
Es solo un lenguaje joven, llegará eventualmente. Ideal para aficionados, no listo para la empresa.

Estaba desconectado de la correa J2EE el año pasado quería hacer algo nuevo después de 12 años de Java en el sistema de construcción de gran empresa para algunas de las compañías más grandes del mundo.

Lo había intentado con Ruby on Rails en el pasado. Después de crear algunas aplicaciones de muestra, no me gustó su sensación o el hecho de que tendría que escribir un montón de pruebas unitarias para cubrir cosas que normalmente hace un compilador.

Groovy en Grails fue mi próximo puerto de escala. Debo decir que me gusta esto, pero sufre los mismos problemas dinámicos de tipeo que ROR. No me malinterpreten. No voy a descartar Grails, ya que es un marco excelente y lo seguiré usando. Cada uno tiene su propio lugar IMO.

Luego salté sobre Scala y ahora he desarrollado una aplicación híbrida basada en Scala y Spring MVC. Al principio, trabajar con Scala es difícil, pero se vuelve más fácil y productivo cuanto más tiempo dediques a él. Llegué a un punto de inflexión en el que ahora también quiero invertir tiempo en Lift.

La combinación de los libros "Programming in Scala" y "Beginn Scala" de David Pollak es bueno para aprender el idioma, el último con una inclinación menos académica.

Scala todavía es joven y tiene mucho camino por recorrer. Creo que tiene un futuro brillante y veo que el impulso ya está mejorando. Recientemente, uno de los creadores del lenguaje Groovy dijo en una publicación de blog que nunca se habría molestado en diseñar Groovy si Scala hubiera estado presente en ese momento.

Creo que un poco más de trabajo en una mejor integración / envoltura de API Java le dará a Scala el impulso que necesita para ganar más seguidores. La integración básica ya está allí, pero creo que podría pulirse un poco más.

Sí, el soporte IDE está ahí pero es básico en este momento. El poderosa refactorización de Intellij aún no está allí y echo mucho de menos. El compilador + soporte IDE con una combinación de otros complementos aún no está maduro. A veces obtengo errores de compilador internos muy extraños causados por la forma en que Scala se sienta con la mejora de JDO para el motor de la aplicación Goggle. Sin embargo, estas son pequeñas cosas que se pueden arreglar fácilmente. La adaptación temprana de nuevas tecnologías e idiomas siempre viene con un poco de dolor. Pero este pequeño dolor puede producir un gran placer en el futuro.

Si miro las capacidades de Scala en comparación con Java a principios de sus millas por delante. Cuando pasé de C ++ a Java, la JVM aún no estaba lista para la escalabilidad. Solía haber montones de volcados de núcleo JVM de bloqueo y grabación extraños en varios sistemas operativos. Todo esto ahora se ha solucionado en Java y la JVM es sólida como una roca. Scals se ejecuta en la JVM por lo que se le ha dado una gran ventaja inicial en la integración nativa de la plataforma. ¡Está sobre los hombros de los gigantes!

Después de años de desarrollar y apoyar aplicaciones empresariales, mi voto es para un lenguaje en el que un compilador pueda detectar la mayoría de los errores no funcionales incluso antes de que se construyan las pruebas unitarias. Me encanta el tipo de control mezclado con el poder de la programación funcional. Me gusta el hecho de que estoy haciendo OO ++.

Creo que la comunidad de desarrollo decidirá si Scala es el futuro o no. La desventaja de adoptar Scala ahora sería si no adquiriera impulso y adaptación. Sería muy difícil mantener una base de código de Scala con muy pocos desarrolladores de Scala. Sin embargo, vi que Java provenía de los trabajos de Skunk en la empresa para reemplazar a C ++ y la comunidad de desarrolladores lo impulsó de abajo hacia arriba. El tiempo dirá por Scala, pero actualmente tiene mi voto.

Los dos, con lo que quiero decir cuatro, los mayores inconvenientes que veo son:

Muchos que trabajan como desarrolladores en la comunidad profesional no están capacitados y no están dispuestos a aprender a usar un lenguaje funcional, ni siquiera lo probarán para que puedan entender por qué es un mejor enfoque. Esto significa que siempre estará peleando una batalla cuesta arriba para obtener la adopción hasta que sea obligatorio a nivel corporativo.
La integración RDBMS todavía es un poco irregular. Muchas soluciones, pero nada que sobresalga como estándar. Para mí, sin embargo, esto podría ser una ventaja en lugar de una desventaja. JPA2 es un desastre y causa más problemas que problemas que soluciona. Las consultas sobre criterios de Hibernate no son mucho mejores.
El soporte de IDE todavía está rezagado, pero principalmente en el área de la depuración en este momento. La inspección del código funciona bastante bien (al menos en IntelliJ).
¡Nunca más querrá escribir otra línea de Java! Probablemente quieras golpear una pared o romper algo cuando se te obligue a volver a la incómoda sintaxis de Java.

No creo que haya inconvenientes. En realidad, aprender un nuevo idioma es muy útil para ampliar tu conocimiento de programación. Puede obtener de Scala cosas tales como clases genéricas, anotaciones de varianza, límites de tipos superior e inferior, clases internas y tipos abstractos como miembros de objetos, tipos de compuestos, auto referencias explícitamente tipadas, vistas y métodos polimórficos.

Te contaré mi pequeña experiencia personal y cómo descubrí que no era tan fácil integrar Scala con las bibliotecas existentes de Java:

Quería empezar con algo fácil, y como pensé que Scala era muy adecuado para el cálculo científico, quería hacer un pequeño resumen de JAMA (biblioteca de matriz de Java) ... Mi enfoque inicial era extender el tipo de matriz con un Escala la clase y luego sobrecarga los operadores aritméticos y llama a los métodos nativos de Java, pero:

La clase Matrix no proporciona un constructor predeterminado (sin argumentos)
La clase Scala necesita un constructor primario
Pensé que un buen constructor primario podría ser el que aceptara un Array [Array [Double]] (lo primero que apesta es que la sintaxis es mucho más prolija y difícil de leer que Double [] [])
Por lo que sé al leer los manuales, los parámetros del constructor primario también son campos implícitos de la clase, así que terminaría con una matriz [matriz [doble]] en la subclase Scala y otra doble [] [] en la Superclase Java, que es bastante redundante.

Creo que podría haber usado un constructor primario vacío que inicializó la superclase con algunos valores predeterminados (por ejemplo, un [[0]]), o simplemente crear una clase de adaptador que utilizara Jama.Matrix como delegado, pero si un idioma se supone que es elegante e integrado sin problemas con otro, ese tipo de cosas no deberían suceder.

Esos son mis dos centavos.