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

[enrico franchi]

2011/12/7 Andrea Francia <andrea a andreafrancia.it>


> Per quanto mi riguarda cerco di usare quello che mi sembra risolvere
> meglio il problema e adoro imparare linguaggi nuovi.
>

Eh, il problema e' che ci sono linguaggi che ti fanno crescere (e che poi
magari hanno possibilità 0 di essere applicati nella tua realtà produttiva)
e linguaggi che non lo fanno. In particolare PHP e' un linguaggio che non
ti aggiunge *niente* (questo perche' e' molto povero di features). Presente
Perlis? ;)


> Anch'io non capivo il senso dell'esistenza del '.' per concatenare le
> stringhe, poi me l'hanno spiegato.
> PHP è stato fatto per scrivere veloci script web. Tutti i parametri che ti
> arrivano dal client web (per esempio come parametri della GET o della POST)
> sono stringhe.
>

Fermo...

1. la quasi totalità dei programmi (in ogni linguaggio) per la maggior
parte delle volte prendono l'input come stringhe di testo. In PHP ti
arrivano dal client web come stringhe. In linguaggi meno web-oriented ti
arrivano come input dall'utente (eventualmente da una unixiana
concatenazione di stdout-stdin) o da file di testo. E sono testo. Sono
"sempre" testo.

2. Il fatto che le stringhe si concatenino con il . viene dal Perl, mica da
nient'altro. Non e' che la concatenazione di stringhe si faccia con . per
altri motivi. E Perl era un linguaggio "nato" per manipolare files di testo
e simili.

3. Il problema non e' che usi . per concatenare stringhe. Quella e' una
scelta come un altra. In particolare, considerando che (strings, .) e' un
monoide nemmeno abeliano a me non da particolarmente fastidio il fatto di
*non* usare il simbolo +, che mi viene da associare ad una struttura di
gruppo abeliano. Accetto la scelta di usare + anche per quello sulla base
di non proliferare i simboli, sul fatto che probabilmente non fa troppo
danno e fine della storia.

4. Il problema e' che le conversioni implicite sono *male*. E' una cosa
nota: lo sbattimento (specie in un linguaggio dinamico) di avere
conversioni esplicite e' relativamente piccolo. Diventa pesante solo se
devi gestire tutti i tipi numerici, ma li le regole sono abbastanza ovvie e
riesci a farle in modo non troppo non intuitivo -- e ribadisco, non farlo
sarebbe peggio --.

Per il resto convertire una stringa in un numero prima di sommarla non mi
riesce a sembrare un problema. E' anzi un'ottima idea, per come la vedo io.

Nota: le conversioni implicite danno problemi ovunque siano state applicate
(a volte anche con i semplici numeri, quelle che avevo definito "buone" due
paragrafi sopra).

Pensa al C++ e alla necessità di introdurre la keyword "explicit" perche'
avere il costruttore di un parametro che ti auto-converte tutto portava
problemi a non finire. Tanto che lo "standard" e' di dare explicit tutti i
costruttori di un solo parametro per cui non si voglia *di certo* che la
conversione sia implicita (e.g., e' comodo che char const* -> std::string
funzioni, ma non e' una conversione logica).

Supponi di dover fare una pagina che stampa la somma di un numero, dovrebbe
> funzionare così:
>
>      $ curl http://mioserver/somma.php?a=10&b=11
>      21
>
> Se hai un linguaggio come php puoi implementarla con (potrei sbagliare la
> sintassi):
>
> print $_REQUEST['a'] +  $_REQUEST['b']
>
> In questo modo non devi fare la conversione stringa->numero e non ottieni
> risultati scorretti come '1011'
>

Pensa che io direi "non ottieni risultati *corretti* come 1011". Saro' old
fashioned, ma se sommo due stringhe mi aspetto che queste vengano
concatenate (se il linguaggio usa il + per la concatenazione) oppure mi dia
errore se non lo fa.

Nota che il "problema" si risolve con due cast espliciti.

Se il "programmatore" non e' in grado di gestire la cosa (cioe' di capire
che se gli arrivano due stringhe prima di sommarle deve convertirle) forse
e' meglio che stia molto lontano da qualunque cosa che possa essere
eseguita. ;)


> Non devi neanche gestire le eccezioni, è chiaro che è molto implicito e
> che sa un po' di quick and dirty, ma
>  1) in alcuni casi non serve
>  2) e se serve allora hai sbagliato linguaggio :-(
>

Non gestire le eccezioni serve quando il linguaggio non gestisce le
eccezioni. Allargando il discorso: "non gestire gli errori" lo puoi fare
solo se hai un linguaggio con filosofie tipo "let it fail" (Erlang), e poi
sono solo certe categorie di errori e, di fatto, e' come avere un certo
sistema di gestione degli errori built-in nella piattaforma.

Per il resto, scusa, ma il "non gestire gli errori" non lo puoi fare.
Ritornare silenziosamente un risultato sbagliato e' infame. Poi posso
capire che non sai cosa fare con un errore (tutta la famosa discussione su
quando e se catturare le eccezioni). Il problema e' che non devono andare
sotto silenzio. A meno che non silenziate esplicitamente. E, aggiungo, se
hai una buona ragione per farlo.

E no... non ho *sbagliato linguaggio*. E' il linguaggio ad essere
sbagliato. Tout court.


> Non voglio assolutamente discutere se questo sia un approccio valido o
> meno, è stata la scelta dei progettisti di PHP che può piacere o non
> piacere.
>

No. E' stata la scelta dei progettisti Perl. E nel contesto di Perl aveva
anche un barlume di senso.


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