Dieci buoni motivi per non utilizzare PHP

Quando in questi giorni ho appreso la triste notizia che il progetto da consegnare per l’esame di Laboratorio di Reti avrebbe dovuto essere realizzato in PHP, sono stato preso un po’ dallo sconforto.

Per anni mi sono sempre rifiutato di imparare ed utilizzare questo linguaggio ed ho persino declinato diverse offerte di lavoro, visto che già sulla carta ne avevo sempre sentito parlare male. Adesso è arrivato il momento di ingollare il rospo ed imparare almeno il minimo indispensabile alla realizzazione del progetto.

Ho approfittato della situazione per documentarmi un po’ sul PHP e per ribadire alcuni motivi che per anni mi hanno tenuto lontano da questo linguaggio. I punti che seguono prendono spunto sia da considerazioni personali, sia da un ottimo articolo di Edwin Martin.

1. Ricorsione?! Chi era costei…

La ricorsione, come molti di voi sapranno, è un meccanismo che permette ad una funzione di chiamare se stessa. Viene impiegata nell’implementazione di moltissimi algoritmi, come ad esempio il Quick Sort. Se vengono generate troppe chiamate ricorsive in PHP, il linguaggio va letteralmente in palla e non funziona piu’ correttamente. Questa cosa è stata segnalata come bug e la motivazione che è stata data dagli sviluppatori è che PHP utilizza lo stack al posto dell’heap per le chiamate ricorsive. Questo cosa c’entra? Mi viene da chiedere… eppure in altri linguaggi la ricorsione funziona benissimo!

2. Molti moduli PHP non sono thread safe

Anche se tutti i moduli del core di PHP sono garantiti thread safe, la maggior parte degli altri moduli non lo sono. Questo rende completamente inutile il fatto che Apache 2 supporti la modalità multithreaded: gli sviluppatori di PHP sconsigliano pure di utilizzare questa versione di Apache.

3. PHP è azzoppato per motivi commerciali

Vi sembra che PHP sia un po’ lento? Non avete provato la versione commerciale di Zend PHP, che garantisce maggiori prestazioni! La versione gratuita di PHP infatti non ha alcuna ottimizzazione e a meno di non utilizzare un qualche meccanismo di cache (come ad esempio APC) le prestazioni saranno basse.

4. Nessun supporto ai Namespace

Se due moduli hanno una funzione che si chiama read, non possono essere utilizzati contemporaneamente. Era stata proposta una soluzione a questo problema in PHP5, ma alla fine non è stata inclusa nella release definitiva. L’unico modo per evitare la collisione dei nomi dei metodi è quello di nominarli aggiungendo il nome del modulo all’inizio. Ecco perchè non è strano trovare metodi che ad esempio si chiamano xsl_xsltprocessor_transform_to_xml che di sicuro non aumentano la leggibilità del codice.

5. Caratteri di formattazione delle date non standard

La maggior parte dei linguaggi di programmazione utilizza uno standard per quanto riguarda i caratteri di formattazione delle date, che deriva da Unix e dal linguaggio C. PHP utilizza un proprio formato, completamente incompatibile.

6. Inconsistenza nei nomi delle funzioni

Quando i nomi dei metodi contengono piu’ di una parola, solitamente ci sono tre modi diversi per poterli scrivere. Prendiamo ad esempio un’ipotetica funzione che restituisce il numero dei file aperti. Potremmo chiamarla getnumberofopenfiles, get_number_of_open_files oppure getNumberOfOpenFiles. Quale metodo utilizza PHP? Tutti e tre ovviamente! Oltre a questo è opportuno far notare che i nomi dei metodi e delle funzioni non sono case sensitive.

7. Assenza di un framework integrato

Il modello piu’ corretto per sviluppare un’applicazione web, sarebbe quello chiamato MVC, dove la parte di visualizzazione, la business logic e la validazione dei dati ed infine l’interazione con il database, sono parti separate del progetto.

Nella maggior parte dei siti scritti in PHP è molto comune trovare sorgenti che includono tutti e tre questi aspetti in un unico file! Poche righe sopra viene fatta la connessione al database, poi c’è una parte di visualizzazione di alcuni dati, verso la metà ci sono le funzioni di validazione ed infine di nuovo altro codice html di visualizzazione. Credo che questo sia il peggiore dei modi di realizzare un’applicazione web. Pensate che sia facile per un grafico dover apportare modifiche alla parte di visualizzazione senza toccare il codice PHP? E viceversa… pensate che sia facile per un programmatore, aggiungere codice PHP senza rischiare di scombinare il layout della pagina?

Altri linguaggi con Ruby o Python ci hanno ormai abituati a framework come Rails e Django, rispettivamente. Per fortuna le cose sono in miglioramento anche su PHP, grazie a framework come CakePHP o Symfony.

8. Mancanza del supporto Unicode

Questa lacuna forse potra’ non riguardarci da vicino, visto che il set di caratteri che utilizziamo in Europa ed in America è ampiamente supportato, ma non è certo così per Cina, Giappone ed altre nazioni dove viene utilzzato un set di caratteri e di simboli molto diverso dal nostro. Tramite Unicode è possibile supportare anche questi caratteri. PHP avrà il supporto per Unicode solo nella futura versione 6.

9. Lentezza

Pensate che il Java sia un linguaggio lento? Beh, niente a confronto di PHP! Leggendo questo report si mettono in evidenza le scarse prestazioni di questo linguaggio. Persino Rasmus Lerdorf, il creatore di PHP ammette che non c’è modo di migliorare le prestazioni di PHP. Rasmus tra l’altro sconsiglia persino l’utilizzo dei frameworks sopra citati (CakePHP e Symfony) perchè rallenterebbero inutilmente le prestazioni dei siti web.

10. Estrema facilità di utilizzo

Ammetto che questo ultimo punto possa essere non condiviso da molte persone, si tratta infatti di una mia personalissima opinione. Il fatto che un linguaggio di programmazione sia troppo facile da usare, secondo me puo’ presentare anche degli svantaggi. Permette infatti anche a chi ha scarse conoscenze di programmazione, di cimentarsi in progetti, con il rischio poi di far abbassare notevolmente la qualità del codice che si trova in giro. Non è difficile infatti imbattersi in programmi scritti in PHP che all’apparenza possono risultare gradevoli ed accattivanti (magari perchè scritti da persone che principalmente si occupano di web design), ma che sotto sotto sono dei veri e propri pastoni di codice mal scritto.

Conclusioni

A favore di PHP possiamo sicuramente dire che si tratti di un linguaggio molto semplice da imparare ed ampiamente supportato dalla maggior parte dei servizi di hosting in tutto il mondo. A parte queste due motivazioni però, non mi sentirei in alcun modo di consigliarlo per sviluppare un’applicazione web.

Sicuramente qualcuno mi fara’ notare che lo stesso blog sul quale sto scrivendo è scritto in linguaggio PHP. Per l’utilizzo che ne devo fare, WordPress va piu’ che bene, almeno per le mie esigenze. Questo non toglie che PHP soffra ugualmente di tutti i problemi che sono stati esposti sopra.

E’ mia intenzione che questo articolo sia di avvertimento a chi si sta per avvicinare per la prima volta al PHP o chi già lo utilizza. Ci tengo però al fatto che non contenga imprecisioni, perchè credo che servirebbero solo a screditare la natura stessa dell’articolo. Invito quindi i lettori che rilevassero imprecisioni a segnalarmele, indicandomi dove poter trovare maggiori informazioni per verificare la validità di quanto riportato.

5 comments

  1. Hai messo in luce alcuni punti che non conoscevo, ma per altri concordo pienamente con te: l’eccessiva semplicità è dovuta alla mancanza di una linea teorica del linguaggio e questo lo rende un po’ il regno dei niubbi. Per i namespace probabilmente non sono stati introdotti perchè con le classi ce la si può cavare in modo simile… poi non so.

  2. @Tabris: i namespace in verità sono stati appena introdotti nella 5.3 che però è ancora in ALPHA e quindi non rilasciata come stabile. Purtroppo anche se ci sono le classi, senza namespace che li separa non puoi avere due classe diverse con un nome uguale di metodo :(

  3. Premessa. NON amo PHP, pur usandolo da anni per lavoro. NON lo ritengo un bel linguaggio.

    Purtuttavia, mi sento di dovere delle precisazioni su quando scrivi.

    Partiamo da quello che condivido:

    4. Nessun supporto ai Namespace

    Vero. Odioso.
    L’attuale versione 5.2 NON supporta i namespace, che però sono supportati dalla 5.3, in alfa stage, scaricabile da qui http://downloads.php.net/pierre/

    6. Inconsistenza nei nomi delle funzioni
    Vero. Vergognoso.

    Quanto invece ritengo contestabile, poco preciso o decisamente sbagliato sono i punti seguenti:

    1. Ricorsione?! Chi era costei…

    La ricorsione, in ogni sua implementazione ed in ogni linguaggio, è una tecnica avida di risorse. Non esiste linguaggio o sistema al mondo che permetta una profondità di ricorsione arbitraria. Durante la ricorsione il sistema deve memorizzare, normalmente nello stack, i parametri della funzione che chiama se’ stessa, un numero di volte pari alle istanze chiamate. Wikipedia riporta:

    “La ricorsione ha un vantaggio fondamentale: permette di scrivere poche linee di codice per risolvere un problema anche molto complesso. Tuttavia essa ha anche un enorme svantaggio: le prestazioni.

    Infatti la ricorsione genera una quantità enorme di overhead, occupando lo stack per un numero di istanze pari alle chiamate della funzione che è necessario effettuare per risolvere il problema. Funzioni che occupano una grossa quantità di spazio in memoria, pur potendo essere implementate ricorsivamente, potrebbero dare problemi a tempo di esecuzione. Inoltre la ricorsione impegna comunque il processore in maniera maggiore per popolare e distruggere gli stack

    Pertanto, se le prestazioni sono obiettivo principale del programma e non si dispone di sufficiente memoria, si consiglia di non utilizzare la ricorsione.”

    http://it.wikipedia.org/wiki/Algoritmo_ricorsivo

    E’ chiaro che PHP (come ogni altro linguaggio server side), dovendo girare in un contesto di multiutenza rispondendo a decine se non decine di migliaia di richieste, non dovrebbe permettere che un algoritmo che faccia uso pesante della ricorsione esaurisca la memoria del server, riempiendo lo stack o lo heap. Prima che il server si pianti per un algoritmo con una cattiva architettura, PHP (come molti altri linguaggi) permette di definire un limite di memoria utilizzabile per processi come la ricorsione.

    Vuoi usare 200MB per la ricorsione?
    ini_set(‘memory_limit’, ’200M’);

    PHP permette anche di eliminare (a discrezione dell’amministratore) il limite di cui parli

    Basta un
    ini_set(‘memory_limit’, ‘-1′);

    Ma l’idea di base dovrebbe essere: se il tuo algoritmo ricorsivo ha bisogno di 200MB ad istanza significa che è scritto male ed è *un bene* che esista un limite (parametrizzabile ed opzionale) al consumo indiscriminato di memoria.

    Mi spiego meglio.

    L’esempio del Quick Sort è illuminante.
    Quick Sort è stato inventato (ed è tuttora definito) in termini ricorsivi.
    Tuttavia, la sua implementazione ricorsiva è utilizzata solo per scopi didattici, perché è così avida di memoria da incorrere in stack overflow anche per pochi dati.
    Tutte le implementazioni di QuickSort (compresa quella di PHP) sono quicksort iterativi.
    Di nuovo, l’idea è che se nel programma si sta usando un algoritmo di sort capace di bruciare megabyte di memoria, si sta lavorando male e, *fortunatamente*, PHP permette di porre dei limiti di consumi di memoria prima di mandare in palla il server.

    2. Molti moduli PHP non sono thread safe

    Vero. Come è vero per tutti i linguaggi di questa terra. Per Ruby, ad esempio.

    C’è un po’ di confusione sui binari thread safe e i binari non thread safe di PHP. L’articolo sotto dovrebbe mettere un po’ di chiarezza

    http://www.iis-aid.com/articles/my_word/difference_between_php_thread_safe_and_non_thread_safe_binaries

    In brevissimo, PHP può essere completamente thread safe.
    Ovviamente nessuna garanzia può essere fornita su moduli di terze parti, come del resto non può essere fornita per nessun altro linguaggio (Ruby è thread safe, Ruby On Rails e Camping no, a differenza di altri framework per Ruby come Og + Nitro e Merb).

    Il suggerimento migliore è usare FastCGI, che permette di usare il multithreading senza incorrere nei problemi di thread.

    3. PHP è azzoppato per motivi commerciali

    Questa è semplicemente una leggenda metropolitana.
    Zend pubblica PHP sotto licenza BSD. PHP ha nativamente lo Zend Engine, esattamente come la versione distribuita da Zend.
    Ovvero, NON esiste differenza tra il PHP di Zend e il PHP che hai installato sul tuo PC.

    Il refuso nasce dal fatto che Zend vende un’estensione chiamata Zend Optimizer, un prodotto completamente separato da PHP che può essere acquistato ed usato con PHP (cioè, con l’unica versione esistente di PHP).

    Alla stregua di Zend Optimizer esistono altri prodotti (commerciali ed open source) che forniscono metodi di accelerazione. Uno dei migliori, APC, è open source e fornisce prestazioni molto superiori rispetto a Zend Optimizer.

    Sarebbe bene chiudere con questa storia della versione azzoppata di PHP, perché non ha alcun fondamento.

    5. Caratteri di formattazione delle date non standard

    Non è vero.
    Basta cercare bene ;)

    http://www.php.net/manual/en/function.strftime.php

    7. Assenza di un framework integrato

    Temo questo punto sia completamente mal posto.
    Forse Ruby ha un framework integrato? Ruby e Ruby On Rails sono due progetti separati, tanto che su Ruby si può decidere di utilizzare un framework differente (Camping, ad esempio).

    E cosa significa “integrato”? Incluso nel core? Quale linguaggio possidere un framework integrato? Java? C++? Il fatto che “altri linguaggi con Ruby o Python ci hanno ormai abituati a framework come Rails e Django” non significa che questi siano integrati.
    E, aggiungerei: fortunatamente! Perché io voglio scegliere quale framework usare.

    E’ anche contestabile l’affermazione “le cose sono in miglioramento anche su PHP, grazie a framework come CakePHP o Symfony”.

    CakePHP è solo di un anno più giovane rispetto a RoR. PEAR, un altro framework MVC molto molto esteso e completo, per PHP, esiste dal 1999, anni prima che i framework che citi fossero anche solo stati concepiti.

    E, se vogliamo proprio fare le pulci agli altri linguaggi, andrebbe anche detto che per PHP esistono qualcosa come 60 framework, contro la 15ina di Python e la decina per Ruby.

    8. Mancanza del supporto Unicode

    Non vero.
    Dal manuale: http://www.phpbuilder.com/manual/en/ref.unicode.php

    9. Lentezza

    Non è così vero.
    Andrebbe tenuto conto che PHP è un linguaggio di scripting e pertanto aspettarsi benchmark peggiori rispetto a linguaggi compilati. Infatti, PHP scompare accanto a C++ (come del resto scompaiono Ruby ed altri linguaggi di script).

    Tuttavia alcuni test potrebbero stupire.

    E’ più veloce e più parsimonioso nel consumo di memoria di Ruby e un po’ meno di Python.
    http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&lang2=php

    Ha grosso modo la stessa velocità e lo stesso consumo di memoria di Perl
    http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=php

    Con APC la situazione migliora ulteriormente.
    Direi, insomma, che PHP si colloca, come prestazioni, come altri linguaggi di script (con la possibilità di miglioramenti tramite acceleratori).
    In contesti di uso di framework, invece, è decisamente più performante di Ruby.

    Che poi PHP sia un brutto linguaggio, convengo con te. Ma non per i motivi da te riportati.
    Ciao!

  4. Mi sono imbattuto per caso nel tuo articolo, sono uno sviluppatore di applicazioni Web; sono passato da ASP prima, poi ASP.NET e infine a PHP e devo dire di essere proprio felice della scelta!
    Potrei dilungarmi a confutare le tue affermazioni, ma dico una sola cosa: se PHP fa così schifo perchè il tuo Blog è su WordPress??? WordPress è un’applicazione scritta in PHP!!!

  5. … sono felice di utilizzare PHP dopo una esperienza decennale di ASP. Le utlime versioni offrono una risorsa inestimabile di funzioni. Sviluppiamo webApp di rete, gestionali aziendali e non abbiamo mai trovato alcuna difficoltà in impallamenti delle memoria del server.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>