Sabonis
21-06-2009, 23:19
Secondo voi quali tra questi linguaggi sono più interessanti da imparare?
lisp/scheme
erlang
f#
haskell
OCaml
lisp/scheme
erlang
f#
haskell
OCaml
View Full Version : [vari] Linguaggi Funzionali
!k-0t1c!
22-06-2009, 00:14
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.
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
22-06-2009, 09:32
Se sei a digiuno di programmazione funzionale, io partirei da Scheme. Ci sono ottimi (http://www.htdp.org/2003-09-26/Book/) libri (http://mitpress.mit.edu/sicp/full-text/book/book.html) che lo usano come base.
Anche Haskell è interessante, anche se io non riesco a farmelo piacere; c'è un altro ottimo libro qui (http://book.realworldhaskell.org/read/).
Degli altri conosco poco e niente, quindi non mi esprimo.
Se posso aggiungerne uno alla lista, prova Factor (http://www.factorcode.org/). 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 :Prrr:
Anche Haskell è interessante, anche se io non riesco a farmelo piacere; c'è un altro ottimo libro qui (http://book.realworldhaskell.org/read/).
Degli altri conosco poco e niente, quindi non mi esprimo.
Se posso aggiungerne uno alla lista, prova Factor (http://www.factorcode.org/). 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 :Prrr:
^TiGeRShArK^
22-06-2009, 13:45
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.. :stordita: )
..qualche suggerimento per un buon tutorial? :fiufiu:
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.. :stordita: )
..qualche suggerimento per un buon tutorial? :fiufiu:
!k-0t1c!
22-06-2009, 17:02
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.
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^
22-06-2009, 17:12
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. :p
Per Expert F# intendi quello della Apress?
In effetti mi sono sempre trovato bene con i libri di quella casa. :p
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. :p
Per Expert F# intendi quello della Apress?
In effetti mi sono sempre trovato bene con i libri di quella casa. :p
!k-0t1c!
22-06-2009, 17:35
danke. :p
Per Expert F# intendi quello della Apress?
In effetti mi sono sempre trovato bene con i libri di quella casa. :p
Sì, apress :)
E' fatto bene ed anche se è datato è molto esaustivo e 99 volte su 100 ancora attuale.
http://www.amazon.com/Expert-F-Experts-Voice-Net/dp/1590598504
Per Expert F# intendi quello della Apress?
In effetti mi sono sempre trovato bene con i libri di quella casa. :p
Sì, apress :)
E' fatto bene ed anche se è datato è molto esaustivo e 99 volte su 100 ancora attuale.
http://www.amazon.com/Expert-F-Experts-Voice-Net/dp/1590598504
fero86
22-06-2009, 19:36
Sì, apress :)
E' fatto bene ed anche se è datato è molto esaustivo e 99 volte su 100 ancora attuale.
http://www.amazon.com/Expert-F-Experts-Voice-Net/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? :D
datato quanto? datato dell'anno scorso?
te lo chiedo perché sarei interessato anche io all'acquisto di uno o due libri su F#.
E' fatto bene ed anche se è datato è molto esaustivo e 99 volte su 100 ancora attuale.
http://www.amazon.com/Expert-F-Experts-Voice-Net/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? :D
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!
22-06-2009, 19:50
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 ;)
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
22-06-2009, 19:53
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.
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
23-06-2009, 14:22
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 :D. 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# ?
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 :D. 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
23-06-2009, 14:34
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.
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!
23-06-2009, 14:38
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...:D
Uhm, io direi che e' invece un numero tirato a caso :D. 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...
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...:D
Uhm, io direi che e' invece un numero tirato a caso :D. 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
23-06-2009, 15:23
Peccato che rimane in ambito M$ questo F#... Clojure (http://clojure.org)? Non se lo fila nessuno?:D - 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 :p e non ho avuto particolari rogne con le parentesi...
shinya
23-06-2009, 16:45
Peccato che rimane in ambito M$ questo F#... Clojure (http://clojure.org)? Non se lo fila nessuno?:D
Emh... veramente io avevo postato il link ad un bel tutorial tempo fa (che si, non si è cagato quasi nessuno :p), perchè penso che Clojure abbia delle buone idee.
Emh... veramente io avevo postato il link ad un bel tutorial tempo fa (che si, non si è cagato quasi nessuno :p), perchè penso che Clojure abbia delle buone idee.
marco.r
23-06-2009, 17:10
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...:D
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.
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...:D
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
23-06-2009, 17:13
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
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!
24-06-2009, 10:09
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...
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.
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 :().
Usato molto al Credit Suisse, usato per i servizi online XBox, etc. Questo al giorno d'oggi, che è ancora in CTP...
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.
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
24-06-2009, 10:20
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... :p)
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.
(sono un utente vim, ma glisso sull'argomento... :p)
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
24-06-2009, 12:52
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 :D (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" (http://www.codinghorror.com/blog/archives/001188.html)...
Vim puo' essere integrato anche nei tools che utilizzi per lo sviluppo ti segnalo in proposito 2 progetti:
Viemu (http://www.viemu.com/) (Prodotti M$) con tanto di cheat sheet (http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html)
Eclim (http://eclim.sourceforge.net/) (Eclipse + Vim)
http://www.gianfrancobutinar.it/110percento/img/marzullo.gif
"Poco poco, piano piano, come piace a noi, non si pensi pacatamente, ma anzi, serenamente"
Io non glisso sull'argomento editor :D (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" (http://www.codinghorror.com/blog/archives/001188.html)...
Vim puo' essere integrato anche nei tools che utilizzi per lo sviluppo ti segnalo in proposito 2 progetti:
Viemu (http://www.viemu.com/) (Prodotti M$) con tanto di cheat sheet (http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html)
Eclim (http://eclim.sourceforge.net/) (Eclipse + Vim)
http://www.gianfrancobutinar.it/110percento/img/marzullo.gif
"Poco poco, piano piano, come piace a noi, non si pensi pacatamente, ma anzi, serenamente"
marco.r
26-06-2009, 19:24
Usato molto al Credit Suisse, usato per i servizi online XBox, etc. Questo al giorno d'oggi, che è ancora in CTP...
Se e' per quello al Credit Suisse usano molto anche haskell, in ogni caso e' quell'etc. che mi lascia perplesso :D
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 a' pprendimento e la rapidità d'utilizzo dell'IDE.
Un cheat-sheet di emacs per le funzionalita' di base son quattro facciate, non ci si mette ore a leggerlo. Il farsi la mano e' riferito al fatto che i keybinding standard sono abbastanza particolari per chi non e' abituato e ci vuole un po' di giorni per cominciare ad abituarsi ad usare (ad esempio) ctrl-x-s per salvare invece che il ctrl-s "standard". In ogni caso la versione gtk di emacs ha i menu con gli shortcut evidenziati tanto quanto un ide normale. C'e' chi ci si trova e chi no, a me piace e ci sono alcune funzionalita' che raramente hanno riscontro in ide piu' standard, come keyboard macro, skeletons e integrazione con i tool piu' disparati, da jabber al version control.
Devo aver dimenticato il link che avevo trovato di un caso in cui questo vale:
http://markmail.org/message/dl7xwdevzcnwvcbi
li' si parla di un altro problema, ovvero che in haskell le performance sugli array erano abbastanza penose; comunque in entrambi i casi stavano procedento in modo decisamente imperativo. Da una prova rapida comunque sembra adesso haskell se la cavi meglio, visto che una prova di somme su array fatta al volo va dieci volte piu' lento rispetto al C, e una versione CL ottiene invece le stesse performance del C (non penso sia interessante, posso comunque riportare il codice).
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 :().
Perche' sei costretto a lavorare con librerie pensate per un uso orientato agli oggetti, non funzionale. E' il problema dei linguaggi funzionali basati su .NET o sulla JVM: un sacco di librerie, ma nessuna funzionale.
In altri linguaggi con librerie proprie il problema si sente meno. E in quelli lazy ancora meno perche' in molti casi si riesce ad organizzare in modo diverso il problema ad un livello piu' alto.
Se e' per quello al Credit Suisse usano molto anche haskell, in ogni caso e' quell'etc. che mi lascia perplesso :D
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 a' pprendimento e la rapidità d'utilizzo dell'IDE.
Un cheat-sheet di emacs per le funzionalita' di base son quattro facciate, non ci si mette ore a leggerlo. Il farsi la mano e' riferito al fatto che i keybinding standard sono abbastanza particolari per chi non e' abituato e ci vuole un po' di giorni per cominciare ad abituarsi ad usare (ad esempio) ctrl-x-s per salvare invece che il ctrl-s "standard". In ogni caso la versione gtk di emacs ha i menu con gli shortcut evidenziati tanto quanto un ide normale. C'e' chi ci si trova e chi no, a me piace e ci sono alcune funzionalita' che raramente hanno riscontro in ide piu' standard, come keyboard macro, skeletons e integrazione con i tool piu' disparati, da jabber al version control.
Devo aver dimenticato il link che avevo trovato di un caso in cui questo vale:
http://markmail.org/message/dl7xwdevzcnwvcbi
li' si parla di un altro problema, ovvero che in haskell le performance sugli array erano abbastanza penose; comunque in entrambi i casi stavano procedento in modo decisamente imperativo. Da una prova rapida comunque sembra adesso haskell se la cavi meglio, visto che una prova di somme su array fatta al volo va dieci volte piu' lento rispetto al C, e una versione CL ottiene invece le stesse performance del C (non penso sia interessante, posso comunque riportare il codice).
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 :().
Perche' sei costretto a lavorare con librerie pensate per un uso orientato agli oggetti, non funzionale. E' il problema dei linguaggi funzionali basati su .NET o sulla JVM: un sacco di librerie, ma nessuna funzionale.
In altri linguaggi con librerie proprie il problema si sente meno. E in quelli lazy ancora meno perche' in molti casi si riesce ad organizzare in modo diverso il problema ad un livello piu' alto.
javaboy
26-06-2009, 20:03
Se e' per quello al Credit Suisse usano molto anche haskell, in ogni caso e' quell'etc. che mi lascia perplesso :D
.
Haskell??? Mi dici qualcosa di più?
E' bello sapere che al mondo c'è qualcosa oltre a java e php...
.
Haskell??? Mi dici qualcosa di più?
E' bello sapere che al mondo c'è qualcosa oltre a java e php...
cdimauro
27-06-2009, 08:12
Perche' sei costretto a lavorare con librerie pensate per un uso orientato agli oggetti, non funzionale. E' il problema dei linguaggi funzionali basati su .NET o sulla JVM: un sacco di librerie, ma nessuna funzionale.
In altri linguaggi con librerie proprie il problema si sente meno. E in quelli lazy ancora meno perche' in molti casi si riesce ad organizzare in modo diverso il problema ad un livello piu' alto.
Se può interessare: Functional Programming HOWTO (http://docs.python.org/dev/howto/functional.html).
In altri linguaggi con librerie proprie il problema si sente meno. E in quelli lazy ancora meno perche' in molti casi si riesce ad organizzare in modo diverso il problema ad un livello piu' alto.
Se può interessare: Functional Programming HOWTO (http://docs.python.org/dev/howto/functional.html).
^TiGeRShArK^
27-06-2009, 11:38
ecco..
per esempio una cosa che non mi cala proprio della sintassi di python sono le generator expression e le list comprehension.... :fagiano:
scrivere questo codice:
line_list = [' line 1\n', 'line 2 \n', ...]
stripped_iter = (line.strip() for line in line_list)
stripped_list = [line.strip() for line in line_list]
lo trovo poco leggibile dato che prima mette l'azione, poi l'elemento e poi la lista....
secondo me per essere + leggibile dovrebbe avere prima l'elemento su cui si opera....
F# d'altro canto estremizza ancora di + questo concetto permettendo addirittura di fare l'esatto contrario:
let stripped_list = list |> String.split(' ')
praticamente invia la lista alla funzione String.split e applica ad ogni elemento la funzione.
personalmente mi piace di questa soluzione, dato che in taluni casi (tipo la concatenazione di funzioni) la arrivo a preferire rispetto al codice classico in C# ad esempio:
var stripped_list = list.Select(e => e.split(' '));
poi ovviamente dipende dai gusti, ma mi sa che sapere subito qual'è l'oggetto su cui applicare la funzione è meglio rispetto a conoscere prima la funzione che viene applicata. :p
per esempio una cosa che non mi cala proprio della sintassi di python sono le generator expression e le list comprehension.... :fagiano:
scrivere questo codice:
line_list = [' line 1\n', 'line 2 \n', ...]
stripped_iter = (line.strip() for line in line_list)
stripped_list = [line.strip() for line in line_list]
lo trovo poco leggibile dato che prima mette l'azione, poi l'elemento e poi la lista....
secondo me per essere + leggibile dovrebbe avere prima l'elemento su cui si opera....
F# d'altro canto estremizza ancora di + questo concetto permettendo addirittura di fare l'esatto contrario:
let stripped_list = list |> String.split(' ')
praticamente invia la lista alla funzione String.split e applica ad ogni elemento la funzione.
personalmente mi piace di questa soluzione, dato che in taluni casi (tipo la concatenazione di funzioni) la arrivo a preferire rispetto al codice classico in C# ad esempio:
var stripped_list = list.Select(e => e.split(' '));
poi ovviamente dipende dai gusti, ma mi sa che sapere subito qual'è l'oggetto su cui applicare la funzione è meglio rispetto a conoscere prima la funzione che viene applicata. :p
javaboy
27-06-2009, 22:50
Non ho mai lavorato seriamente con un linguaggio funzionale ma ho la sensazione che in molti casi si potrebbe essere più produttivi che con un tradizionale linguaggio ad oggetti. Certamente il codice funzionale è meno error prone...
Se solo le aziende sperimentassero un pò.....
Se solo le aziende sperimentassero un pò.....
^TiGeRShArK^
28-06-2009, 01:31
Non ho mai lavorato seriamente con un linguaggio funzionale ma ho la sensazione che in molti casi si potrebbe essere più produttivi che con un tradizionale linguaggio ad oggetti. Certamente il codice funzionale è meno error prone...
Se solo le aziende sperimentassero un pò.....
dipende..
nel caso del PLINQ hai un rapporto qualità/tempo inarrivabile dato che puoi adattare del codice funzionale esistente in modo da fargli utilizzare un numero di thread ottimale per il processore su cui esegui il programma spesso con una sola istruzione aggiuntiva.
In generale io lo trovo in molti casi + leggibile rispetto al classico codice ad oggetti.
Ma, ovviamente, la massima "the right tool for the right job" è SEMPRE valida.
Non per niente nell'ultimo contest, tanto per fare un esempio pratico, ho scritto la prima parte in funzionale dichiarativo puro tramite LINQ e la seconda parte in maniera imperativa. :p
Utilizzare SEMPRE un funzionale puro per me è anzi controproducente, non per niente Haskell mi sta molto meno simpatico rispetto a F# e a C# (che con LINQ dal .net framework 3.0 in poi è a tutti gli effetti un linguaggio anche funzionale).
Se solo le aziende sperimentassero un pò.....
dipende..
nel caso del PLINQ hai un rapporto qualità/tempo inarrivabile dato che puoi adattare del codice funzionale esistente in modo da fargli utilizzare un numero di thread ottimale per il processore su cui esegui il programma spesso con una sola istruzione aggiuntiva.
In generale io lo trovo in molti casi + leggibile rispetto al classico codice ad oggetti.
Ma, ovviamente, la massima "the right tool for the right job" è SEMPRE valida.
Non per niente nell'ultimo contest, tanto per fare un esempio pratico, ho scritto la prima parte in funzionale dichiarativo puro tramite LINQ e la seconda parte in maniera imperativa. :p
Utilizzare SEMPRE un funzionale puro per me è anzi controproducente, non per niente Haskell mi sta molto meno simpatico rispetto a F# e a C# (che con LINQ dal .net framework 3.0 in poi è a tutti gli effetti un linguaggio anche funzionale).
marco.r
28-06-2009, 03:04
Se può interessare: Functional Programming HOWTO (http://docs.python.org/dev/howto/functional.html).
E' un buon punto di partenza, ma la strada e' ancora lunga :P.
Giusto per chiarire, mi riferisco alla presenza di strutture dati tipo quelle descritte qui:
www.cs.cmu.edu/~rwh/theses/okasaki.pdf
(ad esempio il cap 5).
Ovvero intendo la possibilita' di lavorare su strutture dati "comuni" (alberi tabelle hash etc) senza effetti collaterali.
E' un buon punto di partenza, ma la strada e' ancora lunga :P.
Giusto per chiarire, mi riferisco alla presenza di strutture dati tipo quelle descritte qui:
www.cs.cmu.edu/~rwh/theses/okasaki.pdf
(ad esempio il cap 5).
Ovvero intendo la possibilita' di lavorare su strutture dati "comuni" (alberi tabelle hash etc) senza effetti collaterali.
marco.r
28-06-2009, 03:07
Haskell??? Mi dici qualcosa di più?
E' bello sapere che al mondo c'è qualcosa oltre a java e php...
Se parli di utilizzo nel mondo reale trovi un po' di notizie sul sito ufficiale di haskell ( http://www.haskell.org/haskellwiki/Haskell_in_industry) . Se invece intendi altro... chiarisci, che non ho capito :D
E' bello sapere che al mondo c'è qualcosa oltre a java e php...
Se parli di utilizzo nel mondo reale trovi un po' di notizie sul sito ufficiale di haskell ( http://www.haskell.org/haskellwiki/Haskell_in_industry) . Se invece intendi altro... chiarisci, che non ho capito :D
javaboy
28-06-2009, 10:35
dipende..
nel caso del PLINQ hai un rapporto qualità/tempo inarrivabile dato che puoi adattare del codice funzionale esistente in modo da fargli utilizzare un numero di thread ottimale per il processore su cui esegui il programma spesso con una sola istruzione aggiuntiva.
In generale io lo trovo in molti casi + leggibile rispetto al classico codice ad oggetti.
Ma, ovviamente, la massima "the right tool for the right job" è SEMPRE valida.
Non per niente nell'ultimo contest, tanto per fare un esempio pratico, ho scritto la prima parte in funzionale dichiarativo puro tramite LINQ e la seconda parte in maniera imperativa. :p
Utilizzare SEMPRE un funzionale puro per me è anzi controproducente, non per niente Haskell mi sta molto meno simpatico rispetto a F# e a C# (che con LINQ dal .net framework 3.0 in poi è a tutti gli effetti un linguaggio anche funzionale).
Concordo....purtroppo i linguaggi funzionali vengono ignorati anche quando sono "the right tool for the right job"....
Senza dubbio in molti casi sono più adatti i linguaggi ad oggetti anche se ti devo confessare che la mia breve esperienza amatoriale con erlang mi sta facendo innamorare dei linguaggi funzionali: erlang è semplice da apprendere, elegante, conciso e divertente da utilizzare.
Peccato per la gestione delle stringhe e per la libreria standard non all'altezza....come vorrei che creassero un bel linguaggio E#
nel caso del PLINQ hai un rapporto qualità/tempo inarrivabile dato che puoi adattare del codice funzionale esistente in modo da fargli utilizzare un numero di thread ottimale per il processore su cui esegui il programma spesso con una sola istruzione aggiuntiva.
In generale io lo trovo in molti casi + leggibile rispetto al classico codice ad oggetti.
Ma, ovviamente, la massima "the right tool for the right job" è SEMPRE valida.
Non per niente nell'ultimo contest, tanto per fare un esempio pratico, ho scritto la prima parte in funzionale dichiarativo puro tramite LINQ e la seconda parte in maniera imperativa. :p
Utilizzare SEMPRE un funzionale puro per me è anzi controproducente, non per niente Haskell mi sta molto meno simpatico rispetto a F# e a C# (che con LINQ dal .net framework 3.0 in poi è a tutti gli effetti un linguaggio anche funzionale).
Concordo....purtroppo i linguaggi funzionali vengono ignorati anche quando sono "the right tool for the right job"....
Senza dubbio in molti casi sono più adatti i linguaggi ad oggetti anche se ti devo confessare che la mia breve esperienza amatoriale con erlang mi sta facendo innamorare dei linguaggi funzionali: erlang è semplice da apprendere, elegante, conciso e divertente da utilizzare.
Peccato per la gestione delle stringhe e per la libreria standard non all'altezza....come vorrei che creassero un bel linguaggio E#
fero86
28-06-2009, 12:32
come vorrei che creassero un bel linguaggio E# un altro F#? a che scopo?
javaboy
28-06-2009, 12:36
un altro F#? a che scopo?
Non avrebbe scopo, anzi forse sarebbe controproducente per la Microsoft.
A me personalmente invece sarebbe piaciuto tantissimo un linguaggio .net ispirato a erlang e non a ocaml.
Non avrebbe scopo, anzi forse sarebbe controproducente per la Microsoft.
A me personalmente invece sarebbe piaciuto tantissimo un linguaggio .net ispirato a erlang e non a ocaml.
cdimauro
29-06-2009, 08:36
ecco..
per esempio una cosa che non mi cala proprio della sintassi di python sono le generator expression e le list comprehension.... :fagiano:
scrivere questo codice:
line_list = [' line 1\n', 'line 2 \n', ...]
stripped_iter = (line.strip() for line in line_list)
stripped_list = [line.strip() for line in line_list]
lo trovo poco leggibile dato che prima mette l'azione, poi l'elemento e poi la lista....
secondo me per essere + leggibile dovrebbe avere prima l'elemento su cui si opera....
E' una sintassi che rispecchia quella classica che si ritrova in matematica.
Sicuramente qualcosa del tipo
[for line in line_list return line.strip()]
sarebbe stato più abbordabile per chiunque, ma penso che nella scelta della sintassi sia ricaduta la similitudine con altri linguaggi funzionali che implementano meccanismi di questo tipo.
F# d'altro canto estremizza ancora di + questo concetto permettendo addirittura di fare l'esatto contrario:
let stripped_list = list |> String.split(' ')
praticamente invia la lista alla funzione String.split e applica ad ogni elemento la funzione.
personalmente mi piace di questa soluzione, dato che in taluni casi (tipo la concatenazione di funzioni) la arrivo a preferire rispetto al codice classico in C# ad esempio:
var stripped_list = list.Select(e => e.split(' '));
poi ovviamente dipende dai gusti, ma mi sa che sapere subito qual'è l'oggetto su cui applicare la funzione è meglio rispetto a conoscere prima la funzione che viene applicata. :p
Concordo.
E' un buon punto di partenza, ma la strada e' ancora lunga :P.
Giusto per chiarire, mi riferisco alla presenza di strutture dati tipo quelle descritte qui:
www.cs.cmu.edu/~rwh/theses/okasaki.pdf
(ad esempio il cap 5).
Ovvero intendo la possibilita' di lavorare su strutture dati "comuni" (alberi tabelle hash etc) senza effetti collaterali.
Cioé senza modifiche allo "stato" degli oggetti, immagino. Il problema è che tante volte... è troppo semplice e comoda la soluzione non puramente funzionale. :fagiano:
Comunque nel codice che ho sviluppato ho aggiunto una funzioncina che prende tutti gli oggetti delle librerie itertools e functools, e li inserisce nel modulo builtins per renderli immediatamente accessibili (senza effettuare import); solo che, a parte le funzioni "partial" e "wraps", non ho mai usato altro.
Non so, non riesco a pensare di utilizzare gli altri strumenti che mi portano a sviluppare codice in ottica funzionale.
Magari è per il tipo di codice che scrivo, ma al momento le cose più interessanti che utilizzo sono le comprehension e i decoratori...
per esempio una cosa che non mi cala proprio della sintassi di python sono le generator expression e le list comprehension.... :fagiano:
scrivere questo codice:
line_list = [' line 1\n', 'line 2 \n', ...]
stripped_iter = (line.strip() for line in line_list)
stripped_list = [line.strip() for line in line_list]
lo trovo poco leggibile dato che prima mette l'azione, poi l'elemento e poi la lista....
secondo me per essere + leggibile dovrebbe avere prima l'elemento su cui si opera....
E' una sintassi che rispecchia quella classica che si ritrova in matematica.
Sicuramente qualcosa del tipo
[for line in line_list return line.strip()]
sarebbe stato più abbordabile per chiunque, ma penso che nella scelta della sintassi sia ricaduta la similitudine con altri linguaggi funzionali che implementano meccanismi di questo tipo.
F# d'altro canto estremizza ancora di + questo concetto permettendo addirittura di fare l'esatto contrario:
let stripped_list = list |> String.split(' ')
praticamente invia la lista alla funzione String.split e applica ad ogni elemento la funzione.
personalmente mi piace di questa soluzione, dato che in taluni casi (tipo la concatenazione di funzioni) la arrivo a preferire rispetto al codice classico in C# ad esempio:
var stripped_list = list.Select(e => e.split(' '));
poi ovviamente dipende dai gusti, ma mi sa che sapere subito qual'è l'oggetto su cui applicare la funzione è meglio rispetto a conoscere prima la funzione che viene applicata. :p
Concordo.
E' un buon punto di partenza, ma la strada e' ancora lunga :P.
Giusto per chiarire, mi riferisco alla presenza di strutture dati tipo quelle descritte qui:
www.cs.cmu.edu/~rwh/theses/okasaki.pdf
(ad esempio il cap 5).
Ovvero intendo la possibilita' di lavorare su strutture dati "comuni" (alberi tabelle hash etc) senza effetti collaterali.
Cioé senza modifiche allo "stato" degli oggetti, immagino. Il problema è che tante volte... è troppo semplice e comoda la soluzione non puramente funzionale. :fagiano:
Comunque nel codice che ho sviluppato ho aggiunto una funzioncina che prende tutti gli oggetti delle librerie itertools e functools, e li inserisce nel modulo builtins per renderli immediatamente accessibili (senza effettuare import); solo che, a parte le funzioni "partial" e "wraps", non ho mai usato altro.
Non so, non riesco a pensare di utilizzare gli altri strumenti che mi portano a sviluppare codice in ottica funzionale.
Magari è per il tipo di codice che scrivo, ma al momento le cose più interessanti che utilizzo sono le comprehension e i decoratori...
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.