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

[enrico franchi]

2011/12/8 Manlio Perillo <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.
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.

Potrei sbagliare. Effettivamente Darcs mi ha messo i brividi. Comunque
Haskell e' in crescita. Vediamo cosa succedera'.


> La lazyness che è non banale da controllare (però le strutture dati lazy
> mi piacciono perchè le vedo come una generalizzazione dei generatori), e
> il voler tenere a tutti i costi separato l'I/O dal resto porta a
> complicazioni che si potevano evitare (credo sia più pratico l'approccio
> di SML e/o Ocaml).
>

Ah... beh, la laziness non ho finito di decidere se mi piace. Le strutture
dati lazy credo che siano molto piu' di una generalizzazione dei
generatori. Sono la logica conclusione di un modo di programmare
dichiarativo.

Se sei veramente dichiarativo, perdi il concetto di "prima e dopo" che hai
nella programmazione imperativa. In questo senso semplicemente definisci le
cose. Se sei lazy, sei appunto 1-1 con la definizione. Perche' non hai il
passaggio intermedio di "costruisco una lista cons-ando questo elemento con
la lista costruita...".

Hai semplicemente "la mia lista e' la lista tale che ...".

E cosi' via con tutte le strutture dati del caso.

Il problema e' che essenzialmente questo stile funziona molto bene per
modellizzare cose che effettivamente non hanno il prima e il dopo. Quando
hai il prima e il dopo sono d'accordo con te: hai complicazioni. Perche'
devi modellare una cosa che prima era invece implicita nel modello (eseguo
questo, poi questo).

In un programma "normale" il prima e il dopo sono gia' parte della
semantica del linguaggio. In haskell devi modellarli esplicitamente. Guarda
caso la semantica denotazionale e' una palla per i fatti suoi, scriverci
programmi puo' essere veramente pesante. ma ancora, forse sono io che non
mangio abbastanza haskell.

Riguardo alle "inutili" complicazioni... se sei lazy, non puoi avere IO.
Cioe' sarebbe troppo poco intuitivo.

Ti troveresti subito con troppa roba sorprendente. Per inciso, e' anche un
plus su STM.

In Clojure ho STM e infatti dicono chiaro e tondo di non fare IO dentro le
transazioni. Se no, ovviamente, stampa apparentemente a caso (ovvero, l'IO
non e' trasparente rispetto alle transazioni).

In particolare in Haskell sei costretto a crearti (e definire con
> precisione) i tuoi pattern (Monadi) molto più spesso che in altri
> linguaggi. Magari è un pregio, ma per programmatori normali è un difetto.
>

Quoto. Immagino che imparando diventa piu' leggero.

Guarda, essendo in contatto con un sacco di gente che sta imparando a
programmare ad oggetti, vedo una cosa simile. Si devono definire i loro
pattern per scrivere codice sensato (per assurdo il procedurale puro e'
"piu' semplice" dal punto di vista di non ciccare le astrazioni).

Solo che quello noi tendiamo a non contarlo perche' abbiamo gia' imparato.

Poi sono d'accordo: non oso pensare cosa capiterebbe ad imparare da 0 con
Haskell, magari da parte di uno non eccessivamente brillante.


>
> Sto cominciando a studiare altri linguaggi funzionali come SML e OCaml,
> ma il mancato supporto alle Type Classes di Haskell non me li fa
> apprezzare.
>

Beh, sono piu' vecchiotti sotto tanti punti di vista. SML poi cerca di
rimanere molto piccolino.
A proposito... F#? Dovrebbe andare benino.


> >  Clojure.
>
> Piace anche a me, ma è ancora troppo giovane.
>

Quoto. Ci sono ancora tante cose che devono finire di aggiustare.


> 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...




> > IMHO i campi dove Python davvero spacca sono:
> > 1. calcolo scientifico (c'e' di tutto, altissima qualita', ottime
> > performance,
>
> Non dimentichiamo però che le performance dipendono dai vari "core"
> scritti in C.
>

O addirittura in Fortan. Mi sembra inevitabile! :)

Basta che fai qualcosa di non standard (vedi post di qualche tempo fa
> riguardo la scarsa efficienza quando il codice scritto in C deve
> chiamare codice scritto in Python nel main loop dell'algoritmo),
> e cominci ad avere problemi.
>

Pero' attenzione... chiamare Python da C non e' uno use-case comunissimo.
Nel caso di Numpy per dire, al limite da C chiamero' le stesse librerie
C/Fortran su cui si appoggia numpy.

Poi voglio dire... di fatto Matlab, al di la della sintassi ben piu'
merdosa, fa esattamente questo. Scrivere estensioni in C per Matlab pure
non e' una passeggiata. E, come dicevo, va bene.

Sono d'accordo che per fare scientifico sarebbe bello avere un linguaggio
comodo come Python e veloce come C. Ma apparentemente non esiste. :)
Con il risultato che il miglior compromesso al momento disponibile sia
usare un linguaggio espressivo e chiamare cores molto veloci.

Aggiungo poi... buona parte dei problemi di performance con Python+Numpy o
matlab sono dovuti al fatto che non si e' scritto codice con il classico
stile matriciale per cui sono pensati. Se cominci a smontare e rimontare le
matrici tutte le volte, ovviamente vai piano.

Tornando poi a noi, con pypy che avanza, credo che anche molte di queste
cose andranno parzialmente scomparendo.


> 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. 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.

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.

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.

-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20111210/1c6ac731/attachment-0001.html>