altre destinazioni

vedi anche

ultimi post

ultimi commenti

tag principali

categorie

archivi

powered by

  • WPFrontman + WP

friends

copyright

  • © 2004-2011
    Ludovico Magnocavallo
    tutti i diritti riservati

Ruby e i programmatori con la puzza sotto il naso

15 luglio 2006

7 commenti

tag

categorie

Rispondo qui ad un commento di Alberto al mio ultimo post sul benchmark dei tre principali framework web, dato che alcune sue affermazioni meritano una risposta più elaborata di quanto possa entrare in un commento. Nel mio post, commentando le pessime performance di PHP, scrivevo:

Dopo anni di dominio incontrastato, il primato di PHP per le applicazioni web scricchiola sempre di più: il pessimo design del linguaggio, la qualità mediocre della community, lo scimmiottamento di Java in PHP 5 mentre il resto del mondo Open Source predilige linguaggi più lineari come Python e Ruby, e ora le performance scadenti.

Ad Alberto, sempre convinto dell’eccellenza di ezPublish (wink) le mie affermazioni non sono piaciute:

Mi sembra un po’ azzardato dire che il mondo opensource predilige ruby/rails. Ad ogni modo io credo che ruby sia un ripiegamento per i programmatori java con la puzza sotto il naso, quelli che “php è poco professionale”.

Resta il fatto che php5 è ancora poco utilizzato, ma quando verrà utilizzato su larga scala magari vedremo migliorare anche le performance.


Ovviamente non sono d’accordo con nessuna delle affermazioni di Alberto. Forse ho esagerato parlando del “resto del mondo Open Source” che predilige Ruby/Python rispetto a PHP: più che gli smanettoni o chi personalizza applicazioni come WordPress/ezPublish cui sembra far riferimento Alberto, pensavo ai vari guru e alle teste pensanti che influenzano le opinioni, le tecnologie e il futuro prossimo venturo. Python e Ruby sono infatti linguaggi molto più eleganti, sofisticati (metaprogramming, metodi e oggetti first-class, reflection, ecc.) e potenti (generatori/iteratori, named arguments, unicode, ecc.) di PHP, e hanno alle spalle una community di teste pensanti di livello decisamente più elevato. Non per niente molti dei guru di Python lavorano per Google, compreso il creatore Guido van Rossum e l’italiano Alex Martelli.

Dire che Ruby è un ripiegamento per programmatori Java con la puzza sotto il naso è, oltre che poco corretto, decisamente fuorviante. Non ci sono più molti dubbi (a parte forse per le mega società di consulenza) sul fatto che J2EE è un catafalco complesso e poco produttivo, WS-* si avvia a ripetere il fallimento di CORBA, e SOA sta per raggiungere il cimitero dove le buzzword riposano in pace. Perchè stupirsi quindi se alcuni programmatori Java si guardano intorno alla ricerca di soluzioni meno “Enterprisey”, e screditare loro e le tecnologie alternative cui si rivolgono con una definizione riduttiva? Mi sembra invece naturale che chi sta cercando un’alternativa a J2EE si rivolga prima di tutto a Rails, il framework che ha dato una scossa allo sviluppo Web e che negli Stati Uniti sta creando un bel numero di posti di lavoro. Oltretutto, non mi sembra che 37Signals, Joyent/Textdrive, e le tante altre società Web2.0 che utilizzano Rails siano programmatori Java delusi e un po’ snob.

Riguardo a PHP5, secondo me non prenderà mai veramente piede. Il successo di PHP è dovuto ad una enorme base di utenti poco sofisticati, che apprezzano la facilità di deployment e la sintassi (apparentemente) semplice e poco restrittiva. Utenti che difficilmente trarranno vantaggio dalle nuove funzionalità di PHP5, che ha cercato di rendersi appetibile ai programmatori Java introducendo funzionalità proprie di quel linguaggio che poco hanno a che vedere con l’utilizzo “medio” di PHP, e aggiungono complessità inutile invece di semplificare la vita a chi sviluppa. Oltretutto, il 99% delle applicazioni PHP è sviluppato per PHP4 e non credo che nessuna di queste correrà il rischio di rinunciare ad una larga fetta dei propri utenti per quel poco di funzionalità in più aggiunto da PHP5.

7 commenti

  • Alberto Mucignat
    15 luglio 2006 #

    azz se ho sortito questo effetto significa che ho colpito nel segno (wink!)

    btw, ti rispondo con calma. oggi fa caldo, vado al mar.

    ciao

  • Matteo
    15 luglio 2006 #

    A mio parere Ludo ha ragione sulla sorte che avranno i diversi linguaggi. PHP5 cerca una fetta di mercato già occupata, e brillantemente. Non sottovaluterei però l'enorme base di utenti php4. Cosa faranno costoro? Io mi ci metto dentro. Quello che ho sempre apprezzato di php è stata la sua semplicità d'uso, per chi proviene dal client scripting. Non mi trovo a mio agio con Python, sono affascinato dalla buzzword Ruby, ma sinceramente se dovessi scegliere ora come ora, sarei molto titubante. Intanto mi studio Flex2. :) Ritorno all'interfaccia…

  • riffraff
    17 luglio 2006 #

    C’è da dire una cosa su php5: alcune ficiur ammiccano a python (i.e. __set/__get/__call) ma ci vorrà una vita perché riescano a infilarsi nella cultura del phpista medio, la comunità php ha troppi cattivi esempi[1], ed è molto più difficile cambiare la testa di un milione di persone che di cento.

    [1] m’è venuto in mente l’esempio di captcha su phpsec.org che soffriva di race condition.. misà che pure s9y da alberto lo fa :)

  • Folletto Malefico
    2 agosto 2006 #

    A me peraltro risulta che PHP5 sia una versione "intermedia", in modo analogo al versioning del Kernel 2.5 che era una versione di sviluppo (pari/dispari).
    Ma non ritrovo il link per avvalorare tale fonte, quindi prendetela con le pinze.

    In argomento comunque, credo che PHP abbia l’enorme vantaggio di non avere praticamente alcuno scalino sul livello "zero", ovvero quello da "cos’è PHP" a "scrivo PHP malissimo": Apache lo supporta nativamente, scrivere un blocco PHP nel normale HTML è banalissimo, etc.

    Questo garantisce una soglia di adozione che si fonde benissimo nello spazio fra una pagina statica ed una dinamica.

    Questa cosa però ha fatto pagare a PHP lo scotto (forse anche per le sue origini meno nobili) di non essere un efficiente linguaggio quando si deve progettare qualcosa IN PHP. La differenza è sostanziale ed è ancora più rilevante quando confrontiamo le velocità dei framework (e notiamo che PHP è l’unico a perdere connessioni).

    Cmq, sono perfettamente d’accordo sul discorso J2EE (Java mi sta un po’ qui, se vuoi passa a vedere un articolo in merito all’Usabilità del Codice che ho scritto) e mi auguro davvero che altri linguaggi, meno "gonfiati" dal marketing (di SUN in questo caso) ma più ideologici, arrivino al successo.

    Aggiungo una domanda che mi è risaltata fuori ora: io mi continuo a chiedere perché Google faccia così poco evangelismo a riguardo di Python… non vi pare strano?

  • Filippo Fadda
    7 agosto 2006 #

    Francamente non sono d’accordo con nessuna delle opinioni. Ho sviluppato per anni applicazioni client/server e three tier prevalentemente su piattaforma Windows e riconosco che negli anni ’90 lo sviluppo per componenti l’ha fatta da padrone. All’epoca era "quasi" necessario utilizzarli ed effettivamente potevano, in alcuni casi, abbreviare i tempi di sviluppo (non sempre).

    Poi alcuni linguaggi OOP, fortemente tipizzati, come ad esempio l’Object Pascal, non hanno mai avuto i generici (se non attraverso librerie di terze parti che li emulavano), erano carenti sotto il profilo delle espressioni regolari, vi erano pochi contenitori, tra l’altro anche male implementati, ecc. Ma erano tutte questioni "accessorie" non determinanti, perché quelli erano gli anni dei componenti e ciò che serviva era un RAD con un buon supporto per i componenti. Addirittura spesso si usavano strati di accesso ai dati intermedi come il BDE, ODBC, ADO, che determinavano un degrado delle prestazioni. ma ci si accontentava.

    Oggi gran parte delle applicazioni gestionali (e non solo) vengono sviluppate per funzionare su Internet, dove i componenti non servono più a niente. Se volete si stanno facendo strada dei componenti che sono scritti in JavaScript, e che utilizzando AJAX fanno delle chiamate asincrone per aggiornare solo una parte della pagina. Ma siamo ancora indietro. I componenti sono nati con Win32, perché la parte più complessa da programmare in Win32 era l’interfaccia. Tutto poggia sulla Window Procedure e la correlata gestione dei messaggi. Per fare una finestra era necessario usare un editor di risorse e gestirsi tutti i messaggi a mano. Lo scenario è completamente cambiato.

    Oggi si utilizza un protocollo stateless, attraverso il quale si richiamano delle pagine, che si possono scrivere con praticamente qualunque linguaggio, ma sono e rimangono degli script che pescano dei dati da un DB, li elaborano e restituiscono una pagina Web. L’output è puro e semplice HTML o XHTML, sempre e comunque uguale e la formattazione avviene per mezzo di un altro linguaggio ancora, i CSS. Non si usano più componenti che fanno uso delle API Win32, oppure che usano la VCL o ancora MFC, è puro e semplice HTML. Non ci sono più messaggi o eventi da gestire. Il paradigma è semplice: a fronte di una richiesta di una particolare URL viene generata una pagina HTML. Oltre tutto prima si usava un solo linguaggio, ora si usano un linguaggio server side ed uno client side, più naturalmente ad XHTML e CSS.
    Prima si potevano usare decine di approcci diversi, oggi l’approccio è uno soltanto e si chiama HTTP.

    PHP non è più lento di Ruby o Python, sono i framework ad esserlo. PHP non si perde di connessioni, sono i framework scritti male che se le perdono. Questa mania dei framework è assurda, anche perché questi framework non sono per niente flessibili. Con WordPress o con eZ non si può fare tutto, si possono fare le cose così come sono state concepite dai progettisti. WordPress ad esempio per Programmazione.it non andrebbe bene, per Digg neppure e così via. Va bene per chi se lo fa andare bene, per chi vuole realizzare un sito in un certo modo e con certe caratteristiche.

    Nessuno usa le funzioni avanzate di PHP 5 perché non servono assolutamente a niente. Gran parte delle estensioni apportate al linguaggio sono inutili quando si programma sul Web. Potrebbero servire se si scrivessero applicazioni con GTK+, applicazioni standalone. Per questo non si usano. Non bisogna per forza usare tutto, bisogna usare quello che serve. E la maggior parte delle feature di PHP 5 non servono perché si usa un paradigma, quello request/response, tipico del protocollo stateless HTTP, che pone di fatto delle limitazioni e rende inutili utilizzare determinate caratteristiche, che prima, negli anni 90, erano non dico indispensabili, ma quantomeno utili.

    Poi fatemi capire. Quali sono queste cose sofisticate che non si possono fare utilizzando PHP 4? Con PHP 4 si può tranquillamente fare un sito come Flickr, Technorati, Digg. Ruby è una moda. Chi ha un po’ di esperienza sa bene che ogni ulteriore strato, oltre ad inserire bug, introduce delle limitazioni. Io sono assolutamente certo che con Ruby on Rails non si possa fare tutto, così come non si può fare tutto con eZ. Poi Ruby on Rails sarà 10 volte meglio di eZ, ma allora parliamo di framework non di linguaggi.

    PHP non è un linguaggio fortemente tipizzato, non c’è controllo statico dei tipi, dunque si fa molto prima a scrivere codice che in Java o Python. I suoi contenitori sono tutti generici, supporta la serializzazione degli oggetti. Nel 5 c’è una reflection API completa, che non userò probabilmente mai, ecc.
    Sembra che da quando ci sono le classi una persona non possa più scrivere funzioni, che da quando ci sono i framework sia per forza necessario usarne uno. Eppure chissà come mai TUTTE le librerie di PHP sono librerie di funzioni, ma non sono tali perché PHP è limitato, ma perché sono scritte in C.

    Questi sono gli anni dei maniaci. Non di quelli sessuali, ma quelli di wrapper e framework, quelli delle classi ad ogni costo. Quelli che usano MySQL da PHP attraverso gli oggetti non perché abbiano dei vantaggi ma perché "pensano" sia meglio così. Sono gli anni di universitari incompetenti nati con Java nella stessa, sono gli anni degli accademici che non hanno mai scritto un programma in vita loro.

  • Folletto Malefico
    11 agosto 2006 #

    "PHP non è più lento di Ruby o Python, sono i framework ad esserlo. PHP non si perde di connessioni, sono i framework scritti male che se le perdono."

    Può essere, non lo escludo, ma fino a prova contraria non riesco a crederlo: perché su tre framework proprio quello PHP perde pezzi? E seppure fosse un problema del framework, perché è così difficile sviluppare un framework decente in PHP mentre in Python o Ruby è questione di "istanti"? Queste domande costituiscono parte dei miei dubbi che mi fanno credere falsa la tua affermazione di cui sopra. Mi ripeto: non sto dicendo che *è* falsa, ma che per mia opinione non la credo vera perché non è dimostrata più della fallibilità di PHP (dimostrata) e per alcune argomentazioni logiche.

    Il punto, però è un altro. Ti posso dare ragione che i framework non risolvono tutto e di fatto è così: usare un framework perché "piace" è semplicemente stupido. Rails (e non Ruby, in un passaggio sembra che li confondi) può essere una moda, ma è un framework per CERTI scopi e che funziona per quegli scopi in modo eccellente.

    E così dovrebbe essere per ogni framework: migliore per qualcosa.

    Poi, Wordpress *non* è un framework e non lo sarà ancora per parecchio tempo, basta guardare il suo sorgente. Il mio CMS era meglio strutturato, fai tu (e di fatto era in parte un framework). Ma è anche vero che WP è una cosa piuttosto curiosa, perché dentro un template di WP ci puoi fare anche il caffé. Ovvero: un template di WP è oggettivamente un normale sito PHP che però *può* usare il backoffice di WP. Ho sviluppato dei siti in questo modo e ti assicuro che hanno il loro perché.

    Questo, semplicemente per sottolineare che è questione di scopi. E’ stupido dire Java è il meglio tanto quanto è stupido dire che Rails è il meglio. Ma, oggettivamente, per quanto mi riguarda nessuno (praticamente nessuno) si è ancora messo mai a pensare ad una cosa chiamata "usabilità del codice". Ovvero: Java è un linguaggio poco usabile. E questo indipendentemente dalle sue funzionalità.

  • Filippo Fadda
    13 agosto 2006 #

    Quello che posso dirti è che se PHP effettivamente avesse problemi di connessione me ne sarei accorto. Noi serviamo ben oltre un milione di pagine al mese ed il problema non si è mai presentato. Se poi i framework che ci sono in giro sono stati scritti male, allora tutto è possibile.