-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 10/12/2011 10:43, enrico franchi ha scritto: > > > 2011/12/8 Manlio Perillo <manlio.peri...@gmail.com > <mailto:manlio.peri...@gmail.com>> > > A me proprio non piace. > Mi piace invece il suo modello della concorrenza, e la robustezza del > suo runtime. > > > Beh, di quello che si parla! La sintassi e' semplicemente funzionale a > quello.
Però io sulla sintassi sono abbastanza fissato. Beh, non è detta l'ultima parola: in passato avevo sempre detto che non avrei mai imparato Lisp ed invece... > E si, ci sono alcune menate che rompono le palle (sintattiche e semantiche). > Pero' quello che e' globalmente non mi dispiace. > > > Il problema è che per fare cose pratiche non lo vedo molto bene. > > > Si e no. La mia opinione globale concorda con la tua. Mi chiedo sempre > se il problema fondamentale e' che io non penso in Haskell e di > conseguenza debba tradurre, con ovvi problemi. Quello che io penso, ma > potrei sbagliare, e' che se avessi in Haskell l'esperienza che ho con la > programmazione ad oggetti, sfrutterei al meglio le sue features per > girare intorno ai suoi limiti. Esattamente come faccio con Python. > Si, questo è un ragionamento che faccio spesso anche io. All'inizio ricordo che anche con Python avevo difficoltà (leggendo codice Twisted). Comunque un parere interessante su Haskell (e altro) si trova qui: http://www.bitc-lang.org/docs/bitc/bitc-origins.html > [...] > > Beh, sono piu' vecchiotti sotto tanti punti di vista. SML poi cerca di > rimanere molto piccolino. > A proposito... F#? Dovrebbe andare benino. > Leggendo dei commenti ho letto che è partito bene (OCaml) ma finito male perchè hanno dovuto introdurre alcune idiosincrasie per .NET. Ma dato che F# non l'ho mai nemmeno provato, non ho un parere. L'unico parere (negativo) è che funziona esclusivamente su .NET (ma è così complesso avere qualcosa come PyPy con generatori di codice *e* runtime multipli?) > [...] > E non ha CLOS, mi sembra (però vedo bene le interfacce: in Common Lisp è > abbastanza brutto non averle, e le generic functions non sono usate > molto nello standard - e probabilmente non sono efficienti come una > implementazione semplice come quella in Clojure). > > > Non direi che "non ha CLOS"... cioe', si, non ha CLOS (anche se mi > sembra ci siano implementazioni). > Ma non mi sembra che manchi di particolari features di CLOS a parte > l'ereditarieta' di implementazione (che se mi manca posso comunque avere > passando per il bridge clojure-java). > > Probabilmente mi sfugge qualcosa... > Al momento dovrei controllare, ma mi sembra che Clojure non supporti il dispatch multiplo. > [...] > Sono d'accordo che per fare scientifico sarebbe bello avere un > linguaggio comodo come Python e veloce come C. Ma apparentemente non > esiste. :) Common Lisp? :) > [...] > In casi come questi magari Ocaml o Common Lisp sono una valida > alternativa. > Peccato che Common Lisp che non ha una comunità attivissima (ma in > Maxima, ad esempio, ci sono moltissime cose disponibili) e Ocaml che non > ha un modello di sviluppo "aperto" come quello di Python. > > > Questa e' una possibilita'. Pero' attenzione... Ocaml e' molto veloce, > niente da dire. E a quanto ho letto il generatore di codice non è nemmeno troppo sofisticato per le ottimizzazioni più spinte. > Pero' non mi piace quando va "imperativizzato" per > guadagnare performance. Riguardo Common Lisp, ovviamente in parte hai > ragione. Di per se ce la puo' fare (specie SBCL). Non so pero' come se > la cava con lo smazzamento matriciale. > Li si tratta di avere le giuste librerie. > Anche avere le librerie fa molto: tipo un minimizzatore che va di > gradiente coniugato scritto da me in 10 minuti e scritto in fortran da > persone che ci hanno preso dei mesi e tunato per anni IMHO non e' > paragonabile. Alla fine credo che saremmo sempre a "core in C/Fortran" > chiamate da common lisp. > Si, credo sia inevitabile. Non è pensabile replicare le varie librerie nei vari linguaggi, e sperare che siano tutte efficienti. > E ribadisco, con pypy che spinge, non so quale delle due soluzioni > finirebbe per essere piu' veloce: dopotutto delegando i float a numpy e > facendo gli interi con numpy (cicli e compagnia) c'e' rischio che si > stia prendendo il meglio dei due mondi. > Speriamo. Prima però devono rendere possibile compilare il codice senza avere una workstation con 8GB di RAM... Ciao Manlio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7jTd0ACgkQscQJ24LbaUQ3igCfe8pIlNBnq4ldgsEJog1R8IK8 AisAmQEV2EUnuek9jzRoJ4zxRYaMK2Wi =KG1x -----END PGP SIGNATURE----- _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
