Per me uno degli aspetti più belli di Ruby è la "naturalezza" con cui permette di esprimere dei concetti: c'è tantissimo "syntactic sugar" che fa sì che un programma ruby ben scritto si legga quasi facilmente come un testo in inglese. Ci sono pochissime cose "inutili" da mettere in giro, e questa è una differenza con cui mi sto un po' scontrando nell'implementazione del mio framework.Originariamente inviato da CozzaAmara
Molto interessante la tua esperienza, lo dico da sviluppatore PHP che recentemente sta studiando Ruby-> RoR.
Posso chiederti quali grosse differenze hai notato da PHP a Rails, dove lo sviluppo ottiene dei grossi benefici, dove meno ecc?
Per esempio, in Rails posso tranquillamente fare
u = User.find_by_name_and_surname('Mario', 'Rossi')
mentre col mio framework posso al massimo puntare a un
$u = User::find_by_name_and_surname(array('Mario', 'Rossi'));
che al momento però non è ancora implementato, e si ottiene con un ancor più brutto
$u = User::find('first', array('conditions' => array('name = ? AND surname = ?', 'Mario', 'Rossi')));
Quello che io miro ad ottenere è appunto un framework che dia anche a PHP questo genere di immediatezza espressiva in cui leggo una riga di codice e capisco immediatamente cosa fa. Purtroppo in PHP c'è sempre di mezzo la parola chiave "array", mentre in Ruby basta un semplice paio di [].
Oltre a questo, sempre restando sul linguaggio "puro", Ruby ha da sempre un binding "sensato" dei nomi delle classi, mentre PHP lo avrà solo tra poco: al momento tutti i framework per PHP impongono una sintassi del tipo
$user = new User();
$u = $user->find(...);
che è concettualmente sbagliato perché $user non è un'istanza di User. Tra questo che è sbagliato e inventarti una classe UserPeer (come fa Propel) solo per aggirare i limiti del linguaggio, quando torni a PHP dopo un po' che programmi in Ruby, ti viene da sbattere la testa sul muro.
Queste sono considerazioni spicciole sul linguaggio puro e semplice, ma prendendo in considerazione tutto il framework, il discorso si fa ancora più ampio: in Rails c'è una solidissima impalcatura che risparmia tantissimo lavoro tedioso e passibile di errori in PHP semplice. I dati entrano sempre da un controller, interagiscono (praticamente) sempre con il model, escono sempre da una view. In questi tre passaggi le variabili hanno sempre gli stessi nomi (cosa che ho cercato di rispettare anch'io nel mio framework, ma anche qui mi sono trovato un po' limitato dal linguaggio), il flusso di controllo è sempre rigorosamente lo stesso. In più quando si arriva all'HTML, ci sono un sacco di funzioni per aiutare in un sacco di cose. Tra queste sono sicuramente apprezzabili la generazione dinamica degli URL e degli elementi dei form: il programmatore ragiona con gli oggetti astratti della sua applicazione, e su che URL "mapparli" lo decide il framework in base alle regole stabilite dal programmatore, pre-impostate su dei default così ragionevoli che raramente si sente il bisogno di cambiarli.
A me è successo di dover tornare a PHP dopo aver provato tutte queste comodità, e davanti alla tabula rasa m'è venuto un magone mica da ridere.Mesi fa, prima di iniziare il progetto vero e proprio che mi avevano assegnato, mi sono scritto una mia versione di ActiveRecord compatibile con PHP 5.2 giusto per avere una base da cui partire, ma soffriva delle limitazioni di cui parlavo sopra. Ora che invece non mi corre dietro nessuno, ho deciso di affrontare le cose come si deve e scendere a compromessi il meno possibile, di modo che quando uscirà PHP 5.3, il mio potrebbe essere il framework più simile a Rails... anche se essendo per ora da solo a svilupparlo, molto probabilmente finirò presto sopravanzato da qualche azienda, ma poco male: almeno mi sarò divertito e avrò imparato molto sia di Rails che di PHP.
Ad ogni modo, per questi prossimi giorni mi prendo un po' una pausa dal PHP, ma vi terrò informati su cosa combino.
Anzi Cozza, se ti interessa fare un giro col ThinFramework fammi sapere, ché piazzo un .tar.gz da qualche parte -- per ora ce n'è abbastanza per fare un piccolo blog come quello che c'è su www.thinserver.org (sito che gira sul mio PC a casa). Magari nelle prossime 24 ore metto "in produzione" il sistema di commenti che ho già scritto, così giusto per far vedere che funziona, anche se la cosa più interessante è vedere il codice, che è molto "railoso" pur essendo PHP.![]()


Mesi fa, prima di iniziare il progetto vero e proprio che mi avevano assegnato, mi sono scritto una mia versione di ActiveRecord compatibile con PHP 5.2 giusto per avere una base da cui partire, ma soffriva delle limitazioni di cui parlavo sopra. Ora che invece non mi corre dietro nessuno, ho deciso di affrontare le cose come si deve e scendere a compromessi il meno possibile, di modo che quando uscirà PHP 5.3, il mio potrebbe essere il framework più simile a Rails... anche se essendo per ora da solo a svilupparlo, molto probabilmente finirò presto sopravanzato da qualche azienda, ma poco male: almeno mi sarò divertito e avrò imparato molto sia di Rails che di PHP.
Rispondi quotando