2009-03-18 12 views

Respuesta

8

concisión como una característica del lenguaje está mal definida y probablemente no uniforme. Los diferentes idiomas pueden ser más o menos concisos dependiendo del problema.

Erlang como lenguaje funcional puede ser muy conciso, más allá de Ruby o Python. Específicamente, la coincidencia de patrones a menudo reemplaza las declaraciones y la recursión, y las listas de comprensión pueden reemplazar los bucles.

Por ejemplo Java podría tener algo como esto:

String foobar(int number){ 
    if (number == 0) { 
    return "foo"; 
    } else if (number == 1) { 
    return "bar"; 
    } 
    throw new Exception(); 
} 

mientras que el código Erlang sería el resultado:

foobar(0) -> "foo"; 
foobar(1) -> "bar". 

Con la excepción siendo inherentes porque no hay ninguna cláusula para la entrada de otros entonces 0 o 1. Esto es causa de un problema que se presta bien al desarrollo del estilo de Erlang.

En general, cualquier cosa que pueda definir como una transformación coincidirá especialmente con un lenguaje funcional y se puede escribir con mucha precisión. Debido a que muchos fanáticos del lenguaje funcional afirman que cualquier problema en la programación es una transformación.

2

Erlang le permite realizar funciones en muy pocas líneas de código, en comparación con mis experiencias en Java y Python. Solo Smalltalk o Scheme se acercaron a mí en el pasado. Solo obtiene un poco de sobrecarga, pero normalmente tiende a identificar identificadores para módulos, funciones, variables y átomos. Hacen que el código sea más legible. Y tienes muchos tirantes normales, rizados y cuadrados. Por lo tanto, depende de la distribución de su teclado qué cómodo será. Usted debe darle una oportunidad.

mue

1

Erlang es sorprendentemente conciso, especialmente cuando se quiere lograr un rendimiento y fiabilidad.

Erlang es concisa, incluso si se compara con Haskell:

http://thinkerlang.com/2006/01/01/haskell-vs-erlang-reloaded.html

Y es sorprendentemente rápido (y confiable) incluso en comparación con C++:

http://www.erlang.se/euc/06/proceedings/1600Nystrom.ppt

(18x menos SLOC no es sorpresa).

De todos modos, siempre depende de tus preferencias y objetivo lo que quieras lograr.

1

Tienes que dedicar algo de tiempo, escribir código, para entender el punto óptimo de erlang, frente a todas las otras herramientas emergentes, DHT, tiendas de documentos, marcos mapreduce, hadoop, GPU, scala, ... Si intentas hacer , digamos aplicaciones tipo SIMD fuera del punto óptimo, probablemente terminará luchando contra el paradigma y escribiendo código detallado, mientras que si se topan con problemas que necesitan escalar servidores y middleware sin problemas hacia arriba y hacia abajo, fluye naturalmente.(Y el aumento de Scala en su punto óptimo es inevitable, también, creo)

Algo bueno para buscar sería el experimento Tim Bray Wide Finder (destilando grandes archivos de registro de Apache) de hace un par de años, y cómo estaba decepcionado con Erlang.

lo general no recomiendo poner mucho tienda en la tanda de Alioth, dado que inevitablemente terminan comparando realmente bueno y malo de código, pero si usted necesita para poner los números de LOC, Erlang vs C, rubí, sea cual sea

http://shootout.alioth.debian.org/u32q/erlang.php

Cuestiones relacionadas