[vari] Linguaggi Funzionali

[Sabonis]

Secondo voi quali tra questi linguaggi sono più interessanti da imparare?

lisp/scheme
erlang
f#
haskell
OCaml

[!k-0t1c!]

A seconda di quel che ti interessa:

Se ti interessa la piattaforma .NET, metodi quantitativi per la finanza, image processing etc allora ti direi F#
LISP è molto usato in ambito accademico a scopo didattico ma nel mondo reale trova pochi sbocchi, per lo più nella programmazione di AI.
erlang è molto apprezzato per la programmazione concorrente ma io non riesco a trovarci alcun pregio particolare che altri linguaggi nella lista non offrano (né una combinazione di pregi tale da renderlo speciale). Bisogna considerare tuttavia che se vuoi scrivere software per il calcolo distribuito all'interno di un cluster o similia c'è già molto di precucinato...
haskell è affascinante dal punto di vista della purezza e per alcuni paper che ho letto che presentano interessanti innovazioni, ma nel mondo reale la programmazione puramente funzionale si scontra spesso con alcuni classici tipo algoritmi che con la mutabilità performano fino al 50000% più veloce (non è un numero a caso) e per adesso inoltre la documentazione, le librerie e i tools non sono ancora molto maturi. E' comunque da tenere d'occhio, visto anche come recentemente la sua crescita sta accelerando.
Quanto ad ocaml ti direi di lasciar perdere. L'idea di ocaml non era male, ma la realizzazione non brillava, al punto che F#, che da ocaml prende molto, è finito per discostarsene non poco e con risultati molto migliori.

[shinya]

Se sei a digiuno di programmazione funzionale, io partirei da Scheme. Ci sono ottimi libri che lo usano come base.
Anche Haskell è interessante, anche se io non riesco a farmelo piacere; c'è un altro ottimo libro qui.

Degli altri conosco poco e niente, quindi non mi esprimo.
Se posso aggiungerne uno alla lista, prova Factor. E' funzionale e concatenativo. E' come lisp/scheme, come concetti, ma al contrario, e senza le parentesi! Ha una quantità smodata di librerie, e le prestazioni sono ottime (il codice è JIT-compiled). Poi io quando posso contribuisco, quindi il mio giudizio è un pò poco obiettivo

[^TiGeRShArK^]

Originariamente inviato da !k-0t1c!

A seconda di quel che ti interessa:

Se ti interessa la piattaforma .NET, metodi quantitativi per la finanza, image processing etc allora ti direi F#
LISP è molto usato in ambito accademico a scopo didattico ma nel mondo reale trova pochi sbocchi, per lo più nella programmazione di AI.
erlang è molto apprezzato per la programmazione concorrente ma io non riesco a trovarci alcun pregio particolare che altri linguaggi nella lista non offrano (né una combinazione di pregi tale da renderlo speciale). Bisogna considerare tuttavia che se vuoi scrivere software per il calcolo distribuito all'interno di un cluster o similia c'è già molto di precucinato...
haskell è affascinante dal punto di vista della purezza e per alcuni paper che ho letto che presentano interessanti innovazioni, ma nel mondo reale la programmazione puramente funzionale si scontra spesso con alcuni classici tipo algoritmi che con la mutabilità performano fino al 50000% più veloce (non è un numero a caso) e per adesso inoltre la documentazione, le librerie e i tools non sono ancora molto maturi. E' comunque da tenere d'occhio, visto anche come recentemente la sua crescita sta accelerando.
Quanto ad ocaml ti direi di lasciar perdere. L'idea di ocaml non era male, ma la realizzazione non brillava, al punto che F#, che da ocaml prende molto, è finito per discostarsene non poco e con risultati molto migliori.

secondo me ora come ora F# potrebbe essere una buona base di partenza..
anche se sinceramente non ho trovato un buon tutorial completo, quelli che ho visto sono un pò troppo sintetici (vabbè che li guardavo nei ritagli di tempo al lavoro tra una compilazione e l'altra e in effetti alcune cose magari mi sfuggivano per quel motivo.. )
..qualche suggerimento per un buon tutorial?

[!k-0t1c!]

Per la maggior parte degli impasse in cui ti potresti trovare come principiante questo dovrebbe bastare:
http://www.a6systems.com/fsharpcheatsheet.pdf

Per un po' di tutorial introduttivi dai un'occhiata su http://cs.hubfs.net

Se vuoi fare sul serio, invece, guardati Expert F#. Imbattibile. Mi ha insegnato tutto quel che dovevo sapere in poche ore ed il resto è stata solo questione di pratica.

[^TiGeRShArK^]

Originariamente inviato da !k-0t1c!

Per la maggior parte degli impasse in cui ti potresti trovare come principiante questo dovrebbe bastare:
http://www.a6systems.com/fsharpcheatsheet.pdf

Per un po' di tutorial introduttivi dai un'occhiata su http://cs.hubfs.net

Se vuoi fare sul serio, invece, guardati Expert F#. Imbattibile. Mi ha insegnato tutto quel che dovevo sapere in poche ore ed il resto è stata solo questione di pratica.

danke.
Per Expert F# intendi quello della Apress?
In effetti mi sono sempre trovato bene con i libri di quella casa.

[!k-0t1c!]

Originariamente inviato da ^TiGeRShArK^

danke.
Per Expert F# intendi quello della Apress?
In effetti mi sono sempre trovato bene con i libri di quella casa.

Sì, apress
E' fatto bene ed anche se è datato è molto esaustivo e 99 volte su 100 ancora attuale.
http://www.amazon.com/Expert-F-Exper.../dp/1590598504

[fero86]

Originariamente inviato da !k-0t1c!

Sì, apress
E' fatto bene ed anche se è datato è molto esaustivo e 99 volte su 100 ancora attuale.
http://www.amazon.com/Expert-F-Exper.../dp/1590598504

scusa ma come fa ad essere datato un libro che parla di un linguaggio per .NET che é a malapena uscito nella versione beta del nuovo IDE Microsoft?
datato quanto? datato dell'anno scorso?
te lo chiedo perché sarei interessato anche io all'acquisto di uno o due libri su F#.

[!k-0t1c!]

Il libro è del dicembre 2007 e si riferisce alla versione 1.9.4 del linguaggio.
Ora il linguaggio ha raggiunto la versione 1.9.6.16
Detto questo non si riscontrano problemi con quanto contenuto nel libro salvo per un link ad un progetto purtroppo defunto.
Al momento io considero Expert F# il miglior libro disponibile su F#, quindi non mi faccio scrupolo alcuno a consigliarlo anche se Seq.max_by è diventato Seq.maxBy etc

[javaboy]

Conosco vagamente erlang e lisp.
Lisp forse è più interessante dal punto di vista accademico ma ha un grosso problema: ne esistono N (con N molto grande) implementazioni non sempre compatibili fra di loro. Inoltre alla lunga diventa stressante combattere contro tutte quelle parentesi tonde.

Erlang è più usato nella pratica, personalmente trovo molto piacevole programmare in erlang anche se l'ho usato pochissimo e solo per curiosità personale. E' ottimo per la programmazione concorrente.

[marco.r]

Originariamente inviato da !k-0t1c!

LISP è molto usato in ambito accademico a scopo didattico ma nel mondo reale trova pochi sbocchi, per lo più nella programmazione di AI.

In generale ben pochi linguaggi funzionali hanno ampia diffusione nel mondo del lavoro. In questo senso i lisp non sono messi peggio, anzi assieme ad Haskell ed Erlang, Common Lisp e' usato in piu' di qualche grande realta'. sicuramente di piu di F# ...

haskell è affascinante dal punto di vista della purezza e per alcuni paper che ho letto che presentano interessanti innovazioni, ma nel mondo reale la programmazione puramente funzionale si scontra spesso con alcuni classici tipo algoritmi che con la mutabilità performano fino al 50000% più veloce (non è un numero a caso) e per adesso inoltre la documentazione, le librerie e i tools non sono ancora molto maturi.

Uhm, io direi che e' invece un numero tirato a caso . Soprattutto di recente haskell ha fatto passi da gigante dal punto di vista delle prestazioni. Alcuni tipi di algoritmi sono difficili da implementare efficientemente in forma puramente funzionale, ma con un po' di pratica si riesce ad ottenere delle performance di tutto rispetto. Se hai qualche esempio specifico possiamo fare delle prove.

Quanto ad ocaml ti direi di lasciar perdere. L'idea di ocaml non era male, ma la realizzazione non brillava, al punto che F#, che da ocaml prende molto, è finito per discostarsene non poco e con risultati molto migliori.

con realizzazione cosa intendi ? L'implementazione ?
Dal punto di vista del codice, OCaml mi risulta produca codice molto efficiente; il linguaggio non lo conosco molto, per cui non lo posso giudicare; ho letto che tra gli autori c'e' chi dice che il difetto piu' grosso e' il modello ad oggetti; in che misura e' diverso F# ?

[marco.r]

Originariamente inviato da javaboy

Conosco vagamente erlang e lisp.
Lisp forse è più interessante dal punto di vista accademico ma ha un grosso problema: ne esistono N (con N molto grande) implementazioni non sempre compatibili fra di loro. Inoltre alla lunga diventa stressante combattere contro tutte quelle parentesi tonde.

Beh, in fondo i due dialetti principali sono common lisp e scheme; scheme ha il problema che lo standard e' (era) molto ridotto per cui ogni implementazione aggiunge un sacco di funzionalita' non standard. In common lisp invece si riesce ad essere abbastanza portabili senza troppa fatica, e comunque le implementazioni che contano sono proprio poche.

[!k-0t1c!]

Originariamente inviato da marco.r

In generale ben pochi linguaggi funzionali hanno ampia diffusione nel mondo del lavoro. In questo senso i lisp non sono messi peggio, anzi assieme ad Haskell ed Erlang, Common Lisp e' usato in piu' di qualche grande realta'. sicuramente di piu di F# ...

Il solo fatto che F# comparirà in VS2010 lo renderà in un colpo più diffuso di haskell, erlang e common lisp messi insieme, e quasi tutto quel che richiede (tutto tranne FSharp.Core.dll) sarà già sul PC di qualche centinaio di milioni di utenti Ed anche in maniera comoda...che IDE supporta Haskell (per dirne uno) come VS supporta F#? (no, ho provato tutti i plugin per eclipse, non c'è nulla di lontanamente paragonabile). Quanto a Common Lisp potrei impazzire con tutte quelle parentesi tonde...

Uhm, io direi che e' invece un numero tirato a caso . Soprattutto di recente haskell ha fatto passi da gigante dal punto di vista delle prestazioni. Alcuni tipi di algoritmi sono difficili da implementare efficientemente in forma puramente funzionale, ma con un po' di pratica si riesce ad ottenere delle performance di tutto rispetto. Se hai qualche esempio specifico possiamo fare delle prove.

Andavo a memoria da un blog che non riesco a ritrovare, ma sembra che il numero 50 volte (50000%) non sia poi tanto raro. In questo caso non è riferito a purezza/mutabilità ma semplicemente a linguaggi (lo so, gli optimizer contano, ma anche l'approccio usato).

con realizzazione cosa intendi ? L'implementazione ?
Dal punto di vista del codice, OCaml mi risulta produca codice molto efficiente; il linguaggio non lo conosco molto, per cui non lo posso giudicare; ho letto che tra gli autori c'e' chi dice che il difetto piu' grosso e' il modello ad oggetti; in che misura e' diverso F# ?

Intendo proprio il linguaggio: assenza di operator overloading, la sintassi con gli "in" di default, type inference meno potente che in F#. Certo anche sul piano dell'implementazione non c'è paragone...basti pensare che OCAML genera codice nativo e F# usa un compilatore JIT e tuttavia F# batte OCAML in una lunga serie di benchmark...

[mindwings]

Peccato che rimane in ambito M$ questo F#... Clojure? Non se lo fila nessuno? - Penso che per le parentesi tonde sia questione di abitudine. Ho scritto poco codice in scheme e a dire il vero la sintassi e' quasi inesistente e non ho avuto particolari rogne con le parentesi...

[shinya]

Originariamente inviato da mindwings

Peccato che rimane in ambito M$ questo F#... Clojure? Non se lo fila nessuno?

Emh... veramente io avevo postato il link ad un bel tutorial tempo fa (che si, non si è cagato quasi nessuno ), perchè penso che Clojure abbia delle buone idee.

[marco.r]

Originariamente inviato da !k-0t1c!

Il solo fatto che F# comparirà in VS2010 lo renderà in un colpo più diffuso di haskell, erlang e common lisp messi insieme

Aspettiamo prima che si cominci ad usarlo, poi possiamo cominciare a vedere i numeri...

e quasi tutto quel che richiede (tutto tranne FSharp.Core.dll) sarà già sul PC di qualche centinaio di milioni di utenti Ed anche in maniera comoda...che IDE supporta Haskell (per dirne uno) come VS supporta F#? (no, ho provato tutti i plugin per eclipse, non c'è nulla di lontanamente paragonabile). Quanto a Common Lisp potrei impazzire con tutte quelle parentesi tonde...

ho provato molto poco sia haskell+eclipse sia f#+vs, per cui non posso giudicare in merito. Per common lisp slime e' a livello di ide per C# e Java, una volta che si fa la mano.

Andavo a memoria da un blog che non riesco a ritrovare, ma sembra che il numero 50 volte (50000%) non sia poi tanto raro. In questo caso non è riferito a purezza/mutabilità ma semplicemente a linguaggi (lo so, gli optimizer contano, ma anche l'approccio usato).

Portiamo qualche esempio, e poi lo valutiamo, anche perche' una soluzione efficiente puramente funzionale puo' essere radicalmente diverso da una classica.

Intendo proprio il linguaggio: assenza di operator overloading, la sintassi con gli "in" di default, type inference meno potente che in F#. Certo anche sul piano dell'implementazione non c'è paragone...basti pensare che OCAML genera codice nativo e F# usa un compilatore JIT e tuttavia F# batte OCAML in una lunga serie di benchmark...

Capito.

[fero86]

Originariamente inviato da !k-0t1c!

Il libro è del dicembre 2007 e si riferisce alla versione 1.9.4 del linguaggio.
Ora il linguaggio ha raggiunto la versione 1.9.6.16
Detto questo non si riscontrano problemi con quanto contenuto nel libro salvo per un link ad un progetto purtroppo defunto.
Al momento io considero Expert F# il miglior libro disponibile su F#, quindi non mi faccio scrupolo alcuno a consigliarlo anche se Seq.max_by è diventato Seq.maxBy etc

grazie mille delle spiegazioni

[!k-0t1c!]

Originariamente inviato da marco.r

Aspettiamo prima che si cominci ad usarlo, poi possiamo cominciare a vedere i numeri...

Usato molto al Credit Suisse, usato per i servizi online XBox, etc. Questo al giorno d'oggi, che è ancora in CTP...

Originariamente inviato da marco.r

ho provato molto poco sia haskell+eclipse sia f#+vs, per cui non posso giudicare in merito. Per common lisp slime e' a livello di ide per C# e Java, una volta che si fa la mano.

Quel che non sembra recepito da tutti gli utendi di EMACS + qualcosa, vi + qualcosa etc è che c'è una valanga di programmatori, me compreso, che non è disposta a perdere ore a "farsi la mano". Una minima parte di operazioni, molto frequenti, si impara a farla con scorciatoie, un'enorme parte di operazioni meno frequenti ma non meno importanti è accelerata infinitamente se l'interfaccia è buona (no, quella di EMACS + qualsiasi cosa non lo è...) e questo migliora enormemente la curva di apprendimento e la rapidità d'utilizzo dell'IDE.
Alla luce di questo mi pare ovvio che i tools a disposizione di un linguaggio concorrano in enorme parte al suo successo (o fallimento) e pertanto sono fiducioso che il forte interesse per F# non farà che crescere.

Originariamente inviato da marco.r

Portiamo qualche esempio, e poi lo valutiamo, anche perche' una soluzione efficiente puramente funzionale puo' essere radicalmente diverso da una classica.

Devo aver dimenticato il link che avevo trovato di un caso in cui questo vale:
http://markmail.org/message/dl7xwdevzcnwvcbi
e sono perfettamente d'accordo, le soluzioni possono essere tremendamente diverse, ma ci sono casi come ad esempio funzioni ricorsive dove è necessario passare delle collection dove la sola costruzione e duplicazione della collection (quando non viene modificata dentro alla funzione) causa performance notevolmente inferiori rispetto a una modifica in-place (che mi piace di meno ma a volte fa semplicemente meglio il suo lavoro ).

[shinya]

Originariamente inviato da !k-0t1c!

Quel che non sembra recepito da tutti gli utendi di EMACS + qualcosa, vi + qualcosa etc è che c'è una valanga di programmatori, me compreso, che non è disposta a perdere ore a "farsi la mano".

(sono un utente vim, ma glisso sull'argomento... )

Originariamente inviato da !k-0t1c!

e sono perfettamente d'accordo, le soluzioni possono essere tremendamente diverse, ma ci sono casi come ad esempio funzioni ricorsive dove è necessario passare delle collection dove la sola costruzione e duplicazione della collection (quando non viene modificata dentro alla funzione) causa performance notevolmente inferiori rispetto a una modifica in-place (che mi piace di meno ma a volte fa semplicemente meglio il suo lavoro ).

In quel caso forse si dovrebbe usare una struttura dati persistente, che combina il meglio dei due mondi (immutabilità e velocità d'accesso). Clojure le ha... immagino che anche Haskell le abbia. Rimango dell'idea di Marco... senza vedere il codice è difficile parlare di benchmark.

[mindwings]

Originariamente inviato da !k-0t1c!

Quel che non sembra recepito da tutti gli utendi di EMACS + qualcosa, vi + qualcosa etc è che c'è una valanga di programmatori, me compreso, che non è disposta a perdere ore a "farsi la mano". Una minima parte di operazioni, molto frequenti, si impara a farla con scorciatoie, un'enorme parte di operazioni meno frequenti ma non meno importanti è accelerata infinitamente se l'interfaccia è buona (no, quella di EMACS + qualsiasi cosa non lo è...) e questo migliora enormemente la curva di apprendimento e la rapidità d'utilizzo dell'IDE.

Io non glisso sull'argomento editor (da novizio utente vim) ti diro' l'apprendimento puo' essere graduale quando tu parli di ore perse a farsi la mano e' chiaro che prendi in considerazione solo i vantaggi a breve termine, il sapiente utilizzo di un editor di testo ti permette di essere mooolto piu' veloce/produttivo considerando anche che "We are Typist first, Programmer Second"...
Vim puo' essere integrato anche nei tools che utilizzi per lo sviluppo ti segnalo in proposito 2 progetti:

• Viemu (Prodotti M$) con tanto di cheat sheet
  
• Eclim (Eclipse + Vim)

"Poco poco, piano piano, come piace a noi, non si pensi pacatamente, ma anzi, serenamente"