Newsgroup: it.comp.www.php
Titolo: PHP - Una analisi critica

L'articolo formattato per benino in HTML si trova qui:
http://www.icosaedro.it/articoli/php-analisi-critica.html
Questa e' la versione solo testo.
Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  
www.icosaedro.it
PHP Analisi Critica
In breve
Il linguaggio di programmazione PHP è sempre più popolare e forse il più usato 
in assoluto per lo sviluppo di siti WEB dinamici. Si tratta di un linguaggio 
nato quasi per caso per assolvere ad esigenze pratiche, ed ha punti di forza ma 
anche qualche debolezza. Questo articolo analizza i pro e i contro del PHP.
I punti di forza del PHP
Il PHP non è stato progettato "a tavolitno" sulla base di astratti principi di 
programmazione. Il PHP è nato poco alla volta per rispondere ad esigenze 
pratiche, e così e' diventato forse il piu' popolare linguaggio per lo sviluppo 
di siti WEB dinamici. I suoi meriti sono tanti, e un elenco completo sarebbe 
davvero lungo, ma tessere le lodi di un prodotto aiuta poco alla sua 
evoluzione. Qui riassumo solo le sue valenze principali.
E un linguaggio interpretato. Ogni modifica apportata al sorgente è 
immediatamente effettiva.
Non richiede dichiarazioni di tipo. Il tipo delle variabili viene stabilito 
dinamicamente quando viene assegnato un valore ad esse.
Ricca dotazione di librerie di funzioni utili e di uso immediato.
Le debolezze del PHP
E' un linguaggio interpretato. Poco efficiente, soprattutto la fase iniziale di 
parsing del sorgente. PROPOSTA: implementare una cache del codice intermedio, 
come già fanno certi prodotti di terze parti.
E' difficile implementare un compilatore capace di generare codice macchina 
direttamente eseguibile dal computer. Causa di questo problema sono la 
mutabilita' di tipo delle variabili, la possibilita' di definire dinamicamente 
le costanti e il meccanismo di inclusione di file. Se il linguaggio fosse 
appena piu' rigoroso si aprirebbero nuove strade per l'applicazione del PHP per 
coloro che vorrebbero usarlo anche in altri contesti oltre allo scripting di 
siti WEB. Alcune delle proposte che qui suggerisco vanno proprio nella 
direzione di rendere il PHP un linguaggio "compilabile".
Molti messaggi di avvertimento che l'interprete puo' generare a run-time si 
possono disabilitare. Ed e' esattamente quello che fanno molti programmatori: 
vedendo allungarsi il log file di oscuri messaggi, preferiscono risolvere 
questa noia disabilitandone la generazione piuttosto che avvalersene per 
correggere e migliorare il proprio programma. Ad esempio, l'avvertimento quando 
si usa il valore di una variabile non inizializzata (errore spesso fatale in 
altri linguaggi) in PHP e' un NOTICE disabilitato per default. FIXME: elenca 
messaggi di errore da promuovere a "fatali".
Regole di scope un po' confuse. I nomi delle costanti sono globali, e quindi 
visibili anche dentro le funzioni, dentro le classi e i metodi, 
indipendentemente da dove queste costanti sono state definite. Idem per i nomi 
di funzione. Le variabili globali hanno invece l'accesso regolato dalla 
istruzione global e sono accessibili dall'interno di funzioni e classi via 
$_GLOBAL[]. Secondo il mio modo di vedere le cose della programmazione 
strutturata, un identificatore definito all'interno di qualcosa e' locale a 
quel contesto a meno che non sia esplicitamente indicato diversamente.
I vari tipi di identificatori occupano spazi dei nomi separati. Ad esempio, un 
nome di costante puo' coincidere col nome di una variabile: PI e $PI sono due 
identificatori diversi. In queste caso nessun problema reale, visto che la 
presenza del $ permette di distinguere bene le due cose. Ma cosa dire della 
funzione PI() e della classe PI? Questo sorgente risulta valido su PHP5:
define("defUsername", "pippo");
$defUsername = "pluto";
function defUsername() { return defUsername; }
class defUsername {
	const defUsername = "topolino";
	public $defUsername = "qui";
	function defUsername($defUsername)
	{ $this->defUsername = defUsername; }
}
$u = new defUsername( defUsername() );
echo $u->defUsername;
Tralasciamo per il momento le considerazioni sulla salute mentale del 
programmatore che ha scritto questo codice (cioe' io... :-) Domanda: che nome 
stampa l'ultimo echo? Un po' confuso, non e' vero? E che dire se sorgesse la 
necessita' di convertire un simile sorgente in un altro linguaggio meno 
permissivo? oppure volessimo compilarlo con un ipotetico compilatore? Non 
sarebbe meglio avere nomi diversi per cose diverse? PROPOSTA: lo spazio dei 
nomi degli identificatori deve essere unico; tutti gli identificatori sono 
case-sensitive.
Le parole chiave del linguaggio sono case-insensitive. Dunque è ammesso 
scrivere cose come questa:
IF ($i > 0 && $i < 10 ) {
	Echo "Valore nell'intervallo previsto.";
Else {
	ECHO "Valore fuori dell'intervallo previsto.";
}
Questo confonde i principianti, non ha alcuna utilita' pratica, ed e' brutto a 
vedersi. PROPOSTA: tutte le keyword sono case-sensitive, e di norma sono 
minuscole. Le keyword che rappresentano costanti (TRUE, FALSE, NULL, ...) 
devono essere maiuscole, come da comune convenzione per i nomi di costanti.
Non si possono annidare i commenti multi-linea. A volte sarebbe utile poter 
escludere al volo una sezione di codice, soprattutto in fase di test del 
programma, e i commenti multi-linea sembrano adatti a questo scopo. Purtroppo 
questa soluzione non è applicabile quando nella sezione di codice sono già 
presenti degli altri commenti multi-linea. Se ciononostante si prova a 
commentare il codice, si possono verificare comportamenti inattesi:
$i = 9;
/**** CODICE ESCLUSO
$k = 10; /* limite max di $i */
$i_max = 20;
FINE CODICE ESCLUSO *****/
In questo esempio l'assegnamento alla variabile $i_max viene comunque eseguito, 
anche se risulta inserito nel blocco di codice commentato. L'interprete segnala 
poi un errore "misterioso" perchè l'istruzione "FINE" non risulta definita. In 
una sezione di codice appena più lunga e intricata questo potrebbe rubare un 
po' di tempo al programmatore. RIMEDI PROPOSTI:
    * Permettere i commenti multi-linea annidati.
    * In subordine, l'interprete dovrebbe segnalare la presenza del commento 
annidato con un apposito messaggio di avvertimento. 
Che valore prendono le variabili non definite che appaiono nel RHS? Rasmus dice 
che si comportano come NULL (p. 30). FIXME: VERIFICARE.
Variabili per riferimento. L'argomento è un po' fumoso.
Le variabili locali a funzione dichiarate static possono non avere un valore 
iniziale, e allora risultano not set. Ma allora a cosa serve poterle 
dichiarare? Le variabili locali static dovrebbero obbligatoriamente avere 
sempre un valore iniziale.
L'assegnamento di array avviene con copia dell'array. In realtà la copia 
effettiva dell'array avviene solo se la copia viene modificata. Molti 
programmatori invece si aspetterebbero che l'array copia sia un riferimento 
all'originale.
Non si possono annidare le funzioni. Se la funzione f() contiene la 
dichiarazione della funzione g(), allora: la funzione g() esiste solo se viene 
chiamata f(); la funzione g() risulta comunque visibile globalmente; se la 
funzione f() viene chiamata due volte, alla seconda chiamata viene segnalato un 
errore fatale perché risulta un tentativo di ridichiarare la funzione g().
function f()
{
	function g() { ... }
	...
}
f();  # dopo questa chiamata, g() esiste anche globalmente
g();  # posso chiamare g() anche se locale a f()!
f();  # errore fatale, g() viene ridefinita!
Tutto questo tende a confondere il principiante e induce a scrivere codice 
sbagliato. Alcuni algoritmi complessi si avvantaggiano della possibilità di 
scomporli in funzioni più piccole e specifiche. L'impossibilità di scrivere 
funzioni annidate impone di dichiarare funzioni visibili globalmente anche se 
usate solo localmente. Anche per i metodi delle classi sarebbe utile poter 
disporre di funzioni nidificate. PROPOSTA:
    * Implementare le funzioni annidate, con un meccanismo di visibilità 
naturale degli argomenti e delle variabili locali delle funzioni genitrici.
    * In alternativa, vietare le funzioni annidate. 
Non sono ammesse classi private all'interno di una classe. Tutte le classi, una 
volta dichiarate, sono pubbliche, anche se sono concepite solo per l'uso 
interno di un certo modulo di programma e non sono utilizzabili al di fuori di 
esso.
I nomi delle costanti predefinite, delle funzioni e delle classi non sono 
sensibili alla differenza tra maiuscole e minuscole. Ad esempio, la funzione 
per aprire un file si può scrivere indifferentmente fopen() FOpen() FOPEN(), 
mentre per le costanti predefinite si può scrivere null Null NULL true True 
TRUE. Non un vero problema, ma una questione di stile che spesso confonde i 
neofiti.
Il meccanismo per la definizione delle costanti non è coerente. Le costanti si 
definiscono con l'istruzione define(EXPR1, EXPR2); dove EXPR1 è una espressione 
che genera il nome della costante ed EXPR2 è il suo valore. Siccome il nome 
della costante e il suo valore si possono generare dinamicamente, alcuni 
programmatori sfruttano questa possibilità, ottenendo "costanti" di fatto 
variabili e dal nome a priori indefinito. Pessimo stile di programmazione. 
Inoltre si possono dichiarare costanti dal nome non valido che poi risulta non 
utilizzabile, come in questo esempio:
    define("@#$%", 123); 
Inoltre l'istruzione define() ammette un terzo argomento opzionale per dire se 
il nome della costante e' o non e' case-sensitive. I nomi delle costanti sono 
sempre globali, anche se definite dentro a una funzione. Inoltre la sintassi 
per la definizione delle costanti di classe in PHP5 usa una sintassi diversa. 
PROPOSTA:
    * Adottare la sintassi delle costanti di classe PHP5 anche per le costanti 
regolari, in modo che si possa scrivere
      const MAX_USERS = 123;
      invece che
      define('MAX_USERS', 123);
      Questo permette all'interprete di fare maggiori controlli sull'uso delle 
costanti, ed impedire che vengano generate dinamicamente. Inoltre i nomi delle 
costanti risultano case-sensitive.
    * Le costanti definite dentro a una funzione devono essere locali alla 
funzione. 
Manca supporto multi-lingue nelle stringhe. Le stringhe sono banalmente 
sequenze di byte, senza informazioni sul charset o sulla codifica del testo che 
contengono. L'estensione multibyte permette di aggirare il problema, ma sarebbe 
meglio un supporto nativo del linguaggio almeno per l'UTF-8.
Manca un tipo numerico per i calcoli monetari. Usare i tipi interi o a virgola 
mobile per i calcoli monetari induce a commettere errori subdoli che a volte 
portano a risultati inattesi. Ad esempio l'importo 0.10 (dieci cent) non può 
essere rappresentato in modo esatto dal tipo float, producendo un troncamento 
di cui spesso i programmatori non tengono conto. Usare la libreria BCMath per 
gestire i numeri decimali a precisione arbitraria è piuttosto scomodo.
Type juggling. Così si chiama il meccanismo automatico di conversione dei tipi. 
Il PHP tenta sempre di calcolare le espressioni convertendo il tipo di una 
variabile a seconda del contesto. Questo semplifica a volte il lavoro del 
programmatore, ma induce a commettere degli errori difficili da individuare. In 
certi casi sarebbe meglio imporre al programmatore una conversione esplicita.
Sintassi simil-C poco chiara. L'abbondanza di parentesi tonde e graffe ostacola 
l'apprendimento e oscura la struttura del sorgente. La scelta del C come 
linguaggio prototipo di tutti i nuovi linguaggi e' una usanza purtroppo 
diventata comune, ma e' una scelta poco felice.
Le espressioni possono contenere assegnamenti. E' una conseguenza dell'adottare 
il C come prototipo della sintassi. Il C era concepito per programmatori di 
sistema abituati al linguaggio assembly, e per i quali le astrusita' della 
sintassi del C erano nulla in confronto a quello che dovevano fare altrimenti. 
Tuttavia certe soluzioni sintattiche complicano l'apprendimento, oscurano il 
sorgente e danno ben pochi vantaggi. Gli assegnamenti dentro alle espressioni 
ricadono in questa categoria di soluzioni sintattiche astruse. Eseguire 
assegnamenti dentro alle espressioni puo' sembrare sintetico e fico, ma produce 
codice oscuro e difficile da debuggare. Nel linguaggio C c'e' il salvagente del 
tipo delle variabili che salva da molti guai, ma in PHP il meccanismo del type 
juggling maschera questi problemi che poi diventano difficili da risolvere. 
Paradossalmente, gli assegnamenti dentro le espressioni, che erano gia' una 
grana per i programmatori C, diventano ancora piu' subdole per i programmatori 
PHP. Poi il fatto che l'operatore di assegnamento "=" e l'operatore di 
confronto per uguale "==" siano molto simili, completa la frittata. Ad esempio, 
questo sorgente viene eseguito regolarmente dal PHP, ma non fa quello che 
potrebbe sembrare ad una prima lettura poco attenta:
$a = "pippo";
$b = "pluto";
if ( $a = $b )
	echo "nomi uguali";
else
	echo "nomi diversi";
Abbiamo assegnato dei nomi a due variabili, poi vogliamo stampare se sono 
uguali oppure no. Purtroppo l'espressione logica dell'if() fa una cosa 
completamente diversa perche' abbiamo scritto "=" (assegnamento) invece che 
"==" (confronto). In definitiva, l'espressione dentro all'if() sovrascrive $a 
con il valore di $b e poi stampa "sono uguali". Un linguaggio piu' rigoroso 
vieterebbe l'assegnamento dentro all'espressione logica dell'if(EXPR), o 
perlomeno avvertirebbe che il risultato finale della valutazione della 
espressione EXPR e' una stringa invece che un valore logico. PROPOSTA:
    * Gli assegnamenti sono istruzioni a se' stanti, e non si possono includere 
dentro alle espressioni.
    * Le istruzioni e gli operatori che si aspettano un determinato tipo di 
dato ma ne ottengono un altro, emettono un avvertimento. Poi possiamo anche 
ammettere che l'interprete esegua le sue conversioni implicite di tipo (il type 
juggling, appunto) nel tentativo di andare avanti, ma c'e' l'elevata 
probabilita' che il codice sia bacato ed e' bene che il programmatore lo 
sappia. 
NOTA BENE. Non sto dicendo che il PHP debba diventare un linguaggio fortemente 
tipizzato, cosa che lo snaturerebbe. Sto dicendo che certi tipi di errore nel 
codice sono quasi certamente un errore logico che l'interprete puo' facilmente 
rilevare e che dovrebbe segnalare nell'interesse del programmatore. Solo cosi' 
possiamo sperare che il PHP esca dalla nicchia delle "piccole applicazioni WEB" 
e diventare uno strumento di sviluppo robusto.
Assegnamenti dentro alle espressioni. La possibilità di eseguire assegnamenti 
dentro alle espressioni confonde il neofita e induce l'esperto a scrivere 
codice poco chiaro. Il calcolo di una espressione e l'assegnamento di un valore 
a una variabile sono invece due operazioni ben distinte.
Troppi livelli di priorità degli operatori. Ci sono circa 20 livelli di 
priorità. Questo costringe il programmatore a consultare frequentemente la 
documentazione oppure a usare una quantità di parentesi tonde inutili per 
evitare subdoli errori. Due o tre livelli di priorità basterebbero, lasciando 
l'uso delle parentesi tonde solo a quei rari casi di espressioni realmente 
complesse.
La funzione isset($x) ritorna FALSE se $x=NULL. Eppure NULL e' un valore, ed e' 
ben diverso lo status di una variabile unset da quello di una variabile che ha 
il valore NULL.
Si possono aggiungere dinamicamente proprietà ad un oggetto. L'istruzione 
$obj->xyz = 123; aggiunge la proprietà xyz all'oggetto, anche se la classe a 
cui appartiene l'oggetto non l'ha dichiarata esplicitamente. Questo è comodo in 
certi casi, ma più spesso il programmatore ha semplicemente sbagliato a 
scrivere il nome della proprietà, come in questo esempio:
class DBQuery {
	public db_conn = NULL;  # risorsa del DB aperto
	public curr_res = NULL; # risultato dell'ultima query
	function __construct($db_name)
	{
		$this->db_con = pg_exec("dbname=$db_name");
	}
	...
}
Visto l'errore? Il costruttore istanzia la proprieta' "db_con" invece che 
quella prevista, che ha una enne in piu'. L'interprete non lamenta il problema, 
e il programma non funzionera' come previsto. Consentire di creare nuove 
proprieta' "al volo" induce il programmatore a scrivere codice mal documentato, 
perché nella dichiarazione della classe dovrebbero essere elencate tutte le 
proprietà.
In un assegnamento e nel passaggio di argomenti a funzione, gli oggetti in PHP4 
vengono copiati; in PHP5 viene copiato solo il riferimento.
Identificatore	Case-sensitive?	Scope
Keyword	No	--
Costante	Si'/No	Globale
Variabile	Si'	Locale
Argomento formale di funzione	Si'	Locale
Funzione	No	Globale
Classe	No	Globale
Costante di classe (PHP5)	Si'	Scope protetto
Proprieta'	Si'	Scope protetto
Metodo	No	Scope protetto
Quadro degli identificatori e loro proprieta'.
Rimedi
Mentre aspettiamo che i volenterosi sviluppatori del PHP ci presentino un 
giorno una versione riveduta e corretta del nostro linguaggio di programmazione 
preferito (magari applicando anche qualcuno dei suggerimenti che ho indicato 
qui), ecco cosa possiamo fare per migliorare i nostri programmi:
    * Abilitare sempre tutti i messaggi diagnostici. Nel file php.ini deve 
apparire:
          error_reporting = E_ALL | E_STYLE | E_STRICT 
      (E_STRICT e' solo per PHP5).
    * Inviare i messaggi diagnostici in un log file che potremo esaminare con 
calma; attivare tutte le modalita' diagnostiche:
display_errors = Off
display_startup_errors = Off
log_errors = On
track_errors = On
warn_plus_overloading = On
    * Esaminare quotidianamente il log file, e lavorare in modo da eliminare 
tutti i messaggi di errore, inclusi i NOTICE piu' insignificanti. Il nostro 
lavoro sara' completo quando l'applicativo WEB sara' in grado di girare senza 
emettere alcuna lamentela.
    * Durante la scrittura del sorgente riporre la massima cura nella logica 
delle espressioni. Non mischiare tipi di dato diversi. Convertire 
esplicitamente le stringhe in numeri quando necessario, perche' questo migliora 
anche l'efficienza del programma.
    * Se durante lo sviluppo sorgono dei dubbi su determinati punti, lasciare 
sempre un commento chiaramente identificabile, e ripromettersi di rimeditare la 
questione a mente fresca. Io uso sempre mettere la parola "FIXME" nei commenti. 
Applicare questa regola in modo sistematico. In Unix basta fare un "grep FIXME 
programma.php" per vedere lo stato di maturita' raggiunto dal sorgente. La 
mancanza di FIXME e' un buon indice.
    * Le funzioni della libreria del PHP ritornano spesso un valore speciale 
per indicare le condizioni di errore, tipicamente FALSE o NULL. Ad esempio, 
fopen() ritorna una risorsa se ha successo, mentre ritorna FALSE su errore, per 
cui il test per verificare la condizione di errore e' if( ($f=fopen(...)) === 
FALSE ) die("apertura fallita");
    * Sottoporre il sorgente a un validatore sintattico/semantico, come 
PHPLint. Quando un sorgente supera la validazione di PHPLint ed e' stato 
depurato da tutti i FIXME, ci sono buone possibilita' che funzioni a dovere.
    * Contemplare con compiacimento il proprio sorgente. Stampare le parti piu' 
complesse e rileggere attentamente, seguendo la logica del programma 
passo-passo. Cambiare i nomi di funzioni, variabili, ecc. fino a quando 
riflettono bene il loro significato. Le funzioni dovrebbero esprimere azioni, 
le variabili dovrebbero esprimere cose/entita' reali. Curare la strutturazione 
del sorgente e l'indentazione delle istruzioni, adottando uno stile uniforme. 
Aggiungere linee di spazio per evidenziare gruppi di istruzioni che eseguono un 
dato compito, magari indicando in un commento cosa fanno, cosa entra e cosa 
esce; tale gruppo di istruzioni e' suscettibile di essere poi trasformato in 
una funzione. Rendere il programma ben strutturato e modulare spesso produce 
codice piu' facilmente riutilizzabile perche' se ne possono estrarre 
determinate parti.
    * Non cominciare a buttare giu' codice senza avere le idee chiare sul da 
farsi. Ogni progetto, anche se piccolo, deve avere una analisi dei requisiti 
dettagliata. Il livello di dettaglio deve essere tale da lasciare il 
programmatore concentrarsi sul "coding" e basta.
    * Adottare un buon programma per il controllo di versione, come CVS. E' 
l'unico modo per scoprire come mai un programma che funzionava perfettamente 
fino a ieri, improvvisamente si e' messo a fare le bizze dopo le ultime 
insignificanti modifiche di oggi. Se il progetto viene sviluppato da diverse 
persone, e' l'unico modo di tenere sotto controllo la situazione evitando 
derive verso il caos. Esistono interfaccie grafiche di facile uso: usiamole!
    * Costruire automatismi per il rilascio del programma e il deploy. In Unix 
ci sono "bash" e "make" con i quali e' facile costruire questi piccoli 
automatismi. Ricordarsi di mettere un numero di versione e di "taggare" il 
sorgente rilasciato sul CVS.
    * Mantenere un elenco dei problemi rimasti in sospeso (la bug list). 
Esistono programmi appositi, ma in mancanza d'altro un semplice file di testo 
puo' andare. Mettere anche questo sotto CVS, cosi' da sapere chi quando e come 
lo ha modificato.
    * Beta testing. Lo devono fare dei programmatori, non persone digiune di 
informatica. Solo a un programmatore puo' venire in mente di inserire il valore 
"-1" nel campo "quantita'" della maschera di ordinazione di un prodotto. Solo a 
un programmatore puo' venire in mente di interrogare lo script inviando valori 
deliberatamente artefatti. In generale, eseguire test di safety e securety. 
Usare le specifiche dell'analisi dei requisiti e tentare di fare tutto il 
contrario di quello che e' indicato li': mettere numeri dove il programma si 
aspetta lettere e viceversa, lasciare vuoti i campi obbligatori e riempire 
all'inverosimile quelli facoltativi. Richiamare le pagine del sito in ordine 
arbitrario passando dall'history del browser. Disabilitare cookies e JS: che 
succede?
    * Ok, il Cliente vuole il prodotto entro domani e ce lo paga anche poco. Se 
la priorita' e' il tempo rispetto alla qualita', adeguarsi a sviluppare codice 
"basta che vada", ma la garanzia vale una settimana e deve essere controfirmata 
come clausola vessatoria nel contratto (formula "visto e piaciuto").
THE END (per adesso...)

d'accordo in alcuni punti, ma da neofita di questo splendido (IMHO) 
linguaggio non mi trovo d'accordo con altri...
credo che il punto di forza di php sia proprio dovuto al fatto che sia 
semplice per i neofiti
non conosco altro linguaggio di "programmazione"...e il php l'ho imparato 
leggendo 1 unico libro di McGraw Hill pagato 15,50 ? e aiutandomi con la 
Function List su 
www.php.net
direi che è questo il vero punto di forza di php... perchè complicare le 
cose rendendolo sempre più simile ad altri linguaggi?
da quel che vedo le novità di php5 sono tutte fatte quasi su misura per i 
coder Java... o almeno... così dicono i miei Guru...
non so, forse non ho ancora l'esperienza per fare affermazioni simili... 
però ci tenevo a dirtelo ^^ 

 THE END (per adesso...)
E' il solito discorso. Ogni persona vorrebbe il linguaggio uguale ai 
suoi gusti. Io ad esempio amo l'immediatezza di php e la sua sintassi.
Però lo vorrei molto più orientato agli oggetti e con una tipizzazione 
più forte (anche se la tendenza dei linguaggi moderni è il contrario) e 
con altre caratteristiche tipo i packages (da cui importare le classi o 
insieme di classi).
Poi non sarebbe male un webserver dedicato magari con la possibilità di 
avere una cartella privata interna dove mettere classi, frameworks e 
files di configurazione.
Sono idee.. ma è vero che PHP è un linguaggio che è stato "adattato" nel 
tempo..
Ciao
Simone

 files di configurazione.
A me piace PHP interfacciato come CGI, ben scollegato dal WEB server,
cosi' posso utilizzare un mix di linguaggi secondo l'opportunita' e
posso fare gli aggiornamenti senza dover ogni volta coinvolgere tutto.
Pero' un WEB server dedicato potrebbe tornare utile per implementare il
caching del codice, come fa Tomcat con il bytecode delle JSP.


 però ci tenevo a dirtelo ^^ 
Be', se non hai trovato difficolta' col PHP come primo linguaggio, allora
per te Java sara' una passeggiata, perche' ha meno eccezioni ed e' piu'
"lineare", ma poi di fatto e' piu' macchinoso da usare. Io penso che una
convergenza PHP-Java (piu' rigore a PHP e smussare gli angoli a Java)
potrebbe dare ottimi frutti.
