Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Finalmente siamo riusciti a farci sistemare parte della casa, nello specifico la parte in cui io solitamente registro.
Quindi, finalmente, posso ridare a pensieri in codice la giusta qualità audio che secondo me merita.
Dunque, iniziamo il 2025 con un episodio che avevo in mente di fare da parecchio,
(00:21):
dato che l'argomento di cui parleremo salta fuori spesso nel gruppo Telegram del podcast.
Come? Non conosci il gruppo Telegram di Pensieri in Codice? Male, molto male.
Corri subito su pensierincodice.it e clicca sul link apposito, oppure circa Pensieri in Codice direttamente su Telegram.
Fidati, ne vale la pena. Il gruppo è pieno di argomenti e persone interessanti, quindi fallo subito, mi raccomando.
(00:47):
Ad ogni modo, dicevo che, periodicamente, nella community,
il discorso ricade su un certo linguaggio di programmazione del quale tutti,
o quasi, si lamentano.
È orribile, fa schifo, non si può usare.
Per un verso so che nel gruppo lo fanno apposta, perché sanno che è il linguaggio che uso per lavoro e sono dei rompiscatole.
(01:10):
Ma, d'altra parte, so bene che là fuori c'è veramente tanta gente che lo odia,
lo ritiene un problema e lo denigra ad ogni occasione.
Per questo motivo, ho deciso di approfondire un po' la questione e fare un po' di riflessioni in stile pensieristico.
Pensieri in codice.
Quindi, in questo episodio parliamo di PHP.
(01:31):
Ma non delle ultime novità o delle varie versioni, 8.3, 8.4, no.
Oggi parliamo del perché tutti odiano PHP.
Benvenuti su Pensieri in Codice, il podcast dove si ragiona da informatici.
Con Valerio Galano.
(01:52):
Partiamo da un fatto.
PHP è uno dei linguaggi di programmazione più odiati di sempre.
Prova ad entrare in una stanza piena di programmatori e chiedere che cosa non va nel PHP.
La maggior parte di loro si alzerà e inizierà ad elencarti una sfilza di ragioni per le quali il linguaggio è scadente,
(02:18):
non andrebbe usato, addirittura andrebbe estirpato.
PHP è un linguaggio caotico, le funzioni di base sono incoerenti.
È troppo facile da usare, quindi tanti programmatori alle prime armi producono pessimo codice,
non ha degli standard ben definiti, ha pessime performance, soffre di problemi di sicurezza.
(02:42):
Ho mancato qualcosa?
Probabilmente sì, ma in ogni caso sono abbastanza sicuro che queste siano un problema.
Un esempio realistico delle critiche che normalmente vengono mosse a PHP.
Sono tutti punti interessanti, certo, alcuni validi, altri meno.
Ne potremmo discutere per ore senza arrivare ad una conclusione soddisfacente
(03:07):
e probabilmente lo hanno già fatto tanti altri in modo più esaustivo di quanto potrei fare io.
Quindi non mi interessa aggiungere altro rumore all'argomento.
Ciò che invece vorrei fare oggi
è provare a portare avanti un discorso un po' più ampio,
provare ad analizzare e comprendere le radici di tutte queste motivazioni di odio verso il PHP
(03:32):
e provare a contestualizzarle e discuterne.
Ci stai?
Iniziamo.
Siamo nel 1994 e un programmatore danese di nome Rasmus Lerdorf
sviluppa una piccola suite di strumenti software
basata sul linguaggio C
che gli serve per semplificare la gestione del proprio sito web personale.
(03:57):
Il lavoro di Rasmus non è minimamente pensato per diventare un nuovo linguaggio di programmazione.
È solo un espediente per soddisfare delle necessità che ha al momento.
Non è stato accuratamente progettato né tantomeno realizzato guardando al futuro.
(04:18):
Fatto sta che,
dopo circa un anno,
Rasmus decide,
come facciamo in tanti anche oggi,
di rilasciare gratuitamente il codice sorgente della sua suite
sotto il nome di PHP Tools,
che sta per Personal Home Page Tools.
La funzionalità all'epoca è quella di tracciare le visite di un sito.
(04:42):
In quel momento,
il nome PHP viene soppiantato da FI,
che sta per Forms,
Interpreter,
ma questa nuova nomenclatura non dura molto.
Quello stesso anno,
più precisamente nel settembre del 1995,
il programmatore decide però di aggiungere alcune funzionalità che gli risultano comode,
(05:06):
tra cui l'interpretazione delle variabili dei form e la sintassi utilizzabile all'interno di HTML.
In quel momento,
il nome PHP viene soppiantato da FI,
che sta per Forms,
Interpreter,
ma questa nuova nomenclatura non dura molto.
Un ulteriore rilascio effettuato nel mese successivo, infatti,
(05:30):
riporta presto il nome a PHP,
anche se con un significato leggermente diverso da quello iniziale,
cioè Personal Home Page Construction Kit.
Infine,
quasi a voler ribadire la confusione e la crescita inaspettata del progetto,
dopo circa un altro anno,
a novembre del 1997,
(05:53):
viene pubblicata la versione 2.0, stabile e completamente riscritta,
con il nome di PHP-FI,
tanto per non scontentare nessuno.
Ora, se esaminassimo del codice sviluppato all'epoca con PHP-FI,
e potremmo farlo guardando l'esempio riportato nella pagina ufficiale History of PHP,
(06:16):
che trovi in descrizione,
ci renderemmo facilmente conto che era poco più di un classico HTML
con l'aggiunta di alcuni commenti speciali
che fungevano da istruzioni condizionali o da interfaccia verso il database.
Precursore, sì, ma lontano anni luce dal PHP moderno.
(06:38):
La versione 3, che riporta il nome a semplicemente PHP,
esce poi nel 1998.
Nel 99 tutto il core viene riscritto per creare il nuovo motore Zend Engine,
che nel 2000 fa funzionare la versione 4 di PHP.
E ancora, nel 2004 c'è l'uscita di PHP 5, che si basa su Zend Engine 2.
(07:04):
Poi inizia un periodo di stop nel quale gli sviluppatori lavorano a PHP 6,
il quale non vedrà però mai la luce per via del caos,
senza pari nel processo di sviluppo.
Ed è solo nel 2015, dopo ben 11 anni,
che finalmente esce il PHP 7,
(07:25):
una pietra miliare nell'evoluzione di PHP.
In tutta questa storia, nel 2003 Rasmus rilascia un'intervista
nella quale chiarisce che a lui non piace affatto programmare.
Lui voleva semplicemente riutilizzare del codice.
L'intera evoluzione del linguaggio,
gli è fondamentalmente sfuggita di mano
(07:47):
e lui non aveva né l'intenzione,
né le competenze per creare un linguaggio di programmazione da zero.
In ogni caso, nel 2020 è uscito PHP 8,
che di anno in anno è arrivato alla versione 8.3, poi 8.4
e, come forse già saprai, è da un po' che si parla anche di PHP 9.
(08:10):
Ma cosa è cambiato in tutto questo tempo?
A cosa sono servite tutte queste versioni?
Beh, semplice.
Il linguaggio si è evoluto ed è enormemente migliorato
sotto tantissimi punti di vista,
eliminando progressivamente i suoi limiti tecnici
e rincorrendo ed adeguandosi ai moderni linguaggi di programmazione del settore.
(08:35):
Già PHP 7 era più veloce di Python o Ruby, ad esempio.
Si poteva fare uso di tante funzionalità per la coerenza come la tipizzazione forte.
Esistevano i parser statici di codice per aiutare gli sviluppatori
e tanti framework come Zend o Laravel per dettare standard e best practice.
(09:00):
Alla fine, dalla nascita di PHP 7,
viene rilasciata più o meno una versione all'anno,
con tante migliorie e funzionalità
che rivaleggiano con quelle dei linguaggi concorrenti.
Insomma, spero di essere riuscito a trasmetterti il concetto.
Parliamo di un prodotto che introduce continue migliorie ed evoluzioni
(09:23):
con una community solita e attiva e con una voglia di crescere e combattere.
Il punto a cui voglio arrivare è che, secondo me,
chi oggi dice che PHP è lento o è caotico
o costringe a produrre solo spaghetti code
semplicemente non sa di cosa sta parlando
o ha informazioni vecchie al riguardo.
(09:46):
Il fatto è che spesso tanti di quelli che criticano un linguaggio in generale
in realtà o non lo hanno mai veramente utilizzato
o lo hanno utilizzato in un passato abbastanza lontano
oppure, se lo usano oggi, lo fanno nel modo sbagliato e ne sanno ben poco.
(10:08):
Quindi, sempre secondo me,
il primo motivo per cui PHP è così odiato da tanti
è semplicemente perché non è abbastanza conosciuto.
Con questo, ovviamente, non intendo che le persone non sanno cosa sia PHP.
Qualsiasi programmatore lo conosce.
(10:29):
Quel che voglio dire è che di questo linguaggio
non vengono messi in evidenza i pregi nel modo giusto,
ma si lascia fin troppo che siano gli utilizzatori a doverli scoprire e capire.
Prova anche solo a fare un giro sul sito ufficiale php.net
e vedrai che è chiaramente rimasto ad una impostazione di due decenni fa.
(10:53):
Prova ad esplorare il manuale e ti renderai conto
che non aiuta per nulla il lettore inesperto,
ma dà per scontato che esso sappia già come funziona il linguaggio
e sia solo in cerca della definizione di una qualche funzione specifica.
Non c'è una sezione di formazione di base,
come ad esempio per Node.js o Python o Ruby on Rails,
(11:17):
che addirittura in home page ha un video introduttivo di 30 minuti.
Mancano riferimenti a guide ufficiali per principianti
o esempi dimostrativi da cui iniziare.
Questa impostazione rispecchia appieno la filosofia di divulgazione di PHP.
Qualcosa del tipo (11:33):
ecco qui, questo è il linguaggio, ora fanne quello che vuoi.
Ma parliamo di un metodo che forse funzionava 20 anni fa o anche di più,
ma che oggi sicuramente non funziona più.
La verità è che il linguaggio PHP si evolve e migliora in continuazione,
ma la sua reputazione no.
(11:54):
La fama di PHP 8.4 è rimasta fondamentalmente al pari di quella di PHP 5
e questo è sicuramente il suo più grande problema.
Ci sono là fuori tantissimi programmatori a cui piace dire che PHP è un linguaggio morto.
(12:18):
Sono gli stessi che, quando magari scoprono che è il tuo linguaggio di riferimento,
ti chiedono (12:24):
possibile che lavori ancora con PHP?
Perché non studi qualche linguaggio migliore?
Hai presente, no?
La classica domanda (12:33):
ma PHP non è morto?
Beh, mi spiace per loro, ma in effetti PHP è morto
solo se si ignorano le attuali statistiche di utilizzo dei linguaggi di programmazione
e buona parte di ciò che muove il web nel 2025.
A dirla tutta, se vogliamo essere onesti, guardando la pagina di statistiche V3Tech,
(12:56):
che ti lascio in descrizione,
negli ultimi dieci anni PHP ha perso terreno rispetto agli altri linguaggi.
Guardando la tabella riportata, infatti,
e prendendo in esame ad esempio il periodo tra il 2013 e oggi,
si nota subito che Ruby o Java sono cresciuti, per utilizzo lato server,
(13:17):
rispettivamente dallo 0,5 al 6,1% e dal 4 al 5%.
Un linguaggio specifico per il web come JavaScript, poi,
che inizialmente era utilizzato solo lato client,
lato server è invece passato da meno dello 0,1% a ben 3,8%.
(13:39):
PHP, invece, nello stesso lasso di tempo, è in controtendenza e perde terreno,
passando dal 77,7% del 2013 ad un misero 76,7% a fine 2024.
Si tratta, a ben guardare,
di una discreta diminuzione di ben un punto percentuale in dieci anni.
(14:01):
Facendo quindi una proiezione molto semplice,
possiamo immaginare che a questo ritmo l'utilizzo del linguaggio
si andrà ad azzerare completamente all'incirca nell'arco di soli 760 anni.
Ok, scherzi a parte,
dovresti aver capito che quelli che pensano che PHP sia morto
in effetti di PHP e di web non ne sanno poi molto
(14:25):
e, a meno di grossi sconvolgimenti,
almeno per il momento, dovranno rimanere delusi.
Ma, anche scartando la domanda stupida sulla morte di PHP,
resta però una questione reale che, secondo me, è molto più interessante.
La vera domanda che dovremmo porci, infatti, è:
perché la gente chiede se PHP è morto?
(14:49):
Perché lo ritiene un linguaggio finito o così terribile
da dover sparire dalla faccia della terra?
Abbiamo capito che parte della risposta è per ignoranza e superficialità
o per scarsa capacità di divulgazione,
ma io mi rifiuto di pensare che la questione sia tutta qui,
che la cosa si possa spiegare in maniera così semplice.
(15:13):
D'altronde, la maggior parte dei programmatori che conosco
sono tutt'altro che ignoranti e superficiali.
E poi, il fatto di non sapersi pubblicizzare
a dovere non basta ad attirarsi l'odio delle persone.
Un'altra possibile ragione, quindi, secondo me,
è che quelli che insinuano che PHP sia morto
(15:34):
lo fanno perché, in fondo in fondo, vorrebbero che fosse così.
Vorrebbero che questo linguaggio sparisse.
Mi spiego meglio (15:41):
PHP è uno dei modi più semplici per un programmatore
per creare un sito, una pagina web o un API.
Muove buona parte.
Muove buona parte del web
ed è enormemente utilizzato proprio per questa sua semplicità.
Se ci aggiungiamo poi anche il più conosciuto dei suoi prodotti,
cioè WordPress,
(16:03):
possiamo tranquillamente affermare che domina il mercato del web,
almeno quello non fortemente specializzato.
E continua, dunque, ad essere una soluzione più che valida
per moltissimi soggetti.
Non tutti, ma moltissimi sì.
E se è valida,
allora ovviamente viene usata.
Inoltre va tenuto presente che spesso sono i programmatori più esperti
(16:28):
e la cultura aziendale a determinare la scelta di abbracciare un linguaggio
piuttosto che un altro o di perseverare nel suo utilizzo.
E tantissimi big del web hanno utilizzato PHP per i loro backend
e per le loro API
e così come tante altre aziende ci hanno sviluppato prodotti
(16:49):
che tutt'oggi portano loro introiti.
Oltre a questo, tanti di coloro che oggi sono senior developer,
come me ad esempio,
si sono formati nel periodo in cui non c'erano così tante alternative
e PHP era uno dei metodi più rapidi ed efficienti
per realizzare progetti concreti di quelli che ci davano da mangiare.
(17:11):
E il risultato di tutto questo è che, volenti o nolenti,
oggi ci sono là fuori migliaia di progetti software,
basati su PHP,
che sono in funzione
e magari vanno a costituire elementi importanti
se non essenziali per moltissime realtà.
Ma quindi, dov'è che voglio arrivare ti starai chiedendo?
(17:32):
Beh, la mia idea è che tante persone sperano che PHP sia morto
perché di fatto se lo trovano praticamente dovunque
quando in effetti vorrebbero doverci avere a che fare il meno possibile.
Loro sono devoti ai loro linguaggi,
sono devoti ai loro linguaggi di riferimento
e non sopportano l'idea di doversi piegare
(17:53):
a utilizzare quel vecchio e inutile accrocchio che è PHP.
Non lo conoscono bene, non ne vogliono sapere nulla.
Per loro è rimasto alla versione 5
ed è una tragedia ogni volta che ci devono mettere le mani.
Non sanno o non vogliono sapere che, come noi abbiamo già detto,
il linguaggio in questi anni si è evoluto tantissimo,
che è diventato migliore, più professionale, più potente,
(18:16):
più completo e ben definito.
Non importa che per qualità e prestazioni
sia praticamente irriconoscibile rispetto a dieci anni fa.
Per loro resta un qualcosa con cui si trovano costretti ad avere a che fare,
vuoi perché si trovano a dover lavorare su progetti preesistenti,
vuoi perché gli viene imposto dall'alto.
(18:37):
Ma in entrambi i casi i poveri programmatori di turno
raramente possono ribellarsi alla situazione.
Difficilmente possono risparmiare,
possono riscrivere interi progetti da zero
o convincere il proprio capo ad adottare un linguaggio diverso
da quello che è stato deciso.
Guardando la questione da questo punto di vista
è facile ipotizzare che in situazioni del genere
(19:01):
l'astio verso le imposizioni non possa far altro che crescere
e, non potendo essere sfogato verso le vere cause,
si trovi invece ad essere riversato sul linguaggio.
PHP è un linguaggio molto particolare.
Secondo la mia esperienza,
(19:22):
e non solo ovviamente,
esso è in grado di incarnare a pieno due filosofie di progettazione
completamente opposte fra loro,
a volte anche addirittura contemporaneamente.
Capiamoci però,
non mi sto riferendo al processo di sviluppo del codice.
Agile o Waterfall,
o simili non c'entrano.
(19:43):
Così come User Stories,
Specifiche e Design o altro, no.
Io sto parlando proprio di come appare il codice una volta scritto.
In pratica, se questo risulta ben strutturato,
leggibile ed efficiente,
oppure il classico groviglio di istruzioni
comunemente definito spaghetti code.
(20:04):
Le persone che dicono che il codice scritto in PHP fa schifo
hanno ragione.
Esistono software implementati in questo linguaggio
che risultano un coacervo di comportamenti scorretti
se considerati dal punto di vista della buona programmazione.
Però anche le persone che dicono che PHP è un ottimo linguaggio
(20:26):
hanno ragione.
Con esso infatti è stato scritto tantissimo codice
che rispetta tutte le buone pratiche,
dai design pattern alla programmazione ad oggetti,
passando per quella asincrona,
quella funzionale e tanti altri paradigmi.
Sulla carta, questa ambivalenza dovrebbe essere un limite
per un linguaggio, un malus, un freno.
(20:49):
Dovrebbe generare confusione nei programmatori
e impedire che essi riescano a destreggiarsi nel codice esistente
e tantomeno siano invogliati a scriverne di nuovo.
Eppure, là fuori, ci sono decine di linguaggi
più strutturati e più ordinati di PHP
che però non raggiungono minimamente lo stesso livello di diffusione.
(21:13):
Linguaggi precisi, linguaggi potenti,
linguaggi specificamente progettati per il web.
Nessuno che riesce ad affermarsi su PHP.
E come è possibile questa cosa?
Beh, la risposta è semplice:
perché PHP è il peggiore.
Nel 1991 Richard Gabriel,
(21:34):
accademico e informatico di professione,
pubblicò un saggio dal titolo
nel quale affrontava gli aspetti positivi e negativi di Lisp,
un linguaggio che lui stesso aveva contribuito a sviluppare
e che aveva avuto grande diffusione
soprattutto a partire dagli anni '80 del secolo scorso.
(21:56):
Nel suo saggio, Gabriel tentò essenzialmente
di identificare le motivazioni di un periodo di difficoltà di Lisp
e, per farlo,
scuse di confrontare tale linguaggio
con uno sempre più dilagante di quel periodo:
il C.
Secondo Gabriel, il problema di Lisp
risiedeva in una "tensione"
(22:17):
fra due opposte filosofie di sviluppo del codice:
una chiamata "Myth Style"
o "Stand for Style"
e incarnata appunto da Lisp
con le sue innumerevoli varianti;
l'altra, chiamata "New Jersey Style"
e capeggiata invece dal C e i suoi derivati.
Nella pratica, i due stili sono essenzialmente simili
(22:40):
ma si distinguono nel peso e nell'importanza
data a quattro specifici aspetti chiave
che sono:
semplicità, correttezza, coerenza e completezza.
In entrambe le filosofie,
tali aspetti ricoprono un ruolo fondamentale
ma il rapporto fra di essi è inteso in modo differente.
(23:01):
Nel momento in cui è necessario, infatti,
dare priorità ad uno piuttosto che ad un altro,
la scelta varia a seconda della filosofia utilizzata.
Il fulcro della differenza tra i due stili
risiede nel valore riservato all'aspetto della semplicità,
la quale è ritenuta importante per entrambi,
(23:22):
ma nel "New Jersey Style" lo è di più che nello "Stand for Style".
In descrizione trovi il link al testo originale
con le due filosofie descritte in dettaglio.
Ma, volendo riassumere e semplificare al massimo,
il concetto è più o meno il seguente:
lo "Stand for Style" è quello più perfezionista dei due.
(23:46):
In esso la semplicità è preziosa
ma non abbastanza da ammettere con promessi
quando si tratta di correttezza o coerenza.
Ogni aspetto del codice deve essere impeccabile
e perfettamente coordinato.
Questo stile non accetta errori.
Tutto deve funzionare senza sbavature
(24:07):
e ogni dettaglio deve essere coperto.
Programmare è come costruire un orologio svizzero:
ogni parte deve avere il suo posto giusto senza compromessi.
Dall'altra parte, invece,
il "New Jersey Style" è un po' più rilassato e pragmatico.
In esso la semplicità è la cosa più importante,
(24:28):
non che la correttezza non sia importante, ovviamente,
ma se è necessario scegliere tra semplicità e precisione,
il "New Jersey Style" sceglie la prima.
Questo stile ammette la possibilità
di sacrificare un po' di coerenza o di completezza
al fine di mantenere le cose facili e comprensibili.
(24:49):
In esso, programmare è come costruire un ponte
con materiali essenziali:
robusto, utile, funzionale e soprattutto semplice.
Quindi, se da una parte lo "Stanford Style"
punta all'eleganza senza difetti,
dall'altra il "New Jersey Style" preferisce un approccio pratico e diretto,
(25:11):
dove l'importante è mantenere tutto semplice e funzionante
anche se a volte bisogna scendere a qualche compromesso.
Gabriel utilizzò l'ISP come esempio di linguaggio
che implementa la filosofia Stanford,
definendola "the right way", il modo giusto.
E "C" come esempio di "New Jersey Style",
(25:34):
il quale per contrapposizione diventò "the wrong way", il modo sbagliato.
A prescindere dalle definizioni, però,
la realtà dei fatti è che già nel '91,
quando Gabriel scrisse il suo saggio,
il "C", con il suo modo sbagliato di essere,
si era diffuso e si stava espandendo sempre di più,
(25:55):
mentre il perfetto l'ISP continuava a perdere terreno.
L'accademico si interrogò appunto su questo fenomeno,
che superficialmente sembrava controintuitivo,
e giunse ad una sorprendente conclusione che definì:
"Worse is better".
Peggio è meglio.
L'idea di base è semplice:
(26:17):
il peggio ha caratteristiche di sopravvivenza migliori del meglio,
e pertanto si diffonde più facilmente, in modo più pervasivo,
e consiste maggiormente al trascorrere del tempo.
Per spiegare questo concetto,
Gabriel raccontò il seguente aneddoto:
Due persone famose,
(26:38):
una del MIT e l'altra di Berkeley, New Jersey,
che lavorava su UNIX,
un giorno si incontrarono per discutere di sistemi operativi.
La persona del MIT era interessata a capire
come UNIX risolvesse un certo problema.
In pratica,
quando un programma utente invoca una routine di sistema
(27:00):
per eseguire un'operazione lunga,
se durante tale operazione si verifica un'interruzione,
lo stato del programma utente deve essere salvato.
E poiché l'invocazione di una routine di sistema
è solitamente una singola istruzione,
il PC non cattura adeguatamente lo stato del processo,
quindi la routine ha essenzialmente due possibilità:
(27:23):
la prima è fare marcia indietro
e ignorare che l'istruzione sia stata avviata,
l'altra è andare avanti e perdere lo stato.
La cosa più corretta da fare è tornare indietro
e riportare il programma all'istruzione che ha invocato la routine,
in modo che alla ripresa dopo l'interruzione
esso ne ripeta la chiamata.
(27:45):
Ma il tizio del MIT non riusciva a trovare alcun codice in UNIX
che gestisse questo caso e chiese al tizio del New Jersey
come veniva risolta la questione.
Il tizio del New Jersey disse che i tecnici UNIX
erano a conoscenza del problema,
ma la soluzione era che la routine terminava sempre,
(28:06):
solo che a volte veniva restituito un codice di errore
che segnalava che non era riuscita a completare la sua azione.
Un programma utente corretto, quindi,
doveva occuparsi di controllare il codice di errore
per determinare se provare di nuovo la routine oppure no.
La responsabilità non era del sistema operativo.
(28:27):
Al tipo del MIT questa soluzione non piaceva
perché non era la cosa giusta da fare,
ma il tizio del New Jersey rispose che la soluzione UNIX
era giusta perché la filosofia di progettazione di UNIX
era la semplicità e che la cosa giusta era troppo complessa.
Inoltre, i programmatori potevano facilmente inserire questo test.
(28:50):
Il tipo del MIT fece allora notare
che così l'implementazione era semplice,
ma l'interfaccia con la funzionalità era complessa.
E il tizio del New Jersey disse che in UNIX è stato scelto il giusto compromesso,
ovvero che la semplicità dell'implementazione
è più importante della semplicità dell'interfaccia.
(29:12):
Il tizio del MIT poi borbottò qualcosa del tipo
che a volte ci vuole un uomo duro per fare un pollo tenero,
ma il tizio del New Jersey non capì.
UNIX era già al tempo piuttosto diffuso
e successivamente ebbe ancora più successo
prima nelle università ed enti di ricerca,
poi in ambito commerciale.
Sicuramente oggi è noto per essere
(29:34):
il primo sistema operativo portabile multiutente e multitasking
ed è implementato in linguaggio C.
È il precursore di tutti i sistemi operativi Linux
che ormai sono enormemente utilizzati in ambito server
ed è stato per tanti anni
la culla del linguaggio C,
ampiamente gettonato tra gli sviluppatori per più di 30 anni.
(29:56):
Sia UNIX che C sono stati progettati utilizzando un approccio
che si è poi concretizzato nel New Jersey style.
Di conseguenza i primi compilatori UNIX e C
avevano strutture semplici,
erano facilmente portabili,
richiedevano poche risorse
e fornivano buona parte delle funzioni che si possono desiderare
(30:19):
da un sistema operativo e da un linguaggio di programmazione.
Banalmente Gabriel fece notare
che in qualsiasi momento metà dei computer esistenti
è composta da esemplari peggiori della media,
quindi più lenti e meno potenti.
UNIX e C funzionavano benissimo anche su quelle macchine.
Mi raccomando,
(30:40):
tieni presente che il testo risale al '91
quando le caratteristiche dell'hardware erano enormemente inferiori ad oggi
ed era comune che alcuni PC non fossero in grado di compilare
ed eseguire software di una certa complessità.
In definitiva la teoria del 'peggio e meglio'
afferma dunque che la semplicità di implementazione e di utilizzo
(31:03):
ha la massima priorità su tutti gli altri aspetti chiave del software.
Se si riesce a creare un linguaggio o un sistema operativo
che implementa anche solo la metà delle proprie caratteristiche
decentemente ma riesce a farlo in modo semplice e su qualsiasi macchina,
allora questo inizierà a diffondersi ovunque come un virus.
(31:26):
Secondo Gabriel, UNIX e C sono virus informatici per eccellenza.
La lezione che Gabriel trae dalla sua analisi, quindi,
è che spesso non è auspicabile scegliere la cosa giusta per prima
ma è meglio puntare sulla diffusione e poi preoccuparsi degli altri dettagli.
(31:52):
Per citare una frase del suo saggio:
"È meglio rendere disponibile la metà della cosa giusta
in modo che si diffonda come un virus.
Una volta che le persone se ne sono invaghite
ci si prende il tempo necessario per migliorarla
fino a raggiungere il 90% della cosa giusta".
(32:13):
Fine citazione.
Dopo che Gabriel raggiunge questa conclusione,
Rasmus Lerdorf inizia a lavorare sul suo Personal On Page Tools
che, come già detto, noi oggi conosciamo appunto come PHP.
Nato come espediente per gestire un sito personale
e far comunicare dei form con dei database,
(32:35):
PHP non è stato creato per divenire poi un vero linguaggio di programmazione.
Era piuttosto una serie di script e funzioni
basate sul linguaggio C.
Eppure, questo nuovo strumento incarnava
e ha sviluppato nel corso del tempo
le stesse inclinazioni descritte da Gabriel
per le caratteristiche chiave del New Jersey Style.
(32:59):
Cito:
1. Il design deve essere semplice
sia per l'implementazione che per l'interfaccia.
PHP è costruito sul linguaggio C
che già secondo Gabriel rispetta
i criteri fondamentali di semplicità.
Tale caratteristica, quindi, implica già tutta una serie di vantaggi.
(33:20):
Tanto per cominciare,
basarsi su un meccanismo semplice
permette di capirne il funzionamento ed estenderlo con estrema facilità.
Infatti, imparare come funziona il core di PHP al proprio interno
richiede davvero poche ore di studio.
In secondo luogo,
la radice nel linguaggio C permette ai programmatori
(33:42):
di passare facilmente da PHP
ad un altro qualsiasi dei linguaggi della stessa famiglia,
riducendo tempi e costi.
Infine, gran parte dell'interfaccia di PHP è considerata semplice
perché molte delle funzionalità principali
si limitano ad interfacciarsi con varie librerie C
e ad esporle così come sono,
(34:05):
senza aggiungere logiche e complessità.
Col passare del tempo, poi, il linguaggio è cresciuto.
Le estensioni sono aumentate,
così come i campi d'azione coperti.
A poco a poco sono state aggiunte tutte le caratteristiche più moderne
come la programmazione ad oggetti,
quella sincrona e via discorrendo,
(34:26):
ma sempre seguendo il medesimo principio di semplicità.
il design deve essere corretto in tutti gli aspetti osservabili,
ma è preferibile essere semplici piuttosto che corretti.
PHP ha sempre permesso
un'enorme flessibilità su parametri di funzioni e tipi di ritorno,
questo con lo scopo di fornire strumenti potenti
(34:49):
ma rendendoli al tempo stesso più accessibili e semplici possibile.
Per contro, con l'avanzare delle versioni,
chi lo desidera può scegliere di limitare sempre più questi fattori di libertà.
La rigidità può essere introdotta per convenzione,
con l'adozione di un framework,
o anche forzata configurando una serie di restrizioni, eccezioni e strict mode.
(35:15):
In ogni caso, nel processo di evoluzione del linguaggio,
tutte le novità vengono introdotte in base alle richieste dei programmatori della community,
non perché devono essere presenti o sviluppate in un certo modo per presa di posizione accademica.
Insomma, PHP parte di base da un'estrema semplicità di utilizzo,
(35:38):
che poi, a poco a poco, può essere compressa
per fare spazio al livello di correttezza richiesto dallo specifico programmatore,
o, più in generale, dalla community.
3. Il design non deve essere eccessivamente incoerente.
La coerenza può essere sacrificata per la semplicità in certi casi.
(36:00):
PHP non può essere definito "perfettamente coerente", questo è evidente.
È lecito definirlo "abbastanza coerente".
Abbiamo appena detto che tante funzioni PHP si rifanno direttamente alle sottostanti funzioni in C,
e spesso in tale rapporto è mantenuta la coerenza nel funzionamento e nei parametri tra i due linguaggi.
(36:26):
Questa scelta è una semplificazione che però genera inconsistenza rispetto ad altre funzioni del linguaggio
che non trovano una diretta controparte in C.
D'altra parte, però, in PHP le varie funzioni che riguardano, ad esempio, gli array,
tra di loro sono ben coerenti nel funzionamento.
Quelle che riguardano le stringhe anche sono coerenti fra loro.
(36:50):
Il fatto di ritornare un valore false in tutta una serie di casi è anch'essa una coerenza interna del linguaggio.
Insomma, PHP quando può cerca di essere coerente, ma quando tale coerenza complica in qualsiasi modo
il rapporto con il linguaggio C, allora non esita a sacrificarla.
(37:11):
4. Il design deve coprire quante più situazioni importanti possibili.
PHP è completo quanto basta per fare ciò per cui è stato progettato, cioè scrivere applicazioni web.
Si può dire che per tale scopo copra un bel po' di situazioni.
Esso non è mai stato progettato per risolvere ogni singolo problema
(37:34):
del mondo della programmazione.
È solo per la sua semplicità che si presta ad essere utilizzato in situazioni diverse.
L'attenzione iniziale per il web ha contribuito a definirne le caratteristiche iniziali, appunto,
e la tendenza continua ancora oggi.
Le modifiche al linguaggio principale infatti sono guidate totalmente dalle esigenze di sviluppatori web.
(37:58):
E gran parte dell'innovazione deriva dalla necessità di svolgere
il lavoro più rapidamente e meglio.
Anche quando si tratta di copiare funzionalità da altri linguaggi,
ciò avviene per rendere più facile la vita degli sviluppatori
e raramente perché un altro linguaggio fa tale operazione in modo più corretto.
(38:22):
Insomma, PHP, con le sue caratteristiche, estensioni, framework, eccetera,
oggi consente di creare applicazioni web.
E tra cinque anni permetterà sempre di creare applicazioni web
solo con alcune funzionalità in più.
Per concludere, possiamo certamente affermare che PHP
(38:48):
ha tutt'oggi un sacco di problemi e limitazioni,
ma ha anche tantissimi pregi, vantaggi e strumenti potenti.
D'altronde, se così non fosse, non sarebbe così largamente utilizzato ancora oggi
come in passato e non farebbe girare milioni di progetti
il cui numero aumenta quotidianamente.
(39:09):
Semplicemente, PHP, con tutti i suoi limiti, è comunque tra i linguaggi
con le migliori caratteristiche necessarie alla diffusione e alla sopravvivenza.
Come nel processo evolutivo, infatti, chi sopravvive non è necessariamente
il migliore del momento, ma colui che meglio sa adattarsi al cambiamento.
(39:30):
E PHP ha dimostrato di sapersi adattare egregiamente.
Nonostante questo, esso continua ad avere una pessima reputazione,
un po' per colpa di chi lo utilizza e lo diffonde nel modo sbagliato,
ma un po' anche perché tanti programmatori là fuori
parlano senza realmente sapere le cose che dicono.
(39:53):
Magari tanti di quelli che criticano il PHP
di PHP non hanno mai scritto nemmeno una riga.
E un comportamento del genere non è tipico solo del caso in oggetto.
Noi oggi ci limitiamo a parlare di questo solo perché è l'argomento dell'episodio.
Le persone odiano PHP perché oggi va di moda odiare PHP.
(40:15):
Magari domani se la prenderanno con qualche altro linguaggio che oggi va per la maggiore.
Chissà, qualcuno ha detto JavaScript?
Ad ogni modo, quello che penso io è che nella cassetta degli attrezzi
di un buon professionista non è assolutamente indispensabile che ci sia PHP.
Si può essere ottimi programmatori conoscendo tutt'altri linguaggi.
(40:39):
Quello per cui però proprio non c'è spazio, secondo me,
è l'ignoranza e l'elitarismo,
che quando inseriti nell'equazione non possono fare altro che danni.
In altre parole, la prossima volta che qualcuno ti dice che PHP fa schifo,
ricordagli che tutto sommato la longevità e la diffusione di PHP
(41:02):
testimoniano che fare le cose nel modo giusto non è sempre meglio
che farle nel modo sbagliato o addirittura in quello peggiore.
Più in generale, se qualcuno critica il linguaggio o il framework che stai usando,
pensa sempre che a lungo andare la cosa non ha importanza.
Scegli la filosofia di progettazione che più fa al caso tuo
(41:26):
e sii felice di sapere che essere i peggiori potrebbe in realtà rivelarsi la cosa migliore.
E poi, diciamocela tutta, il caro vecchio PHP ci ricorda anche una regola di vita molto importante,
e cioè che l'ottimo è nemico del buono.
Quante volte ci siamo trovati con progetti che non hanno mai visto la luce
(41:49):
perché eravamo alla continua ricerca dell'occasione o del momento perfetto?
Quante volte abbiamo rinunciato a fare qualcosa
perché sentivamo di non poterlo fare nel modo migliore o nelle migliori condizioni?
Beh, la lezione che potremmo trarre da PHP è che se vogliamo veramente fare qualcosa,
(42:10):
allora dobbiamo farlo, buttarci, anche se il risultato non sarà perfetto.
Se nella nostra idea c'è del potenziale, allora questo verrà fuori anche se la realizzazione non sarà perfetta.
Così avremo modo di lavorare in un secondo momento su tutti gli aspetti che necessitano di migliorie.
Non lasciamo che la ricerca della perfezione ci paralizzi e ci impedisca di portare a compimento cose
(42:37):
che potenzialmente potrebbero diventare anche molto belle e importanti.
Bene, spero come al solito di averti portato delle riflessioni interessanti.
Cosa ne pensi tu di PHP e unisciti al gruppo se non l'hai già fatto, così possiamo discuterne insieme.
(43:00):
Nel frattempo, prima di lasciarti, ti ricordo che Pensieri in Codice è un progetto indipendente
che realizzo nel mio tempo libero e con le mie risorse personali
e si basa totalmente sulla filosofia Value for Value.
Cosa vuol dire?
Semplice, vuol dire che è gratuito e disponibile per chiunque senza pubblicità.
(43:22):
L'unica cosa che ti chiedo in cambio è, se lo ascolti con continuità, di valutare che valore ha per te.
Ad esempio, pensa a quanto ti potrebbe dispiacere se da domani scomparisse.
Ora, sulla base di questa riflessione, prendi in considerazione l'idea di supportare il podcast.
(43:43):
Scegli tu il modo, hai tante possibilità.
Ad esempio, puoi spendere un po' del tuo tempo come faccio io.
Diffondilo, parlane, fallo ascoltare, condividi gli episodi.
Aiuta a portare più ascoltatori, che è lo scopo principale di tutto.
Oppure, puoi partecipare alle attività.
Ci sono tante, tante cose da fare.
(44:06):
Per esempio, aprire e gestire degli account social
o portare avanti lo sviluppo del sito o degli automatismi che abbiamo creato con la community.
Mi piacerebbe inoltre aggiornare la sigla
e magari la musica in background.
Se vuoi, puoi proporre qualcosa e aiutare a realizzare gli asset.
(44:27):
Ma non limitarti a questi esempi.
Se hai un'idea che pensi che possa essere di giovamento per il progetto
e sai come portarla avanti, scrivimi e parliamone.
Infine, se non hai tempo ma vuoi contribuire lo stesso,
puoi fare una piccola donazione che fa sempre piacere
perché mi ricorda che, in qualche modo,
(44:48):
apprezzi il lavoro che faccio.
E poi, con le donazioni, ti ringrazio a fine episodio
e, arrivato a una certa soglia,
ricevi a casa i gadget come sticker, segnalibri, card laminate e numerate.
C'è tutto scritto nella sezione supporto del sito pensierincodice.it.
Proprio a proposito di questo,
(45:10):
oggi un ringraziamento speciale va a Piolix
per la sua donazione singola che gli vale
il set di sticker e il segnalibro.
E poi agli abbonati Edoardo e Carlo
che ormai supportano Pensieri in Codice praticamente da anni.
Ah, una cosa importante, anzi due.
(45:31):
La prima è che Paypal applica delle tariffe molto alte.
Soprattutto per le donazioni piccole la percentuale è ridicolmente alta.
Quindi, se puoi, preferisci altri metodi, per favore.
Io, intanto, sto cercando di aggiungere altri metodi alternativi.
Ma, soprattutto, quando fai una donazione,
(45:52):
poi scrivimi per dirmi con che nome vuoi essere ringraziato
ed eventualmente l'indirizzo a cui spedire i gadget se ne hai diritto.
Quasi nessuno lo fa e io, quando il sistema me lo permette,
provo a ricontattare il donatore, ma non sempre posso.
Quindi, per segnalare donazioni o semplicemente metterti in contatto,
(46:14):
direttamente con me, l'indirizzo è valerio@pensierincodice.it
Mi raccomando, sempre con due i, pensieri in codice.
E direi che per oggi è tutto.
Quindi, con un episodio che probabilmente supererà i tre quarti d'ora,
io ti saluto, ti do appuntamento al prossimo episodio
(46:37):
e non dimenticare mai che un informatico risolve problemi, a volte, anche usando il computer.