[Python] [OT]: PHP critique [ERA] Re: Python e html

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 10/12/2011 10:43, enrico franchi ha scritto:
> 
> 
> 2011/12/8 Manlio Perillo <manlio.perillo a gmail.com
> <mailto:manlio.perillo a 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-----