Newsgroup: it.comp.programmare
Titolo: Il LISP è ancora attuale come linguaggio?

Volendo imparare un linguaggio funzionale (proposito per il nuovo anno)
il LISP è stato il primo nome che mi è venuto in mente. Poi ho pensato
anche all'Haskell e allo Scheme, e poi ho pensato che sicuramente ce ne
sono anche altri che non conosco. E ho pensato che probabilmente i
"nuovi" linguaggi funzionali sono migliori. Va bene che non lo imparo
per lavoro, ma non vorrei ritrovarmi con un linguaggio-mausoleo in cui
si programma male e con fatica...
Ora come ora conosco Pascal, C, C++, asm x86, un pò di VBA, Delphi, PHP,
 Javascript e Prolog, ma attualmente uso soprattutto il C++ e il VBA,
mentre gli altri sono un pò sbiaditi dal tempo.
Qualcuno qui ha usato linguaggi funzionali e sa dirmi quale linguaggio
funzionale è meglio imparare, ora come ora?

 funzionale è meglio imparare, ora come ora?
Beh dipende da cosa ti serve. Haskell è sicuramente interessante e
mind-challenging, Scheme lo vedo un po più didattico e fine a sé stesso,
Common Lisp ha sicuramente più librerie, Clojure sta andando ora di moda
perché è basato sulla JVM. In più c'è Erlang di cui hai sicuramente
sentito parlare. Hai saltato in toto i linguaggi funzionali della
famiglia ML, ma non li conosco quindi mi astengo.
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
 - 
stacktrace.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 funzionale è meglio imparare, ora come ora?
Come ti ha detto Lawrence, il LISP è ancora attuale.
Io personalmente sto studiando Haskell, e lo trovo molto interessante; 
inoltre la comunità è molto attiva ed si fa molta ricerca (inclusa la 
Microsoft).
Sto valutanto anche Erlang.
Per quanto riguarda Haskell, comunque, non sono ancora riuscito ad usarlo 
per un progetto serio; avevo in mente di usarlo in un paio di progetti 
(personali) ma sto optando per Python, che conosco molto meglio.
Ciao  Manlio

 famiglia ML, ma non li conosco quindi mi astengo.
Sono contento di sapere che in famiglia stanno tutti bene (dei linguaggi
funzionali intendo). A me interessava apprendere il paradigma di
programmazione funzionale, e il modo migliore è prendere un linguaggio
funzionale e programmarci. Quindi mi va bene un linguaggio didattico
come Scheme. Il Lisp.NET di cui hai parlato mi permetterebbe di usare le
classi del framework .NET (giusto?) quindi sarebbe più direttamente
"spendibile"... cosa in fin dei conti non disprezzabile.
Ma quello che mi premeva era, come dicevo, la sicurezza di non mettermi
a studiare, per ignoranza della materia, un linguaggio fossile. Non so
se esiste un analogo funzionale del PL/1 ma non mi andrebbe di scoprirlo
a mie spese.

 Sto valutanto anche Erlang.
Nome sentito, ma niente di più.

 a mie spese.
Non credo che ci siano fossili tra quelli elencati. Solo più o meno
utili. Se pensi la famiglia dei LISP ha 50 anni...


 
Direi di si.
Nel mio caso è stato così, almeno; non avevo esperienza diretta con 
linguaggi funzionali.
Un pò di numeri (si, io quando imparo un nuovo linguaggio parto dalla sua 
definizione).
La definizione di Haskell 98:
http://haskell.org/haskellwiki/Language_and_library_specification
è relativamente piccola (circa 148 pagine, esclusa la libreria standard).
Di contro, la definizione di Standard ML (1990) è di circa 86 pagine; 
la definizione di Scheme (Revised Report 5) è circa 90 pagine.
Tra questi linguaggi, probabilmente Haskell è quello con la comunità più 
attiva; ha anche una libreria sviluppata da terzi molto ampia e ben 
organizzata:
http://hackage.haskell.org/
Francamente, ho trovato la comunità di haskell, e l'ambiente offerto da 
GHC veramente ottimi, superiori a quanto ho visto altrove.
Di recente hanno publicato un libro:
http://www.realworldhaskell.org/
L'ho letto online è l'ho trovato ben scritto, anche se un paio di 
capitoli mi hanno un pò deluso.
Haskell è comunque abbastanza difficile da padroneggiare.
Un altro linguaggio funzionale (ma non solo) che ha un grosso (beh, si 
parla relativamente) è Ocaml.
Un aspetto interessante di Haskell (in particolare di GHC, il suo 
compilatore principale) è il suo supporto alla programmazione parallela.
Di recente hanno implementato un garbage collector parallelo, ed è allo 
studio il supporto per il "nested data parallelism":
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell
GHC supporta da diverso tempo la parallelizazione del codice e software 
transactional memory.
C'è un bel capitolo in Real World Haskell:
http://book.realworldhaskell.org/read/concurrent-and-multicore-
programming.html#id675076
in particolare una semplice implementazione di map reduce.
GHC supporta anche la programmazione concorrente, usando micro threads.
E uno dei pochi linguaggi ad offrire una implementazione dei micro thread 
efficiente (l'altro esempio notevole è Erlang):
http://shootout.alioth.debian.org/u64q/benchmark.php
?
test=threadring&lang=all
Ciao  Manlio


http://www.b-list.org/weblog/2006/oct/11/functional-language-s-right-under-your-nose/
Elementi di programmazione funzionale possono essere rintracciati in
più o meno qualunque linguaggio.
Ciao.

 parla relativamente) è Ocaml.
Se non sei francese non vale la pena di usarlo. <g>
Scherzi a parte, e' il C++ dei linguaggi funzionali: pieno di feature,
complesso da capire quando usare una o l'altra. Piuttosto pragmatico, ma
non abbastanza. Mono-implementazione sostanzialmente... boh.
-- 
-riko

 funzionale č meglio imparare, ora come ora?
Beh, in tanti ne abbiamo usati. Fra i linguaggi funzionali
sostanzialmente puri io suggerirei Haskell o Erlang.
Sono entrambi molto divertenti, IMHO. Erlang e' un linguaggio con
un'utilita' pratica piuttosto spiccata, facile da imparare (abbastanza,
per lo meno) facile da trovare subito cose "utili" da fare.
Per contro confesso che da un punto di vista preferisco Haskell. Haskell
ha un'ottima comunita'. GHC e' sufficientemente efficiente (se dai un
occhio allo shootout, scopri che al peggio e' 5 volte piu' lento di C,
il che vuole dire che nel mondo reale puoi usarlo *anche* per managgiare
grosse quantita' di dati). 
Il fatto che sia lazy non ha prezzo(tm). IMHO, eh. Il mio giudizio era
piuttosto offuscato dal fatto che non avessi ben capito come usare la
gestione dell'errore, ma credo fosse colpa del testo su cui avevo
studiato. Un testo molto divertente e interessante, ma relativamente
vecchio e poco orientato agli aspetti pratici (ovvero the haskell school
of expression). Ora con real world haskell (e qualche anno di
esperienza) ho le cose molto piu' chiare e devo dire che il modo in cui
gira il suo typesystem mi fa proprio impazzire.
Detto questo e' molto probabilmente piu' rapido sviluppare in Erlang. Io
direi che puoi quasi quasi studiarli entrambi. Al di la delle librerie
diverse, lo studio affiancato ha un pregio: vedi il mondo lazy e quello
strict insieme. Non e' cosa da poco.
Non solo: Erlang e' un linguaggio fondamentalmente IO oriented (nel
senso che buona parte dei programmi erlang hanno a che fare con rete,
parallelismo, scambio di messaggi). Viceversa il cuore di Haskell e' la
separazione fra I/O e computazione. Credo possano essere buoni compagni
di studi.
Come penultima cosa potrei suggerirti Oz. Il linguaggio non lo usa quasi
nessuno, ma Concepts, Techniques and Models of Computer Programming e'
un testo favoloso (per la programmazione funzionale, imperativa, tutto).
E usano Oz per tutti gli esempi.
Valuta anche di riskillarti in Prolog. Non e' un linguaggio funzionale,
ma e' qualcosa che uso e che e' davvero interessante. Eventualmente
estenditi a CLP (e' pazzesco quello che riesci a fare con qualche
vincolo fatto bene), CHR, etc etc etc.
In ultimo... il sistema di templates di C++ e' un linguaggio funzionale
puro. Una volta appreso il paradigma funzionale, il tuo C++ potrebbe
cambiare per sempre (di solito i colleghi dicono in peggio, nel senso
che potrebbero non essere piu' in grado di capire quello che scrivi...
<g>).
-- 
-riko

 [...]
Ciao   Manlio

Il Tue, 06 Jan 2009 18:20:06 +0100, Enrico Franchi ha scritto:

Un utilizzatore di Ocaml, con cui ho discusso durante la PyFiorentina, 
non era molto d'accordo su questo punto di vista.
Ciao  Manlio

 dinamicamente (come Python).
Si. Ma complessivamente e' meno rilevante, IMHO. Dopotutto quando usi
gli elementi (e il primo in particolare) della tupla per dare
un'informazione semantica sul tipo *e* usi il pattern matching, stai di
fatto usando una forma di tipizzazione statica (sebbene gli errori
eventuali li hai a runtime). Non credo di essere stato molto chiaro.
-- 
-riko

 non era molto d'accordo su questo punto di vista.
Ero io o no? :P
Poi capisco che se a uno piace piace. Ma a OCaml preferisco SML (molto
piu' pulito e facile da apprendere). Certo, le implementazioni di OCaml
sono piu' efficienti (anche di quelle di Haskell, che io ricordi) e sono
maggiormente supportate.
-- 
-riko

 [...]
Ciao   Manlio

 funzionale č meglio imparare, ora come ora?
Python!
..oh, come non detto, avevo capito "funzionante"

 Non credo di essere stato molto chiaro.
Non capisco perchè hai messo in mezzo le tuple.
Ciao  Manlio

 il LISP è stato il primo nome che mi è venuto in mente. 
Anche a me: mi sono messo a studiare il Common Lisp! :-)
Ciao,
Giulio
-- 
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 Non capisco perchè hai messo in mezzo le tuple.
Perche' e' praticamente il tipo di dato piu' frequente in Erlang per
"costruire" tipi. Anche i record sono tuple mascherate. Nelle tabelle si
usano le tuple. Etc etc etc.
Si, e i record non piacciono neppure a me.
-- 
-riko

 
Ah, ok.
Io stavo pensando ad Haskell ;-).
Ciao  Manlio

 main = print ([100, 111, 103] == "dog")
Giusto. -10 per me. La tua soluzione e' piu' lineare e mostra meglio il
fatto che volevo sottolineare.
-- 
-riko

 [...]
Ciao  Manlio

 [...]
Ciao  Manlio

 Hugs invece non ha di questi problemi.
Hugs e' ancora sviluppato "attivamente"?
-- 
-riko

 Speriamo in Haskell Prime.
Vediamo. Purche' sia semplice.
-- 
-riko



Non lo so.
Comunque l'ultima versione ufficiale risale a settembre 2006, e l'ultimo 
commit su CVS risale a ottobre 2008.
Ciao  Manlio

 [...]
Ciao

 [...]
Ciao  Manlio Perillo