2009-06-30 21 views

Respuesta

15

Una de las cosas mencionadas en talks by Martin Odersky en Scala es que es un lenguaje que se adapta bien a varios problemas. No estaba hablando de escalar en el sentido de rendimiento, sino en el sentido de que el propio lenguaje puede parecer expandirse a través de las bibliotecas. De modo que:

val lock = new ReentrantReadWriteLock 
lock withReadLock { 
    //do stuff 
} 

parece que hay un poco de azúcar sintáctica especial para tratar con j.u.c cerraduras. Pero este no es el caso, solo está usando el lenguaje scala de tal manera que aparece como. El código es más legible, ¿no?

En particular, las diversas reglas de análisis del lenguaje scala hacen que sea muy fácil crear bibliotecas que se parecen a un lenguaje específico de dominio (o DSL). Mira scala-test por ejemplo:

describe("MyCoolClass") { 
    it("should do cool stuff") { 
    val c = new MyCoolClass 
    c.prop should be ("cool") 
    } 
} 

(Hay un montón más ejemplos de esto - descubrí this one ayer). Se habla mucho sobre las nuevas características que se implementarán en el lenguaje Java en JDK7 (project coin). Muchas de estas características son azúcar sintáctico especial para tratar algún problema específico. Scala ha sido diseñado con algunas reglas simples que significan que las nuevas palabras clave para cada pequeña molestia no son necesarias.

+0

Esto parece un aspecto de la décima regla de Greenspun. – Svante

+4

Estoy de acuerdo con esto, pero lo veo como un gran negativo.Mantener el software implica aprender lo suficiente para resolver su problema y seguir adelante, sin tener que entender cómo un idioma cambia una sintaxis. También creo que la principal preocupación de cada desarrollador debería ser cómo hacer que esto sea más fácil para el siguiente tipo que venga y trabaje en ello. Es por eso que utilizamos comentarios, patrones de desarrollo y código bien escrito. Desde este punto de vista, realmente no creo que Scala sea útil en muchos casos, sin embargo, depende del código experimental, los equipos pequeños y el código que esperas reemplazar en lugar de mantener –

+0

. Me encanta la idea de que solo debes saber lo suficiente. acerca de cómo resolver su problema y nada más. Presumiblemente, adopta la misma actitud hacia su automóvil, y se enojó después de conducir a su garaje y luego descubrió que no sabía cómo hacer que retrocediera para sacarlo nuevamente. Por lo general, hay un lugar para ser proactivo y * preparado *. –

7

Uno más de los objetivos de diseño originales fue, por supuesto, crear un lenguaje que se ejecute en la Máquina Virtual Java y sea totalmente interoperable con las clases de Java. Esto tiene (al menos) dos ventajas:

  • puede aprovechar la ubicuidad, estabilidad, características y reputación de la JVM. (piense en extensiones de administración, compilación JIT, recolección de basura avanzada, etc.)
  • puede seguir utilizando todas sus bibliotecas favoritas de Java, tanto de terceros como propias. Si este no fuera el caso, sería un obstáculo significativo para el uso comercial de Scala en muchos casos (el mío, por ejemplo).
+0

Todo es cierto, pero también es cierto para muchos otros lenguajes basados ​​en JVM. ¿Qué distingue a Scala de los demás? Superficialmente, sus características principales ya están disponibles en otros lenguajes JVM. – skaffman

+0

No preguntó qué distingue a Scala de otros lenguajes JVM –

+0

Lo sé, pero lo soy :) – skaffman

2

Dado que es funcional y utiliza actores (como yo lo entiendo, por favor coméntelo si tengo esto mal) hace que sea muy fácil escalar casi cualquier cosa hasta cualquier número de CPU.

Dicho esto, veo a Scala como una especie de banco de pruebas para las nuevas características del lenguaje. Eche el fregadero de la cocina y vea qué pasa.

Mi opinión personal es que para cualquier aplicación que involucre un equipo de más de 3 personas es más productivo con un lenguaje con sintaxis muy simple y restrictiva solo porque todo el trabajo se vuelve más como interactúa con otros en lugar de solo codificar para hacer que la computadora haga algo

Cuantas más personas agregue, más tiempo va a pasar explicando qué ?: significa o la diferencia entre | y || como se aplica a dos booleanos (en Java, encontrará muy poca gente sabe).

+0

Es por eso que todos los grandes proyectos de software están escritos para Universal Turing Machine –

+0

Como ya he dicho, es mi opinión personal, poco difundida. –

+0

Bill, lo que describes parece ser la premisa básica de Java para mí. – Svante

12

Otro objetivo de la Scala fue a cerrar la brecha entre funcional y orientados a objetos idiomas. Contiene muchos lenguajes funcionales inspirados (es decir, ¡copiados de!).Soy parte del increíblemente poderoso pattern-matching, el actor-based concurrency framework y (por supuesto) funciones de primer orden y superior.

Por supuesto, su pregunta decía que había un propósito específico y acabo de dar 3 razones por separado; ¡probablemente tengas que preguntarle a Martin Odersky!

6

De acuerdo con las respuestas anteriores, pero recomendar la introducción a An Overview of the Scala Programming Language:

El trabajo sobre el Scala se deriva de un esfuerzo de investigación para desarrollar un mejor soporte de idiomas para el software de componentes. Hay dos hipótesis que nos gustaría validar con el experimento de Scala. En primer lugar, postulamos que un lenguaje de programación para el software de componentes necesita ser escalable en el sentido de que los mismos conceptos pueden describir partes pequeñas y grandes. Por lo tanto, nos concentramos en los mecanismos de abstracción, composición y descomposición en lugar de agregar un gran conjunto de primitivas que podrían ser útiles para componentes en algún nivel de escala, pero no en otros niveles. En segundo lugar, postulamos que el soporte escalable para los componentes puede ser provisto por un lenguaje de programación que unifique y generalice la programación orientada a objetos y funcional. Para los lenguajes tipados estáticamente, de los cuales Scala es una instancia, estos dos paradigmas hasta ahora estaban muy separados. (Odersky)

Clasifico personalmente Scala junto con Python en cuanto a qué problemas soluciona y cómo. La diferencia evidente y la queja ocasional es la complejidad del tipo. Estoy de acuerdo con que las abstracciones de Scala son complicadas y, a veces, aparentemente intrincadas, pero por algunos puntos:

  1. También son en su mayoría opcionales.
  2. El compilador de Scala es como pruebas y documentación gratuitas a medida que aumenta la complejidad ciclomática y las líneas de código.
  3. Cuando está correctamente implementado, Scala puede realizar operaciones casi imposibles detras de API consistentes y coherentes. De Scala 2.8 Collections:

Por ejemplo, una cadena (o más bien: su clase RichString el soporte) puede ser visto como una secuencia de Chars, sin embargo, no es un tipo de colección genérica. No obstante, la asignación de un carácter a mapa de caracteres sobre un RichString debería volver a producir un RichString, como en el siguiente interacción con el Scala REPL:

scala> "abc" map (x => (x + 1).toChar) 
res1: scala.runtime.RichString = bcd 

Pero lo que sucede si se aplica una función de char a Int a una cadena? En ese caso, no podemos producir una cadena como resultado, tiene que ser una secuencia de elementos Int en su lugar. De hecho, uno obtiene:

"abc" map (x => (x + 1)) 
res2: scala.collection.immutable.Vector[Int] = Vector(98, 99, 100) 

Así resulta que el mapa rendimientos diferentes tipos dependiendo de lo que el tipo de resultado del argumento de la función es pasado! (Odersky)

Cuestiones relacionadas