Dove si posizionerebbe Erlang sullo spettro della concisione tra, per esempio, Java/.net sull'estremità meno concisa e Ruby/Python sulla parte più concisa dello spettro? Ho un problema di RSI, quindi la concisione è particolarmente importante per me per motivi di salute.Erlang è un linguaggio conciso dal punto di vista di un programmatore?
concisione come caratteristica del linguaggio è mal definito e probabilmente non uniforme. Lingue diverse potrebbero essere più o meno concise a seconda del problema.
Erlang come linguaggio funzionale può essere molto conciso, oltre a Ruby o Python. Nello specifico, la corrispondenza del modello spesso sostituisce se le istruzioni e la ricorsione e la comprensione delle liste possono sostituire i loop.
Per esempio Java dovrebbe avere qualcosa di simile:
String foobar(int number){
if (number == 0) {
return "foo";
} else if (number == 1) {
return "bar";
}
throw new Exception();
}
mentre il codice Erlang sarà simile:
foobar(0) -> "foo";
foobar(1) -> "bar".
Con l'eccezione che è intrinseca perché non v'è alcuna clausola per l'ingresso altro allora 0 o 1. Questo è un problema che si presta bene allo sviluppo di stile di Erlang.
In generale tutto ciò che è possibile definire come una trasformazione corrisponderà a un linguaggio funzionale particolarmente bene e può essere scritto in modo molto conciso. Di fatto molti zelanti del linguaggio funzionale affermano che qualsiasi problema nella programmazione è una trasformazione.
Erlang consente di realizzare la funzionalità in pochissime righe di codice, rispetto alle mie esperienze in Java e Python. Solo Smalltalk o Scheme mi sono stati vicini in passato. Hai solo un piccolo sovraccarico, ma in genere tendi a parlare di identificatori per moduli, funzioni, variabili e atomi. Rendono il codice più leggibile. E hai un sacco di bretelle normali, ricci e quadrati. Quindi dipende dal layout della tastiera di quanto sarà confortevole. Dovresti fare un tentativo.
mue
Erlang è sorprendentemente conciso soprattutto quando si desidera ottenere prestazioni e affidabilità.
Erlang è concisa anche rispetto a Haskell:
http://thinkerlang.com/2006/01/01/haskell-vs-erlang-reloaded.html
Ed è sorprendentemente veloce (e affidabile) anche rispetto a C++:
(18 volte meno SLOC non è una sorpresa).
In ogni caso dipende sempre dalle preferenze e dall'obiettivo ciò che si desidera ottenere.
Devi passare un po 'di tempo, scrivere codice, per capire il punto debole di erlang, rispetto a tutti gli altri strumenti emergenti, DHT, doc store, framework mapreduce, hadoop, GPU, scala, ... Se provi a fare , diciamo app di tipo SIMD al di fuori del punto debole, probabilmente finirai per combattere il paradigma e scrivere codice verboso, mentre se riscontri problemi che necessitano di scalare server e middleware senza interruzioni, esso scorre in modo naturale.(E anche l'aumento di scala nel suo punto debole è inevitabile)
Una buona cosa da cercare sarebbe l'esperimento di Tim Bray Wide Finder (distillazione di grandi file di log di apache) di un paio di anni fa, e come è stato deluso da Erlang.
io in genere non consiglio mettere molto negozio nella sparatoria Alioth, dato inevitabilmente finisce per il confronto veramente buono e il codice cattivo, ma se avete bisogno di mettere i numeri di LOC, Erlang vs C, Ruby, qualunque sia