Come migliorare l’ambiente di PHP
Martedì 14 Aprile 2009 - 15:20
di Riccardo Degni
Qualche giorno fa mi è giunta una mail ufficiale dalla Zend Technologies il cui scopo principale era quello di presentare l’uscita di Zend Server, un web server “concepito per gestire le applicazioni PHP che necessitano di un alto livello di affidabilità, prestazioni e sicurezza” (potete trovare una vasta gamma di informazioni per la rete su questo nuovo prodotto).
Ma quello che più mi ha colpito di quella mail non è stato l’annuncio del nuovo prodotto-bomba, bensì il resoconto di Zeev Suraski, uno dei co-fondatori di Zend Technologies, sulla conferenza tenuta in Quebec.
Il suo intervento era intitolato “Perché PHP è vincente”. E solo con questo titolo direi che ci sarebbe da discutere per ore.
Dopo avere presentato una nutrita collezione di Web Apps di enorme successo che fanno di PHP la loro base (come Facebook, Wikipedia e molte altre), Zeev si pone questa domanda: “ora che il linguaggio ha raggiunto una notevole stabilità, come è possibile migliorare ulteriormente l’ambiente PHP?”.
Insomma, quali sono le mosse che bisogna adottare per incrementare la qualità complessiva:
- degli strumenti in mano agli sviluppatori (Server, IDE, ambienti di sviluppo)
- del codice PHP stesso
- delle metodologie di programmazione e gestione dei diversi ambienti
Come indica il sito ufficiale, Zend Server, per esempio, dovrebbe porsi come nuova tecnologia in grado di fornire migliori prestazioni e caratteristiche (Data Caching in prims) e ridurre il margine di differenza tra sviluppatore ed amministratore.
Ora mi rivolgo a tutti gli sviluppatori ed utilizzatori di PHP, rivolgendo loro questa stessa domanda che Zeev ha precedentemente posto nella conferenza ufficiale e che da il titolo a questo post. Voi come migliorereste l’ambiente di PHP?
Categoria: PHP e Open Source | Permalink
Commenti
1
Per migliorare…
So che è un’idea assurda, ma riscrivere le funzioni (almeno le più importanti, penso a quelle per gestire ad esempio le stringhe) per portarle ad oggetti, con naming convenction ed error handling decenti.
Questo dimostrerebbe una notevole serietà e voglia di andare avanti da parte della Zend, però mi rendo conto del lavoro che richiederebbe..Creare un IDE vero, dedicato solo a PHP, non scritto in java (altrimenti si appendono al tram le performance), uno Zend Studio che non si appoggi a PDT e sia possibilmente open source.. Reattivo, semplice e al contempo potente.. Cosa che al giorno d’oggi non esiste..
Dare una potenziata al motore, velocizzarlo come si deve, e se necessario, introdurre la possibilità di compilare php per aumentarne la velocità. Avere ottimi software come ad esempio Magento, e soffrire le peggiori pene per un engine lento è anacronistico..
Facendo cosi inoltre si potrebbe pensare di iniziare ad utilizzare seriamente PHP fuori dal solito stack LAMP, magari come un serio linguaggio di scripting per CLI (a proposito, fornire un’interfaccia interattiva da riga di comando come fanno python e ruby!), e soprattutto in ambiente GTK..Per ora basta, credo… :)
2
Insomma avere Ruby e Rails :P
3
Ma anche no…:)
L’unica cosa che invidio davvero a Ruby è il fatto di NON essere stato scritto un pò a caso e da gente senza attenzione per i dettagli…:)
4
Sono d’accordo con Lloyd, ciò che manca a PHP non è un IDE, oddio pure quello se vogliamo ma un sacco di cose inerenti al puro linguaggio.
Cose che oltre a Ruby, ci sono persino in Javascript.
Per esempio una gestione degli errori seria, o una decisa virata a oggetti come dice giustamente Lloyd.
Così com’è mi ricorda tanto il Tubo Pascal prima di Delphy, una roba con oggetti embrionali, comodi sì ma pur sempre un’aggiunta e così è oggi per il PHP, comodi, ma senza tante cose importanti come l’ereditarietà ad esempio.
Poi una corretta gestione degli errori, la possibilità di intrappolarli tutti e non solo una parte, di poter utilizzare insomma try/catch così come lo si usa in Java, Javascript e altri linguaggi a oggetti puri.
E poi la sicurezza, cavolo è arciinsicuro un linguaggio che lascia nelle mani degli utenti la possibilità se scegliere di fare un po’ di controllo o niente o farlo in modo serio, ma perché cacchio non obbligare a farlo seriamente e basta. Safe mode, ma ancora esiste? Register globals ma perché? $_REQUEST/$POST/$_GET senza un minimo di sicurezza se non a posteriori se ti ricordi di farlo, e se qualcosa ti scappa?
Un controllo sulle query che fa acqua, ho letto giusto ieri che le funzioni Mysql improved sono state deprecate… ma perché sono degli alias di altre funzioni?
E perché deprecarle, se una funzione non va la si deve togliere, e perché le improved sì e le mysql normali ancora girano?
Portiamo tutto su PDO! Bene, implementatemelo sempre non a seconda delle scelte delle installazioni di PHP, è sicuro PDO? Bene usiamo quello, ma obblighiamo il programmatore a usarlo in modo sicuro.
Basta fare l’esempio del coltello che può essere usato per fare del male o per tagliare la bistecca, è una balla, qui abbiamo un coltello che dopo aver tagliato la bistecca ti accorgi che invece era una gamba.
IDE? Ben vengano, ma dopo. Cacchio!M.
# - postato da Marco Grazia - 14 Aprile 2009 - 18:19
5
In PHP il try/catch c’è, le classi pure, l’ereditarietà pure.
# - postato da Pino - 14 Aprile 2009 - 19:45
6
In effetti concordo pienamente col commento di Lloyd. A PHP serve un IDE veramente potente e veloce veloce veloce!. Serve il refactoring, serve poter navigare all’istante da una chiamata di funzione alla sua definizione.
PHP deve fornire un linguaggio moderno e a oggetti. Deve costruire programmatori orientati agli oggetti! Sinceramente se fossi in Zend rinuncerei totalmente alla retrocompatibilità creando un convertitore…
L’incredibile è che chiunque potrebbe realizzare un ide competitivo rispetto ai tanti esistenti, non riesco a realizzare perchè nessun azienda voglia investire idee e soldi sull’infrastruttura di questa tecnologia.
# - postato da Gianluigi Salvi - 14 Aprile 2009 - 23:17
7
Sviluppo felicemente con Php ma mi rendo conto che per migliorare realmente questo linguaggio bisognerebbe riscriverlo al 95%.
8
Secondo me servono più strumenti open di qualità. PHP è nato come linguaggio open ma poi i tool zend sono a pagamento.
Gli oggetti vanno sicuramente migliorati ma non credo sia giusto obbligare tutti ad utilizzarli, il successo di php è anche nella sua semplicità. E chi è agli inizi della programmazione (non tutti arrivano a php dopo studi seri di informatica) ha serie difficoltà con la oop.
9
Io sono passato a python.
Purtroppo PHP è un linguaggio troppo usato e soprattutto usato da troppi incompetenti.
In mezzo ci sono professionisti eccezionali ma affogano nella fuffa.
10
Il problema principale collegato alla realizzazione di un nuovo IDE, è la necessità di dover creare un programma multipiattaforma.
A differenza del normale share del “navigatore web”, negli sviluppatori PHP c’è una altissima percentuale di persone che utilizzano sistemi operativi Linux e Mac.
Dovrebbero sviluppare un programma utilizzando le GTK di Gnome, oppure le QT di KDE, oppure XUL di Mozilla (ma esiste già Komodo Editor).
Sarebbe decisamente interessante se sviluppassero un editor utilizzando PHP-GTK (http://gtk.php.net) , secondo me avrebbero moltissimi aiuti dalla comunità open source.
Il PHP-GTK è poco utilizzato, pubblicizzato e sviluppato.Anche la CLI ha un potenziale enorme e potrebbe sicuramente diventare più diffusa tra i sistemisti.
Per il resto ci vorrebbe una riorganizzazione tra funzioni e metodi. Al momento sono tutti mischiati, per molte funzionalità è possibile solo accedere tramite funzione. Riorganizzare le funzioni in classi (lasciando la possibilità di utilizzare le chiamate semplici alle funzioni) sarebbe una buona occasione per “riordinare”.
Accelerare lo sviluppo delle nuove versioni di PHP. L’uscita del PHP 5.3 ormai imminente ci ha messo davvero troppo tempo, ci vogliono maggiori risorse nello sviluppo del core.
11
Lavoro in PHP ormai da anni ed ho sviluppato praticamente quasi sempre in ambiente LAMP. Ultimamente per esigenze dell’azienda programmo in PHP su Win2003 / IIS 6 / Sql Server 2005 e devo dire che uno dei limiti più evidenti sono le prestazioni.
Molte grandi aziende sono vincolate nella scelta dei sistemi e una maggiore “integrazione” verso la parte Microsoft credo che sarebbe molto interessante..# - postato da Angelo - 15 Aprile 2009 - 12:20
12
Dire che PHP è perdente perché iniziare è semplice vuol dire non capire proprio i suoi vantaggi.
Si è detto molte volte in questa sede e da utenti molto più autorevoli di me che l’approccio intuitivo di PHP non è un punto debole ma un punto di forza. Il fatto che poi questo apra la porta a migliaia di smanettoni che non sanno o non vogliono capire come tirar fuori il meglio da questo linguaggio di certo non gli toglie il valore che ha.
Se costruisco qualcosa di qualità con PHP, forse avrà meno valore perché altri lo usano male?
Se è vero che proprio per la sua semplicità molti costruiscono cattive applicazioni, non vuol dire che mi debba conformare alle loro worst-practices.Ho sentito molte persone denigrare PHP per la sua popolarità, andando alla ricerca di altri linguaggi solo per poter dire “io uso roba complicata, roba d’elite!”
Al di là di questi discorsi secondo me sterili, il dibattito costruttivo è quello che tira fuori le idee necessarie agli sviluppatori per il miglioramento del prodotto e l’implementazione di quello che gli manca, cosa che tra l’altro è sempre in atto, visti i grandi passi in avanti fatti dalla versione 4 alla 5 (pur non perfetta), e le previsioni per la futura release della 6 (vedi implementazione di namespaces, supporto nativo multibyte etc).
Di fatto è un linguaggio vivo e (tolti gli smanettoni che tanto spaventano gli elitaristi) supportato nel miglioramento da molti programmatori validi.Per quanto riguarda i consigli sulla trasformazione di PHP in native-OOP: il fatto che di base non sia OOP è un vantaggio perché dà accesso alla struttura di basso livello. Per me il bello è proprio la libertà di progettare la mia struttura logica degli oggetti senza dover usare quella di classi/oggetti nativi, con la massima libertà.
Nel basso livello, trasformare espressioni come $a = trim($b) in $a = $b->trim() ha poca rilevanza (io dentro il codice di una classe da 1000 righe preferisco la prima).A mio avviso il basso livello potrebbe essere migliorato in modo sostanziale, trasformando ad esempio quei costrutti del linguaggio (explode(), trim() etc) in funzioni, per permettere una vera compressione del codice come ad esempio in Javascript, dove la gestione delle funzioni e dei costrutti è molto più flessibile, e scrivere qualcosa come:
[’a2.c64′].toString().split(”.”)[0]
fa quello che ci si aspetta e ha notevoli vantaggi.# - postato da EmanueleDG - 16 Aprile 2009 - 11:02
13
@Michele: non credo che il fatto che sviluppatori inesperti usano php sia una giustificazione al non renderlo strettamente oo. Se non sono un ingegnere non mi metto a progettare un ponte, idem dovrebbe essere per la programmazione.
14
@EmanueleDG: IMHO in Javascript quella sintassi è possibile perché ogni valore restituito da quella serie di istruzioni è un oggetto.
Correggimi se sbaglio, ma [’a2.c64′] è un array che in JS è un oggetto.
Ha un metodo toString() che ritorna un oggetto stinga che a sua volta ha un metodo split che ritorna un oggetto array.
Nella parte finale: split(”.”)[0], con quel [0] ti stai riferendo ad una proprietà di un oggetto (ovvero il primo elemento dell’Array).
In PHP come giustamente sottolineavi non è possibile fare una cosa del genere:
explode(’.', ‘a2.c64′)[0]
Ma non tanto perché explode è un costrutto e non una funzione (cosa che comunque non credo sia vera), ma più che altro perché un array non è un oggetto!
Mentre invece è possibile fare una cosa del genere:
function foo(){
return new bar();
}
foo()->method();
15
Io credo che il punto sia un’altro. Perchè si dovrebbe usare PHP?
Il motivo fino ad oggi è stata l’estrema semplicità e la presenza di un’enorme quantità di materiale opensource gratuito. Il principale contro è la più totale mancanza di modularità.
Variabili globali, include dentro include, difficoltà di trovare una variabile. Ecco il vero problema di php.
Prendo uno script già fatto. Ok. voglio ampliarlo? Impossibile. Voglio estrarne un pezzo e riusarlo? Impossibile. Non ci sono nemmeno le Dll o pezzi di codice isolati facili da riusare.
Basterebbe un tool di pulizia del codice o almeno di refactoring per eliminare le cose citate sopra e php migliorerebbe di un milione di volte…
# - postato da Gianluigi Salvi - 16 Aprile 2009 - 21:31
16
Però Gianluca, quelli secondo me sono problemi che si possono risolvere scrivendo codice PHP in un certo modo piuttosto che in un altro. Cioè, non sono tanto legati al linguaggio, ma più che altro allo stile di programmazione…
17
Perché PHP è vincente … :SBONK:
@michele, “non tutti arrivano a php dopo studi seri di informatica“, verissimo, perche’ se hai fatto studi seri di informatica PHP lo escludi a priori!
Se questi fanatici dell’ibrido non implementano runkit ed operator in core il linguaggio sara’ castrato per altri N anni. Via PECL, SPL, ed altro ancora, ci sono possibilita’ notevoli ma i libri ancora scrivono come riferimento ad un print su una variabile da form (register_global, magic_quotes, etc etc … tutta roba che grazie al cielo verra’ falciata via)
@EmanueleDG, “io dentro il codice di una classe da 1000 righe preferisco la prima” … e poi invidi JavaScript?
se ti piace una sintassi tipo questa
[’a2.c64′].toString().split(”.”)[0]
in PHP
A(’a2.c64′)->toSString()->split(’.')->{0};eccoti il codice :D
class S {
protected $_value;
public function __construct($value){
$this->_value = $value;
}
public function split($c){
return call_user_func_array(’A', explode($c, $this->_value));
}
}
class A implements ArrayAccess {
public function __construct(){
$arguments = func_get_args();
foreach($arguments as $key => $value)
$this->$key = $value;
}
public function offsetExists($i){return isset($this->$i);}
public function offsetGet($i){return $this->$i;}
public function offsetSet($i, $value){$this->$i = $value;}
public function offsetUnset($i){unset($this->$i);}
public function toString(){
for($a = array(), $i = 0, $length = count($this); $i $i;
return new S(implode('’, $a));
}
}
function A(){
static $class;
if(!isset($class))
$class = new ReflectionClass(’A');
$arguments = func_get_args();
return $class->newInstanceArgs($arguments);
};… PHP offre molto, poi metti tutto assieme e le performances vanno a farsi benedire ^__^ , insomma, questo linguaggio piu’ lo conosci piu’ ti fa imbestialire per le carenze concettuali, performances, etc, etc!
18
@Fra_T: sì, in Javascript anche gli array e le funzioni sono oggetti (le stringhe credo di no, sebbene si possano istanziare come oggetti e hanno metodi propri), ma non è quello il motivo che permette la concatenazione delle istruzioni.
Su PHP per esempio questa istruzione non funziona:
empty(trim($name))
perché empty() non è una funzione ma un costrutto, come dice la nota in fondo:Note: Because this is a language construct and not a function, it cannot be called using variable functions
Inoltre è poco rilevante che in PHP un array non sia un oggetto, perché la sintassi $arr[$index] è propria degli array, e non funziona su
explode(’.', ‘a2.c64′)[0]
dove explode restituisce proprio un array.@andr3a: dicevo di preferire la comprimibilità sintattica di JS che permette di accodare le istruzioni una dietro l’altra a prescindere che siano oggetti o stringhe o altri tipi :)
Non c’è dubbio che quella sintassi si possa replicare con gli oggetti in PHP visto che un metodo di un oggetto può restituire l’oggetto stesso, però preferirei scrivere soloexplode(”.”, implode(”", array(’a2.c64′)))[0];
avvalendomi della sintassi nativa piuttosto che scrivendo una mini-library per poterlo fare :)
A livello di human-readability molti dicono che sia preferibile il chaining method perché la cronologia delle operazioni coincide con l’ordine di scrittura dei metodi.
Sono d’accordo e infatti la compressione di questo tipo che si potrebbe raggiungere con la programmazione strutturale di PHP è molto bassa.
Certo l’eccessiva compressione è deleteria quando si deve riprendere il filo di un proprio script a distanza di tempo, tuttavia a volte quella flessibilità sarebbe così necessaria…Circa le carenze sono pienamente d’accordo, più lo uso e più vedo i limiti.
Per esempio l’impossibilità di determinare lo scope in varie circostanze (e.g. codice richiamato da include()) da risolvere con varie pezze mem-consuming, tipo re-istanziare con global in locale tutte variabili globali etc.Ho letto che sul PHP 5.3 è supportato un namespacing esteso, che permetterà per esempio con ::include() di risalire allo scope globale, più le possibilità di rendere implicite le concatenazioni dei namespace: PHP namespace in 5.3 version, spero vada subito in stable.
# - postato da EmanueleDG - 19 Aprile 2009 - 16:18
19
@EmanueleDG: non metto in dubbio che empty sia un costrutto. Ma non penso proprio che lo sia explode e trim. Prova ad esempio questo:
var_dump( function_exists(’empty’) ); // False, perché è un costrutto
var_dump( function_exists(’explode’) ); // True, perché è una funzione
var_dump( function_exists(’trim’) ); // True, perché è una funzionePer questo dico che se in PHP non è possibile una sintassi del tipo explode(’.', ‘a2.c64′)[0], la causa non è da attribuire al fatto che explode sia un costrutto.
Inoltre nota che in Javascript $arr[$index] NON è propria SOLO degli array, ma anche degli oggetti. Ad esempio:
obj[’prop’] // leggo una proprietà
obj[’method’]() // eseguo un metodoPer questo quando vedo una cosa del genere:
[’a2.c64′].toString().split(”.”)[0]
Che si può scrivere anche:
[’a2.c64′][’toString’]()[’split’](”.”)[0]Mi vengono in mente i chaining method possibili anche in PHP, ma appunto se si utilizzano oggetti (vedi esempio di andr3a). La mia è comunque solo una deduzione da smanettone :P
@andr3a: che guru! :D
20
indipendentemente da funzione/costrutto, non è possibile
function prova()
{
return Array(1,2,3,4);
}prova()[0];
ma come dice andrea ->{0}
io ho realizzato da tempo ed è già operativo
un framework del linguaggio che implementa molte delle sintassi tipiche dei linguaggi di programmazione full oopho la classe String, i tipi numerici, gli array, tutti implementati in una visione al 99% simile a quella di java
in più ho implementato polimorfismo completo (overloading e overriding + type hinting completo)
il tutto senza utilizzare nessuna estensione pecl
certo ci sono alcune limitazioni, come per esempio la possibilità di non estendere i tipi INT e FLOAT
# - postato da Gunn - 04 Maggio 2009 - 21:48
21
tutti voi siete programmatori esperti, probabilmente ricordate l’epoca di php 4, a quel tempo php era il meglio che si potesse trovare sul mercato perché le alternative si chiamavano asp, coldfusion e perl, tutti decantavano la potenza di php… da allora il linguaggio è migliorato sotto tutti gli aspetti citati(performance,OOP) eppure ora riceve più critiche che elogi, tutto ad un tratto sembra indispensabile poter scrivere inline roba del genere
[’a2.c64′].toString().split(”.”)[0]
e siamo convinti che si l’unico modo, il modo migliore di splittare una stringa…
signori, onestamente trovo questo aspetto del tutto marginale.
la sintassi di php deriva da C, si può scrivere buon software con il set di strumenti presenti in questi 2 linguaggi e poter scrivere inline chilometrici non rende buoni programmi mal pensati, anzi, è il motivo per cui non avete investito il vostro tempo su perl.i costrutti che invidio veramente a ruby e python sono lambda/closure e moduli, che avremo in php6. concordo sulle priorità del team di sviluppo, dissento e in modo critico sulla mancanza di “ambizione” dei leader del progetto, non mi piace che ci si accontenti per un linguaggio che è il più usato al mondo nel settore più promettente, di compromessi al ribasso come “\” per i namespace e “array()” al posto del più standard “[]”, le lambda possono rivoluzionare il linguaggio e sono invece state accolte con molta freddezza, etc.
continuo a ritenere php una buona scommessa per il futuro e se conoscete python e ruby oltre a javascript, avrete notato che non sono perfetti, nemmeno loro, ma per continuare ad essere il linguaggio più usato lato server, il team deve puntare più in alto, continuare a confrontarsi con le migliori alternative disponibili ed avere il coraggio di rimediare agli errori commessi in passato.
buon lavoro
# - postato da devsmt - 12 Maggio 2009 - 14:44
22
Concordo al 100% con devsmt
# - postato da Gianluigi Salvi - 13 Maggio 2009 - 10:39