¿Qué piensan los desarrolladores de Java de Scala? [cerrado]


19

He notado que la compatibilidad con IDE no es tan buena, pero el lenguaje en sí admite expresiones de programación funcional mucho más limpiamente.


3
Python es mi religión, así que solo me importa lo que Guido piense de Scala. neopythonic.blogspot.com/2008/11/scala.html
Trabajo

77
Scala es un lenguaje tan bueno que no solo atrae a todas estas grandes mentes que tiene la comunidad de Scala, sino que lamentablemente también a muchos enemigos envidiosos que intentan encontrar básicamente cualquier cosa para atacar el idioma y las personas que lo usan.
soc

@soc: Solo para que quede claro: no odio a Scala, y las personas que lo usan probablemente no podrían (¡no deberían!) preocuparse menos por lo que pienso al respecto. Creo que es muy complejo. Eso es todo. La complejidad puede estar bien para aquellos que tienen un cerebro grande. Yo no :-)
Joonas Pulakka

3
Lo siento, me molesta cuando la gente sigue repitiendo mitos sin respaldar sus afirmaciones.
soc

2
@soc: Bueno, toda esta pregunta es completamente subjetiva, por lo que cualquier respuesta es correcta, ya sea mito o no.
Joonas Pulakka

Respuestas:


18

He estado programando Scala durante más de un año, así que intentaré retrasarme un año para responder esta pregunta.

  • El código Scala es más conciso que el código Java (sin setter ni getter, se puede inferir mucha información de tipo)
  • El soporte incorporado para el literal XML es muy atractivo.
  • La compatibilidad e interoperabilidad de la biblioteca Java es excelente
  • El soporte para ciertas expresiones idiomáticas funcionales es refrescante (para comprensión, cierre, funciones lambda, mapear, plegar, reducir)
  • No parece haber una característica interesante que el creador del lenguaje no quisiera incluir

Los puntos anteriores eran más o menos lo que pensaba de Scala antes de comenzar a aprenderlo.

En el transcurso de un año, esto es lo que descubrí:

  • Comprar el libro de la escalera fue una gran inversión y me ha ahorrado horas de aprender cosas por mi cuenta.
  • La sintaxis tiene algunas peculiaridades y, a veces, me intrigaba por qué algo no era válido. La compensación es que una vez que esté familiarizado, el código tiene menos desorden y es más fácil de leer. Tenga en cuenta que esto no es realmente un problema si lee en lugar de escribir código.
  • La biblioteca de colección en 2.8 es un placer de usar. Es difícil volver al Java.
  • El literal XML es bueno, pero más allá de algunas cosas básicas, tuve que llegar al ecosistema de la biblioteca de Java. Sin embargo, es conveniente.
  • Usar bibliotecas Java de Scala es súper fácil y conveniente. Usar las clases Scala de Java es un poco más complicado, pero funciona.
  • Me cambié a la edición comunitaria IntelliJ IDEA y, aunque no es perfecta, es más que suficiente.
  • El creador del lenguaje realmente pensó en el conjunto de características y todo funciona muy bien juntos. El soporte orientado a objetos es mejor que en Java (con los rasgos) y puede hacer programación funcional.
  • Es un lenguaje que aparentemente algunos desarrolladores de Java odian con pasión. Para mí, ha traído de vuelta la alegría de la programación.

21

Bueno, creo que Scala es demasiado complejo. Se siente como C ++ en el sentido de que tiene una gran variedad de formas diferentes de hacer las cosas. Algunos llamarían a esto "riqueza", "expresividad" o "poder", pero su kilometraje puede variar. En muchos proyectos del mundo real, tendrías que limitar artificialmente qué características del lenguaje vas a usar y qué no, para que todos los desarrolladores involucrados puedan hablar el mismo subconjunto del idioma.

Para la programación funcional, prefiero Clojure , que es mucho más simple que Scala.

Que comience la guerra santa ;-)


2
Si Rich Hickey se preocupara tanto por .Net como lo hace por JVM ...
Job

Sería útil que explicara un poco más sobre las cosas que considera demasiado complejas.
Richard Warburton

44
@ Richard Warburton: Los problemas de la complejidad de Scala (o, como Martin Odersky lo expresa, "la fuerza y ​​un problema de Scala: su extensibilidad") se han discutido ampliamente en muchos foros. Una de esas discusiones está aquí . No estoy diciendo que complejo == malo per se . El problema es que, si bien el 1% más brillante de los programadores puede hacer milagros con Scala, la gran mayoría simplemente no lo "entenderá", y eso es un problema para el uso en el mundo real. Es como un automóvil de Fórmula 1: la gran mayoría de las personas simplemente no podrán conducir una bestia así.
Joonas Pulakka

2
+1 Por mencionar Clojure como alternativa válida (cuando se trata de programación funcional).
Oliver Weiler

Clojure es genial, pero ¿es tan eficaz como Scala? ¿Es tan fácil refactorizar sin todo este tipeo estático? (Refactorizar Python es bastante difícil, por ejemplo, escribí refactorizaciones para él.)
9000

13

Hace aproximadamente un año, a medida que me frustraba cada vez más el futuro de los productos de mi startup si continuaba usando Java, decidí probar Scala. Ya estaba programando en JavaScript y Python en ese momento, Ruby también era una buena alternativa, pero estaba buscando un lenguaje de tipo estático, preferiblemente uno que pudiera ejecutarse en la JVM.

Realmente intenté que me gustara Scala, realmente lo hice, pero encontré que su código es completamente feo y difícil de entender. Me pregunté drásticamente que si Scala era nuestra mejor respuesta a Java, entonces seguramente estaba jodido y sentenciado a seguir trabajando con un lenguaje que no me gustaba después de todo ...

Afortunadamente, no mucho después, descubrí Fantom . Oh hombre, ¿me encantó? ¡Para mí, fue como la respuesta esplendorosa de los estadounidenses a la burocracia alemana! Se ajustaba a los requisitos que buscaba en Scala, pero con mucha más elegancia . Tenía la integración de Vim , Eclipse y Netbeans , un buen marco web , productos maduros que se ejecutan con él, una comunidad pequeña pero increíblemente útil ... ¡Escritura dinámica y estática! Me alegré!

(Podría continuar, pero esta publicación está destinada a Scala, no a Fantom, así que me detengo aquí. Mi preferencia es clara , sin embargo, hay una publicación que compara los dos. Nunca pude entender por qué Fantom recibe tan poca atención en comparación con Scala. Pero aparentemente no soy el único, si escuchas este podcast [ mp3 ] hasta el final).


9

Cuando inicialmente incursioné en Scala hace 2 años, me pareció extraño e intimidante. En algún momento descubrí que el lenguaje central es en realidad mucho más simple que Java, pero su sintaxis y semántica son tan flexibles que puede crear nuevas construcciones de lenguaje como esta, incluso sin una función de macro. Desde entonces, he cambiado completamente a Scala para todos mis proyectos Java, porque me permite escribir sin demasiado código repetitivo.

Me gusta Clojure, pero hay situaciones en las que la plataforma necesita que compiles un código de bytes estático (Android, applets, ...) y, aunque puedes hacerlo, en Scala, está ahí.

Si bien Scala le permite resolver muchos problemas de manera funcional, a menudo encuentro problemas en los que usar las clases se siente más natural. Eso hace que las cosas sean un poco más complejas, pero no se acerca a las complejidades y dolores de C ++.

Lo más importante para mí cuando realmente comencé a aprender el lenguaje fue que podía programar lo mismo que hice en Java, solo sin el ruido (un poco como cuando comienzas Groovy), pero eventualmente quieres intentar sumergirte más profundamente en el poder del lenguaje, crece contigo.

Acerca de la pregunta IDE: Después de usar Emacs para todo, todos mis problemas IDE desaparecieron :-)


9

Me gusta Scala por muchas razones, pero hay una que a menudo se pasa por alto: su simplicidad.

Puede que Scala no sea tan simple como, por ejemplo, Oberon, pero es bastante más simple que algunos otros idiomas. La especificación del lenguaje Scala es ~ 160 páginas, la especificación del lenguaje Java es ~ 600 (¡solo el idioma, no la JVM o las bibliotecas!), La especificación del lenguaje ECMA-334 C # (que AFAIK corresponde a un subconjunto de Visual C # 2.0) es ~ 440 páginas (esto no incluye cosas como comprensiones de consultas LINQ, expresiones lambda, métodos de extensión, covarianza y contravarianza genéricas dynamic, argumentos opcionales con valores predeterminados, argumentos de palabras clave, var). Incluso el borrador actual para ECMAScript 5.1 es más grande en ~ 210 páginas. Y, por supuesto, mi propio lenguaje "predeterminado", Ruby, cuyo borrador ISO actual pesa ~ 310 páginas, que solo especifican un subconjunto casi inutilizable de la intersección de Ruby 1.8.6, 1.9.1 y 1.9.2.


66
El número de páginas en la especificación del lenguaje es una medida interesante de su complejidad. Es sorprendente cómo Scala divide las opiniones sobre esto. Nadie diría que Python es complejo, o C ++ es simple, pero Scala parece ser ambos :-) ej. Scala-lang.org/node/7431
Joonas Pulakka

Puede construir cosas complejas con el lenguaje, y algunos se verán como si fueran el lenguaje: métodos con nombres que no son alnum, que parecen una sobrecarga del operador, que no lo es, por ejemplo.
usuario desconocido

2
El número de páginas en la especificación del idioma es una forma TERRIBLE de comparar la complejidad de dos idiomas. Solo para dar dos ejemplos: la especificación de Java está escrita de manera casi tutorial, mientras que la especificación de Scala está escrita de una manera muy concisa. U otro ejemplo, C # 2.0 en realidad era más o menos tan complejo como Java hoy, o quizás un poco más complejo dada la maquinaria "insegura", los delegados y las iniciativas. Pero como notará, la especificación C # 2.0 es más pequeña que la JLS.
James Iry

1
Ahora, Martin Odersky ha comparado el tamaño de las gramáticas formales de los idiomas. Esa es una medida razonable de un aspecto de la complejidad. Pero es razonable porque las gramáticas no son tan flexibles como el inglés. Incluso entonces, debes tener cuidado. Al igual que con los programas ordinarios, puede estirar o reducir fácilmente las gramáticas con diferentes opciones sobre cómo diseñarlas, cuántas producciones distintas incluir, qué clases de personajes base asumir, etc.
James Iry

3
esperar lo ? ¿Por qué tratarías de medir la complejidad con el tamaño de la especificación? Es una idea terrible.
smartnut007

9

Esto es lo que apesta de Scala:

  • Para empezar, el puntero nulo era una muy mala idea. Hoare lo llamó su "error de mil millones de dólares", pero Scala es aún peor. Tiene objetos llamados nulo, nulo, ninguno y nulo. nulo es para la interoperabilidad con Java. Nulo es el puntero nulo de la especificación W3C DOM, Ninguno es con lo que debería haberse reemplazado nulo, y Nulo es algo vacío.

  • Cuando las construcciones del lenguaje resultan ser extravagantes, generalmente el culpable es el programador y no el lenguaje. En Scala, sin embargo, el lenguaje central ya contiene clases de biblioteca cuyo único comportamiento documentado es "Esto es un hack". No lo creo Busque el scaladoc para scala.xml.Group.

  • Por último, no menos importante, Scala está mal documentada. Casi ninguna de las clases scala en la documentación oficial viene con código de ejemplo. Scala es significativamente más difícil de aprender que Java y requiere un profundo conocimiento en informática.

Para evitar ser confundido con un enemigo de Scala, esto es lo que me encanta:

  • Tengo menos excepciones. Nunca tuve una ClassCastException y muy pocas NullPointerExceptions cuando interactuaba con Java.
  • El código es mucho más corto y conciso que Java
  • Es intelectualmente desafiante. Java se siente como un lenguaje infantil en comparación.

10
nulles el puntero nulo de Java, Nulles el "tipo" de él. Nonees un posible "estado" de Option[T], una colección con uno o cero elementos. NilEs una lista vacía. Si bien quieres que suene aterrador, no lo es. Esos tipos no son reemplazables o intercambiables entre sí y se comportan exactamente como deberían.
soc

9

Scala es complejo. ¡No hay forma de evitarlo! Su sintaxis es extremadamente flexible y se puede personalizar de muchas maneras (sobre todo operadores / notación de infijo), y el sistema de tipos tiene más características diferentes que cualquier otro idioma que conozco.

Entonces, las cosas no son tan claras como, por ejemplo, en Haskell: Clases de tipos para cubrirlas todas.

A medida que Scala intenta reunir programación funcional, OO, programación de procedimientos y bibliotecas de Java, así como ideas propias, finalmente terminamos con muchos conceptos que de alguna manera parecen ir "en la misma dirección":

  • Valores implícitos
  • Funciones implícitas
  • Existenciales
  • Comodines
  • Rasgos
  • Interfaces
  • Clases abstractas
  • Clases de casos
  • Tipos estructurales
  • Restricciones genéricas
  • Ver límites
  • Tipos anónimos

Elegir entre ellos parece difícil al principio y uno podría preguntarse fácilmente si ha encontrado la solución correcta para algún problema. Incluso es fácilmente posible producir cosas hacky mediante el abuso de implicits.

Pero lo interesante es: Scala funciona. A veces es difícil entender por qué (especialmente descubrir qué conversiones implícitas + herencia + ... algún objeto tiene funcionalidad X), pero no tiene que preocuparse por eso la mayoría de las veces.

Escriba Scala lo más sencillo posible y funcionará. No se confunda con todo lo que sea posible y solo use lo que necesita. Y si necesita algo, puede estar seguro de que de alguna manera Scala lo tiene;)

Y cuanto mejor consiga, más podrá personalizar Scala con operadores, implicaciones, mónadas, sintaxis original ... y finalmente obtendrá algo parecido a un DSL que resolverá perfectamente su problema.

Después de todo, siempre tiene la posibilidad de usar Scala como un Java mucho mejor con una sintaxis más limpia, más fácil, inferencia de tipos y algunas características funcionales.


1
"por encima de todos los operadores / notación infija", solo que la escala no tiene operadores. :) Son solo métodos.
usuario desconocido

6

Es un lenguaje excelente que es más simple que Java en muchos sentidos.

A la mayoría de la gente no le gustará, programador de Java o no, por las mismas razones que a la mayoría de las personas, programadores o no, no les gusta aprender nuevos lenguajes de programación. Sospecho que a la mayoría de las personas que aprendieron un lenguaje de programación ni siquiera les gustó aprender eso.

Si le preocupa que un lenguaje sea tan complicado como C ++, evitaría Clojure como la peste. Quejarse de que Scala es más complicado que Clojure se ha convertido en el argumento alternativo para las personas que ignoran por completo uno o ambos idiomas.

Clojure tiene macros, lo que significa que puede alterar la sintaxis del lenguaje tanto como lo desee, brindándole no solo "una miríada de formas diferentes de hacer las cosas" sino un número casi infinito de formas de hacer las cosas. Y ninguna de esta nueva sintaxis que los programadores están creando con las macros se documentará en ninguna parte de la especificación del lenguaje.

"Pero podemos evitar el uso de macros o regular cuáles están permitidos en nuestro código", dice. Felicitaciones, ahora tienes que "limitar artificialmente qué características del lenguaje vas a usar y qué no", que es exactamente lo que los idiotas que usan Clojure of Scala usaron como razón para evitar Scala.


66
Gracias por su entrada Scala vs Clojure, pero ¿es eso lo que realmente estoy preguntando sobre el OP?
Martin Wickman

Punto interesante re: macros. Ligeramente preocupante, también. ¿Hay macros o similares disponibles en Scala, o todo el "límite artificial" es una distracción?
Armand

1
Esto parece ser un comentario a mi respuesta en lugar de una respuesta a la pregunta original. Estoy de acuerdo, las macros te dan un poder infinito, por lo que cuando se usan mal, apestan. Por lo tanto, debe usarlos correctamente (solo cuando sea necesario). Esto no cambia el hecho de que Clojure el lenguaje es uno de los más simples que existen. Scala definitivamente no lo es.
Joonas Pulakka

> Esto no cambia el hecho de que Clojure el lenguaje es uno de los más simples que existen. <Esto también es completamente falso, a menos que esté usando alguna métrica como "número de construcciones de lenguaje". Si está usando algo útil, como lo fácil que es leer y escribir programas en el lenguaje, entonces Clojure no es uno de los más simples.
Josh

Así que por favor continúe y dénos una buena métrica de la complejidad del lenguaje. "Qué fácil es leer y escribir programas en el lenguaje" es totalmente subjetivo , por lo que realmente no ayuda aquí. Por supuesto, encontrar una métrica útil y objetiva puede ser prácticamente imposible. (Por ejemplo Jörg W Mittag a continuación es el uso de número de páginas en la especificación del lenguaje como una medida de complejidad Mientras objetiva, no estoy seguro de que es muy útil..)
Joonas Pulakka

4

Realmente me gustan los tipos más granulares de la biblioteca Scala. Parece que la nueva biblioteca de colecciones estaba bien pensada. También me gusta cómo reduce la cantidad de código requerida para las clases simples y los conceptos funcionales que agrega. Su inferencia de tipos también es muy útil. Se siente como Java sin las ruedas de entrenamiento. Después de usar C # por un tiempo, Scala realmente se siente como un competidor, con Java aún útil pero quedando atrás.


2

Como programador de Java, inicialmente encontré Scala interesante. Sin embargo, después de incursionar en ello por un tiempo (y encontrarme con casi todos los aspectos positivos / negativos ya mencionados por otros), me sentí muy "meh" hacia eso. Las mejoras en el lenguaje se compensan con la menor disponibilidad de conjuntos de herramientas. Simplemente no pude encontrar ninguna razón definitoria para cambiar. Es bueno, pero no es "lo suficientemente mejor" para justificar el cambio. Tampoco tiene ese factor de emoción subjetiva (como parece que Clojure).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.