¿Cuáles son algunos de los aspectos negativos del uso de Scala?

Lo negativo que más destaca con el uso de Scala es su naturaleza críptica. Con los lenguajes más populares, un programador puede mirar el código fuente, sin conocer el idioma, y ​​aprender qué hace al menos la mayor parte del código. Scala a menudo proporciona esto, pero en muchos sentidos, su comportamiento es muy sutil y no intuitivo.

• Se basa en gran medida en operadores no alfanuméricos, de los cuales es muy difícil determinar el significado, ya que generalmente no se puede simplemente buscar en Google algo como /:
• Scala proporciona un gran control sobre la verificación de tipos en tiempo de compilación. Si bien esto a menudo no se aprovecha en gran medida en el código de la aplicación, sin duda complica la exploración de la API de una biblioteca finamente ajustada.
• Las dificultades también son populares en Scala, que mejoran la “expresividad” con el código, pero también dificultan la lógica de rastreo. ¿Cómo sucedió esa conversión? ¿De dónde viene ese valor?
• La gente a menudo se ha quejado del tiempo que le toma a sbt compilar una aplicación Scala. Todavía estoy aprendiendo, así que esto no ha sido un problema para mí todavía.
• Si bien la simultaneidad, Scala admite y fomenta el suministro de aplicaciones escalables y de alto rendimiento, sigue siendo un lenguaje interpretado que podría necesitar ser ampliado por una biblioteca nativa para admitir el procesamiento en tiempo real. Scala nunca será tan rápido como C o, por supuesto, lenguaje ensamblador. Scala tampoco aprovechará fácilmente las características de vanguardia de su tarjeta gráfica para un videojuego de última generación. El hecho de que Scala esté en la JVM también lo hace propenso a la degradación del rendimiento relativamente incontrolada debido a la recolección de basura.
• El soporte de IDE ha mejorado enormemente, y escuché que IntelliJ es mejor, pero el soporte de Eclipse todavía no es tan sólido como su contraparte de Java.
• El lenguaje no es muy maduro y tiene más flujo que alternativas.
• Scala te ofrece una gran cantidad de formas de hacer algo. No te ayuda a crear código mantenible. Debe confiar en las convenciones publicadas por Typesafe y Twitter como pautas.
• Mientras que para un lenguaje como Java, todas sus preguntas pueden ser respondidas en Stack Overflow, no espere que este sea el caso de Scala.
• Las empresas tardan en adoptar Scala porque les preocupa todo lo anterior, y las empresas que lo han adoptado pueden alejarse de él, prefiriendo crear aplicaciones que sean más fáciles de encontrar para los desarrolladores. Invertir en el aprendizaje de Scala puede aumentar la demanda de empresas que no sean tímidas con respecto a las nuevas tecnologías, pero no aumentará sus posibilidades con la gran mayoría de los posibles empleadores.

Estos son algunos de los aspectos negativos del uso de Scala a diario:

1. Compilación lenta Este es quizás el aspecto negativo más llorado en Scala.
2. Falta de soporte de herramientas. Aunque los IDE están mejorando, todavía están muy por detrás del soporte que ofrece Java.
3. La biblioteca de Colecciones es bastante fácil / intuitiva de usar. Pero bastante difícil de extender. Algunas de las firmas de API también son terriblemente complejas para asustarlo.
4. Al ser un idioma híbrido, hay al menos 2 escuelas de mentalidad en la comunidad Scala. Los defensores de la programación funcional pura encuentran las impurezas de Scala más evidentes en comparación con algo como Haskell. La otra escuela defiende el uso de las capacidades OO de Scala junto con FP para hacer que su diseño sea más idiomático según la filosofía original del lenguaje. Esto a menudo crea una confusión para los nuevos aprendices del idioma.
5. Scala no tiene una inferencia de tipo tan poderosa como Haskell. Esto se debe principalmente al hecho de que Scala ofrece un polimorfismo de subtipo que es difícil de integrar con las características principales de FP del lenguaje. En algunas situaciones, la falta de inferencia de tipos conduce a un código excesivamente detallado y complejo al escribir código funcional en Scala. Lo más notable de esto es implementar la unificación de orden superior para la inferencia del constructor de tipos.

Finalmente, Edward Kmett se quejó recientemente sobre algunos de los inconvenientes de Scala principalmente desde el punto de vista de las capacidades de programación funcional. Aquí está el enlace Odersky: El problema con los tipos – Strange Loop 2013 [InfoQ].

El idioma no tiene una cultura única fuerte. A este respecto, es más bien como C ++. Puede escribir C ++ como si fuera Java bastante complicado, puede escribirlo como si fuera C y puede usarlo como si fuera compatible con la metaprogramación. Diferentes personas afirman que cada uno de estos es la forma correcta de usar C ++. Cada uno de ellos ha sido diseñado para funcionar a lo largo de los años, pero debido a que las características que necesitan las otras culturas presentan, ninguno está completamente limpio.

Del mismo modo, Scala se usa como si fuera Haskell u OCaml por un lado, como si fuera un Java mejor por el otro y como si fuera Ruby por otro. Esto significa que tienes tres tendencias competitivas en el diseño del lenguaje. Esto lleva a los tres mayores inconvenientes que veo en Scala:

1. El sistema de tipos es muy poderoso y útil hasta que no lo sea. En ese punto, tienes que descubrir cómo decirle las cosas, y a diferencia del antiguo Java donde solo aceptas que necesitas lanzar todo, en Scala esto se desaconseja, por lo que debes encontrar la forma correcta, que a menudo no es sencillo. El efecto subyacente aquí es que el polimorfismo de subtipo, que necesita para ser un mejor Java, y el polimorfismo algebraico, que debe ser más como Haskell o ML, no son realmente agradables. Así que tienes muchos parches para intentar que esto funcione.

2. Las variaciones de sintaxis permitidas se vuelven desconcertantes. Las personas que preferirían usar Ruby parecen disfrutar omitiendo los corchetes y los puntos en todo el lugar en la medida en que ni siquiera se puede decir qué parte del discurso significa un fragmento de código en particular. Implicits y otras características que permiten ocultar llamadas de función no ayudan.

• Primero, puede encontrar mucha hostilidad por parte de las personas que no tienen idea de Scala. Odian aprender, y también te odiarán a ti.
• En segundo lugar, odiarás la idea de volver a la estúpida Java. Sentirá disgusto hacia la mayoría de las bibliotecas populares de Java, mal escritas, no diseñadas en absoluto, y teniendo todas las suposiciones que las personas ignorantes hacen sobre cómo escribir código.
• Tercero, hay una curva de aprendizaje; y odiarás tu propio código que escribiste, digamos, hace 6 meses.
• Cuarto, descubrirá que hay multitudes de personas muy inteligentes que hablan sobre cosas de las que nunca ha oído hablar, y necesitará aprender, aprender y aprender; antes de eso, “odiarás al scalaz” (el pasatiempo favorito de las personas que están a medio camino).
• Quinto, también descubrirá que, básicamente, no solo no sabe cómo escribir código, sino que en realidad nadie lo sabe; Y es una triste sorpresa.

Como gerente de ingeniería, tendrá dificultades para contratar desarrolladores experimentados de Scala o mejorar los desarrolladores existentes.

Puede ser “más fácil” encontrarlos en el Valle, pero fuera de eso: no tanto.

Sin embargo, si tiene un sólido equipo de desarrollo de Java y tiene sus conceptos básicos ordenados (excelentes personas, cultura de experimentación y fallas tempranas, pruebas adecuadas, devops, etc.), entonces los alentaría a explorar otros lenguajes basados ​​en JVM (como Scala) para ver si proporciona un beneficio. Pero sería una decisión del equipo. No es un CIO que en realidad no está involucrado en la construcción de nada.

Los tiempos de construcción son un problema. El compilador incremental ayuda, pero no puede resolverlo todo. Entonces hay un problema con la legibilidad del código. Creo que este es serio. La conversión implícita realmente puede dañar la legibilidad de su código y si sus desarrolladores de Scala no se preocupan por escribir código que sea comprensible, inevitablemente se encontrará con un problema de mantenimiento.

Diría que una de las cosas más frustrantes al respecto es que Scala no es tan popular como, por ejemplo, Java, por lo tanto, es más difícil encontrar personas que ya conozcan scala o que estén dispuestas a aprender Scala.

No puede descubrir nada de los errores que se muestran y, a veces, existen errores ilógicos.