ruby scala scala-2.8

Preguntas sobre Scala de un Rubyist



scala-2.8 (7)

Aquí está mi opinión sobre esto:

  • No importa no conocer Java.

  • Scala se basa mucho en las bibliotecas de Java. Eso no importa en absoluto. Puede que tenga problemas para leer algunos ejemplos, claro, pero no lo suficiente como para ser un obstáculo. Con poco tiempo, ni siquiera notará la diferencia entre leer un documento de la API de Java y un documento de la API de Scala (bueno, excepto por el estilo completamente diferente del nuevo scaladoc).

    Sin embargo, a menudo se asume la familiaridad con el entorno JVM. Si puedo hacer un consejo aquí, es evitar a Maven al principio y usar SBT como herramienta de compilación. No será necesario para programas pequeños, pero hará que sea más fácil lidiar con los problemas en el mundo de Java-lang. Tan pronto como desee una biblioteca externa, conozca SBT. Con él, no tendrá que lidiar con ningún XML: escriba sus reglas de compilación en el propio Scala.

  • Puede que le resulte difícil obtener los conceptos y términos de tipo. Scala no solo está tipificado de forma estática, sino que tiene uno de los sistemas tipográficos más poderosos en lenguajes no académicos que existen. Apuesto a que esta será la fuente de mayor dificultad para ti. Otros conceptos tienen terminología diferente, pero rápidamente dibujarás paralelos con Ruby.

    Sin embargo, esto no es un obstáculo tan grande: puede superarlo si lo desea. El principal inconveniente es que probablemente sentirás que cualquier otro lenguaje estático tipado que aprendas después sea torpe y limitado.

  • No mencionaste en qué Programación Scala tenías tus ojos puestos. Hay dos, más una Programación en Scala. Este último fue escrito, entre otros, por el creador del lenguaje, y es considerado un excelente libro, aunque, quizás, un poco lento. Uno de los programadores de Scala fue escrito por un usuario de Twitter, Alex Payne, y por el ex mentor de objetos Dean Wampler. Es un libro muy bueno también. El principio de Scala fue escrito por el creador de Lift, David Pollack, y la gente le ha dicho cosas buenas al respecto. De hecho, no he oído a nadie quejarse de ninguno de los libros de Scala.

    Uno de estos libros sin duda sería útil. Además, el apoyo en las preguntas sobre el desbordamiento de pila para Scala es bastante bueno, ¡hago todo lo posible para garantizar que así sea! :-) Está la lista de correo de scala-users, donde también se pueden obtener respuestas (siempre y cuando la gente no esté muy ocupada), y está el canal #scala IRC en Freenode, donde también obtendrá un buen soporte. A veces las personas simplemente no están cerca, pero si lo están, te ayudarán.

    Por último, hay blogs. El mejor para principiantes es probablemente Daily Scala . Usted puede encontrar muchos, muchos otros son el planeta Scala . Entre ellos, mi propia Algorithmically Challenged , que últimamente no está teniendo mucho amor, pero volveré a hacerlo. :-)

  • Scala ha restaurado la diversión en la programación para mí. Por supuesto, estaba haciendo Java, que es booooring, imho. Una de las razones por las que dedico tanto tiempo a responder preguntas sobre el desbordamiento de pila es que disfruto de encontrar soluciones para las preguntas formuladas.

Recientemente he estado buscando un nuevo idioma durante mi tiempo libre y Scala parece ser muy atractivo.

Tengo algunas preguntas al respecto:

  1. ¿No sabiendo Java impondrá un desafío en aprenderlo? ¿Será una gran desventaja más adelante? (es decir, ¿con qué frecuencia las personas confían en las bibliotecas específicas de Java?)

  2. ¿Qué tan grande es la diferencia en comparación con Ruby? (Aparte de ser tipificado estáticamente) ¿Introduce muchos términos nuevos o estaré familiarizado con la mayoría de los mecanismos del lenguaje?

  3. ¿Qué recursos recomendarías? Tengo mis ojos en la Programming Scala y en los libros de Beginning Scala

  4. Aunque subjetivo, ¿es divertido Scala para programar? : PAG

Gracias


Esta es otra respuesta tardía, ya que recientemente he venido a Scala, pero puedo responder 1, 3 y 4:

1) Porté un proyecto de F # grande y multifacético a Scala sin ningún uso de las bibliotecas de Java o .NET. Así que para muchos proyectos, uno puede apegarse totalmente a Scala nativo. El conocimiento del ecosistema de Java sería una ventaja, pero se puede adquirir gradualmente durante y después de aprender Scala.

3) La programación en Scala no solo es excelente para aprender Scala, sino que es uno de los pocos libros de computación realmente legibles en cualquier idioma. Y es útil para futuras referencias.

4) He usado cerca de una docena de lenguajes de programación diferentes, desde lenguajes de ensamblaje a Prolog, pero Scala y F # son los dos lenguajes de programación más divertidos que he usado, por un amplio margen. (Scala y F # son muy similares, un ejemplo de "evolución convergente" en dos ecosistemas diferentes: JVM y .NET).

-Neil


Esto es muy tarde, pero estoy de acuerdo en cierta medida con lo que dijo oxbow_lakes. Recientemente he realizado la transición de Python a Scala, y saber cómo funciona Java, especialmente las limitaciones de Java con respecto a los tipos genéricos, me ha ayudado a comprender ciertos aspectos de Scala.

Más notablemente:

  1. Java tiene una característica errónea horriblemente dañada conocida como "borrado de tipo". Desgraciadamente, este quebrantamiento también está presente en la JVM. Esto afecta particularmente a la programación con tipos genéricos: un problema que simplemente no se presenta en lenguajes de tipo dinámico como Ruby y Python, sino que es muy grande en los lenguajes de tipo estático. Scala hace un trabajo tan bueno como puede solucionar esto, pero la magnitud de la ruptura significa que parte de ella inevitablemente se desangra en Scala. Además, algunas de las correcciones en Scala para este problema (p. Ej., Manifiestos) son recientes e imprecisos, y realmente requieren una comprensión de lo que ocurre debajo. Tenga en cuenta que este problema probablemente no afectará su comprensión de Scala al principio, pero se encontrará con él cuando comience a escribir programas reales que usan tipos genéricos, ya que hay cosas que intentará hacer que simplemente no funcionarán. y no sabrá por qué, a menos que / hasta que comprenda las limitaciones forzadas por el borrado de tipo.

  2. Tarde o temprano también se encontrará con problemas relacionados con otro error de Java, que es la división de tipos en objetos (clases) frente a tipos primitivos (ints, flotadores, booleanos), y en particular, el hecho de que los tipos primitivos no son parte del sistema de objetos. Scala hace un gran trabajo ocultándote esto, pero puede ser útil saber qué está haciendo Java en ciertos casos de esquina que, de otro modo, pueden ser complicados, especialmente en el caso de tipos genéricos, en gran parte debido a la rotura de borrado de tipo descrita en # 1. (El borrado de tipos también produce un gran impacto en el rendimiento cuando se usan matrices, tablas hash y tipos genéricos similares sobre primitivas; esta es un área en la que saber Java ayudará mucho).

  3. Infracción # 3: los arreglos también se manejan de manera especial y no ortogonal en Java. La ocultación de Scala de esto no es tan perfecta como para los primitivos, pero es mucho mejor que para el borrado de tipo. El mecanismo de ocultación a veces se expone (por ejemplo, el tipo ArrayWrapper), que en ocasiones puede dar lugar a problemas, pero el mayor problema en la práctica, como es lógico, es nuevamente con los tipos genéricos.

  4. Los parámetros de clase de Scala y la forma en que Scala maneja los constructores de clase. En este caso, Java no está roto. Podría decirse que Scala tampoco lo es, pero la forma en que maneja a los constructores de clases es bastante inusual, y en la práctica me ha costado entenderlo. Solo he podido entender el comportamiento de Scala al descubrir cómo el código Scala relevante se traduce a Java (o más correctamente, a Java compilado), y luego razonar sobre lo que Java haría. Dado que asumo que Ruby funciona como Java en este aspecto, no creo que tenga demasiados problemas, aunque es posible que tenga que hacer la misma conversión mental.

  5. I / O. Esto es en realidad un problema de biblioteca en lugar de un problema de idioma. En la mayoría de los casos, Scala proporciona sus propias bibliotecas, pero Scala no tiene realmente una biblioteca de E / S, por lo que no tiene más remedio que usar la biblioteca de E / S de Java directamente. Para un programador de Python o Ruby, esta transición es un poco dolorosa, ya que la biblioteca de E / S de Java es grande y voluminosa, y no es terriblemente fácil de usar para realizar tareas simples, por ejemplo, iterar sobre todas las líneas en un archivo.

Tenga en cuenta que además de la E / S, también necesita usar las bibliotecas de Java directamente para otros casos en los que interactúa con el sistema operativo o las tareas relacionadas, por ejemplo, trabajar con horas y fechas o obtener variables de entorno, pero generalmente esto no es demasiado difícil de entender . Las otras bibliotecas principales de Java que podría necesitar usar son

  1. Invocación de subproceso, también algo grande y voluminosa.
  2. Redes, pero esto siempre es algo doloroso.
  3. Reflexión, es decir, examinar dinámicamente los métodos y / o campos en una clase, o invocar dinámicamente un método por nombre cuando el nombre no se conoce en el momento de la compilación. Esto es algo un tanto esotérico con el que la mayoría de las personas no tienen que lidiar. Al parecer, Scala 2.10 tendrá su propia biblioteca de reflexión, pero actualmente tiene que usar las API de reflexión de Java, lo que significa que necesita saber bastante sobre cómo Scala se convierte a Java. (Afortunadamente, hay una opción de impresión en el compilador de Scala para mostrar exactamente cómo se realiza esta conversión).

Hay muchos conceptos que se comparten entre Ruby y Scala. Ha pasado un tiempo desde que codifiqué a Ruby, así que esto no es exhaustivo.

Ruby <==> Scala (¡Aproximadamente!)

  • Mixins <==> Rasgos
  • Monkey Patching <==> Pimp My Library (conversiones implícitas a un contenedor con métodos adicionales)
  • Proc / Closure <==> Function / Function Literal
  • Duck Typing <==> Tipos estructurales
  • Último argumento como un Proc <==> Lista de parámetros al curry (ver Traversable # flatMap)
  • Enumerable <==> Traversable
  • recoger <==> mapa
  • inyectar <==> foldLeft / foldRight
  • Symbol.toProc <==> Azúcar sintáctico de people.map(_.name) : people.map(_.name)
  • Concisión de escritura dinámica <==> Inferencia de tipo
  • Nulo <==> nulo, aunque la opción es preferible. ( No Nil, que es una lista vacía!)
  • Todo es una expresión <==> ídem
  • Símbolos / hashes como argumentos <==> Parámetros con nombre y predeterminados
  • Singleton <==> object Foo {}
  • Todo es un objeto <==> Todo es un tipo o un objeto (incluidas las funciones)
  • Sin primitivos <==> Sistema de tipo unificado. Cualquiera es supertipo para primitivos y objetos.
  • Todo es un mensaje <==> Los operadores son solo llamadas a métodos

Características de Ruby que te puedes perder

  • método_missing
  • define_method etc

Scala características que deberías aprender

  • La coincidencia de patrones
  • Clases inmutables, en particular clases de casos
  • Vistas implícitas y parámetros implícitos
  • Tipos, tipos y más tipos: genéricos, varianza, miembros de tipo abstracto
  • Unificación de objetos y funciones, significado especial de los métodos de apply y update .

No tengo un historial de Ruby pero, sin embargo, puedo ser capaz de ayudarte.

  1. No creo que no saber Java sea una desventaja, pero podría ayudar. En mi opinión, las bibliotecas de Java se usan con relativa frecuencia, pero incluso un codificador Java entrenado no las conoce todas, por lo que no hay desventaja aquí. Aprenderás algunas partes de la biblioteca de Java al aprender Scala porque incluso las bibliotecas de Scala las usan.

  2. -

  3. Comencé leyendo Programming Scala y giré para leer la fuente de la biblioteca Scala. Este último ayudó mucho a entender el lenguaje. Y como siempre: Código, Código, Código. La lectura sin codificación no te llevará a ningún lado, pero estoy seguro de que ya lo sabes. :-) Otros recursos útiles son los blogs, consulte https://.com/questions/1445003/what-scala-blogs-do-you-regularly-follow para una compilación de buenos blogs de Scala.

  4. ¡Es! Como dijiste, esto es muy subjetivo. Pero para mí, proveniente de un entorno Java, es muy divertido.


Re. punto 1. Al no estar familiarizado con Java, el lenguaje no es necesariamente un problema. Las bibliotecas de terceros se integran en gran medida perfectamente en Scala. Sin embargo, un cierto conocimiento de las diferencias en las colecciones puede ser bueno (por ejemplo, una lista de Scala no es una lista tradicional de Java, y las API pueden esperar lo último).

Las habilidades relacionadas con Java que se transfieren están relacionadas con la plataforma Java. es decir, aún está trabajando con una JVM que realiza la carga de clases, la recolección de basura, la compilación JIT, etc. Así que la experiencia en esto es útil. Pero no del todo necesario.

Tenga en cuenta que Scala 2.8 es inminente, y hay algunos cambios incompatibles de escritura. 2.7. Por lo tanto, cualquier libro, etc. que usted compre, debe ser consciente de tales diferencias.


Voy a presentar una nota de precaución acerca de cuánto conocimiento de Java se requiere porque no estoy de acuerdo en que no sea un problema en absoluto. Hay cosas sobre Java que son directamente relevantes para scala y que debes entender.

  1. El modelo de memoria de Java y los mecanismos que proporciona la plataforma para la concurrencia. Estoy hablando de sincronización, hilos, etc.

  2. La diferencia entre los tipos primitivos (doble, flotante, etc.) y los tipos de referencia (es decir, subclases de Object ). Scala proporciona algunos mecanismos agradables para ocultar esto al desarrollador, pero es muy importante, si está escribiendo un código que debe ser eficaz, saber cómo funcionan estos

Esto va en ambos sentidos: el tiempo de ejecución de Java proporciona características que (sospecho, aunque puedo estar equivocado) no están disponibles en Ruby y serán de gran beneficio para usted:

  • Extensiones de gestión (MBeans)
  • JConsole (para monitoreo de tiempo de ejecución de memoria, CPU, problemas de concurrencia de depuración)
  • JVisualVM (para instrumentación en tiempo de ejecución de código para depurar problemas de memoria y rendimiento)

Estos puntos # 1 y # 2 no son obstáculos insuperables y creo que las otras similitudes mencionadas aquí trabajarán fuertemente a su favor. ¡Ah, y Scala es ciertamente muy divertido!