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

enrico franchi enrico.franchi a gmail.com
Gio 8 Dic 2011 10:19:41 CET


2011/12/8 Luciano Tolomei <luciano a tolomei.name>


> Ho sviluppato in php per oltre 10 anni e sinceramente non concordo con la
> discussione che si è sviluppata, e poi con il bel linguaggio che usate che
> ve ne frega ?


Ora io vedo continuamente questa cosa (non solo da te).

"Fila di motivi per cui X non e' un granche'"
"Non sono d'accordo, go ahead, damn the torpedoes!"

Ovviamente nessuno ti viene a dire che non devi usare PHP. Che non puoi
addirittura *amare* (apprezzare, divertirti, ben considerare, verbo a
scelta) PHP.

Il problema e' che le questioni esposte non sono *soggettive*. "Il rosso e'
un brutto colore" "Non sono d'accordo: sono 10 anni che mi vesto di rosso e
mi piace tantissimo". Questo funziona.

Mancano comunque dei punti fermi, il linguaggio è nato per il web e solo
> per quello; quando di MVC per i "siti internet" non ne parlava praticamente
> nessuno.
>

Ehm... WebObject MVC per i siti web ne parlava dalla meta' degli anni 90.
Poi il fatto che costasse un botto e avesse tutte le sue menate non sposta
di molto la faccenda. ;)

Comunque figurati. Io non sono un object zealot. Sono assolutamente
convinto che ci siano pattern appropriati *non* MVC per una serie di casi
di uso reali. Non credo nemmeno che devi per forza scrivere un'applicazione
ad oggetti. Ho visto bellissimi framework web per linguaggi funzionali,
che, per definizione, non erano ad oggetti.

Poi quando sei ad oggetti MVC viene quasi naturale, dal mio punto di vista.
Per inciso... non e' nulla di male: e' solo la composizione di qualche
design pattern dei piu' elementari, mi verrebbe da dire che e' un
comportamento emergente della buona programmazione ad oggetti.


> La discussione sulla somma di numeri e stringhe, sugli include ed i
> require deriva da non capire che il linguaggio è nato pensando che l'unico
> input che poteva ricevere dall'utente era attraverso i campi delle form
> html, quindi solo stringhe, e che il codice era essenzialmente
> impacchettato dentro l html senza usare template:
>

No: non e' questione di non capire. Semplificare il caso semplice e
complicare il caso complicato *non* e' una buona idea di design.

Come dicevo piu' o meno in tutti gli ambienti l'input e' tipicamente
*testo*. Noi umani *usiamo* il testo. Se ti scrivo 1000, sto in realta'
scrivendo del testo. Poi ok, se hai una GUI con validatore cazzi e mazzi
(leggi *explicit* conversion) in realta' ti potrebbe parere di stare
prendendo un numero da me. Ma la realta' dei fatti e' che dall'utente
prendi del testo e poi lo converti.

La maggior parte dei problemi di PHP sono semplicemente mancanza di buon
design. Chi lo progettava non si poneva il problema di non fare scelte che
si erano gia' rivelate errate. In generale credo che parte del problema
fosse che la comunita' non aveva una minima idea di cosa fosse una buona
idea e di cosa fosse una cattiva idea.

E poi anche ammettendo che il design di PHP e' *corretto*, posto il
constraint che sia usato solo per la "Personal Home Page", si deriva che
l'errore non e' di chi lo ha creato, ma di chi lo ha creato per fare cose
piu' grosse. A me sinceramente non cambia molto chi ha sbagliato.

Mi limito a dire che in ogni caso PHP non e' un granche'. E questo
probabilmente non e' un problema... io ci sto lontano e siamo tutti
contenti. ;)

(non svenite dal ridere ma una volta si lavorava a sta maniera)
>

Guarda che abbiamo presente. :)


>  Per le piccole cose che si fanno bene in procedurale sul web penso sia il
> linguaggio più veloce da sviluppare oggi esistente, inoltre nasconde
> completamente qualsiasi problema tecnico all'utente non richiedendo quindi
> nessuna skill da sistemista.
>

Boh? Come dicevo... non mi interessa molto lo use-case "linguaggio in cui
e' piu' semplice scrivere l'hello world". Trovo molto piu' interessante
vedere chi mi da una mano quando ne ho bisogno.

Poi attenzione: skills da sistemista in PHP non richieste se ti danno un
lamp funzionante.



> PhpBB che è il software più bacato che conosca (almeno fino a qualche anno
> fa, non ci ho più messo le mani per fortuna) gestiva senza nessun tipo di
> problema qualche migliaio di utenti contemporanei su un hardware ridicolo,
> lo dico perché sono piuttosto stupito della discussione in parallelo che si
> sta svolgendo tra sync e async ecc...
>

Parte del motivo e' che di fatto gestiva qualche migliaio di utenti che non
facevano "nulla".
Quantifico il "nulla": query molto semplici in lettura e scritture
relativamente semplici.  Buona parte del carico era sul DB. E la
concorrenza la gestiva apache. ;)

Poi voglio dire, gli errori misteriosi che saltavano fuori mi farebbero
escludere il concetto di "senza nessun problema".


>
> Per sviluppare ad oggetti è un po una pena proprio per il lassismo che ha
> sulle formalità, si possono scrivere anche cose di questo tipo:
>
> $p = new $$_GET["pagina"]($_REQUEST);
>
> la differenza la fa sempre lo sviluppatore, che in python trova in parte
> la pappa pronta ed in php deve darsi dei coding standards piuttosto stretti.
>

La differenza la fa lo sviluppatore. Hai ragionissima. Un cattivo
sviluppatore scrivera' PHP anche in Python. Pero' un buon linguaggio ti da
una mano, altro che no! :)

La marea di convenzioni presenti in Python vuole per esempio dire che
prendi una libreria in giro e di solito capisci piu' o meno subito quale e'
la sua logica. Questo fa risparmiare un sacco di tempo.
Per dire in Java trovo spesso librerie molto complete, anche molto testate
e robuste. Ma capire il *come* vanno usate per bene non e' mai
particolarmente semplice, anche perche' spesso non ti danno il rationale
della libreria, ti danno qualche esempio e il javadoc. E informazioni
comparabili in Python sono invece sufficienti, in genere, per capire come
vanno fatte le cose.


Però come si usava dire una volta per andare a fare la spesa la ferrari non
> è la macchina migliore quindi dipende sempre da che cosa si deve fare e chi
> la fa.
>

In generale vero. Pero' come tutte le figure retoriche e' fallata, nel
senso che sarebbe da intendersi quando Python *non va bene* (mentre e'
chiaro quando la Ferrari non va bene -- cioe' praticamente sempre, visto
che beve un sacco di benzina, e' pericoloso lasciarla parcheggiata fuori,
occupa molto spazio in parcheggio, in generale non puoi usare la velocita',
etc etc etc).


> Non penso che la comunità di drupal o i pazzi di pradosoft (tentativo
> molto interessante anche se ormai superato) siano dei masochisti.
>

C'era un detto, citato dallo spocchioso Waldo, che diceva qualcosa tipo
"History justifies stupidity". Ha un paio di interpretazioni diverse. Una
si puo' abbondantemente applicare in questi casi.


> Ma potremmo dire anche Wordpress o Facebook che sono entrambi in php.
>

Questa cosa di "Facebook" in PHP andrebbe un po' sfatata. Parte di Facebook
e' in PHP. E si trovano in giro i post degli engineers di Facebook che si
lamentano della scelta.

Poi aggiungo... ridurre il problema "Facebook" al front-end mi sembra un
po' tanto ingenuo. Non vorrei dire, ma buona parte dei loro problemi non
sono di programmazione, ma di sistema (ovvero fare scalare tutta quella
roba, propagare i dati, etc etc etc).





>
>

>
> 2011/12/7 Marco Mariani <birbag a gmail.com>
>
>> Nessuno, ovvio.
>>
>> _______________________________________________
>> Python mailing list
>> Python a lists.python.it
>> http://lists.python.it/mailman/listinfo/python
>>
>>
>
> _______________________________________________
> Python mailing list
> Python a lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>


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


Maggiori informazioni sulla lista Python