10 aree di Ruby migliorabili
Lunedì 8 Ottobre 2007 - 08:25
di Simone Carletti
Ogni linguaggio ha i suoi pro ed i suoi contro. L’importante, dal mio punto di vista, è avere una conoscenza e una preparazione che permettano ad un programmatore / project manager di scegliere il linguaggio migliore più adeguato in base agli obiettivi da raggiungere.
Dopo aver analizzato alcuni motivi per imparare Ruby, rivolto la frittata e vi mostro alcuni difetti (o almeno aspetti per i quali questo linguaggio non ha ancora fornito una soluzione valida).
Come al solito, prendeteli come indicazione di massima. Onestamente presumo che quanto scritto sia più utile ad un programmatore che già sviluppa in Ruby piuttosto che ad uno che voglia avvicinarsi a questo linguaggio.
Tra le 10 Areas Where Rails Fails mi sento di convididere in particolare il punto 4, quello relativo alla mancanza di IDE avanzati.
Le soluzioni attuali non offrono ancora livelli adeguati e quasi tutti sono plugin piuttosto che IDE autonomi. Ma non voglio anticipare troppo, l’argomento sarà oggetto di un post per una futura rubrica su Edit in fase di preparazione!
Passando ad altro, una delle limitazioni maggiori incontrate fino ad oggi riguarda il punto 10, ovvero la documentazione. La documentazione di Ruby è abbastanza disorganizzata, senza contare che il sistema integrato mi pare una brutta copia (ma proprio brutta) di Javadoc.
Sarà forse che sono troppo esigente, sarà che spesso scrivo più commenti che codice essendo abituato a lavorare su progetti in team e/o open source, tuttavia perché volere a tutti i costi distinguersi? Javadoc è un sistema eccellente: che motivo c’è nella scelta di non volerlo replicare? Insomma, se una cosa funziona (e bene) perché inventarsene un’altra (a meno che non funzioni meglio, ma non è questo il caso).
Tanto per intenderci, l’attuale rdoc non è neanche in grado di generare per una classe una documentazione che tenga in considerazione metodi, attributi ed elementi ereditati da eventuali superclassi!
Ma sono l’unico a lamentare questa mancanza? Quanto sono importanti per voi i commenti? Vi viene in mente qualche altro punto?
Commenti
1
Perchè dici che mancano IDE avanzati? Mi sembra che quello della CODE GEAR sia abbastanza buono…
# - postato da Davide Bisconti - 08 Ottobre 2007 - 11:12
2
Ciao Davide, parli di http://www.codegear.com/produc.....s/3rdrail/ ?
Non lo conoscevo, ma mi sembra orientato più a Rails (framework) che al linguaggio (Ruby). E’ corretto?# - postato da Simone Carletti - 08 Ottobre 2007 - 11:39
3
beh per produrre documentazione il modo c’è, non conosco gli altri linguaggi, comunque si è vero forse c’è poca documentazione, però è anche poco (relativamente) che la gente inizia ad usarlo. Comunque si fa bene a segnalare le lacune, anche se onestamente non capisco quelle di rails, in quanto rails è un framework, ma volendo si può estendere o crearne uno nuovo
# - postato da Dibi Store - 08 Ottobre 2007 - 11:52
4
Stiamo parlando ancora del linguaggio in quanto tale (come nel precedente post), degli strumenti che sono a disposizione per programamre in Ruby, oppure di RoR come da argomento trattato nei contenuti a cui punta il link?
Due problemi di Ruby (non legati tanto al linguaggio e alla sua semantica quanto all’”ecosistema” Ruby):
- la mancanza di un set di specifiche ufficiale per il linguaggio, attualmente l’MRI (l’interprete di Matz) è usato come “specifica”, ma ovviamente è una situazione per nulla ideale. Ad oggi questa necessità è maggiore e a mio avviso più sentita visto il proliferare di nuove implementazioni (JRuby, IronRuby, Rubinius, Cardinal, etc)
- relativa lentezza dell’interprete (in attesa di Ruby 2.0)Per quanto riguarda RDoc in effetti non credo che sia ancora del tutto ottimale come strumento, anche se personalmente non trovo la documentazione di Ruby eccessivamente disorganizzata (trovo un po’ scomodo invece l’output standard di RDoc, questo sì), ma così su due piedi non sono nemmeno del tutto convinto che JavaDoc possa calzare addosso a Ruby. Non so, in effetti non ho mai pensato a questo aspetto. Detto questo, penso comunque che i commenti nel codice siano importanti ma penso anche che troppi commenti possano sortire l’effetto opposto a quello desiderato. Di sicuro non bisogna usare i commenti come scusa per permettersi di scrivere codice in maniera astrusa perché “tanto sta scritto altrove come funziona” :)
5
Sono fin troppo verboso nel commentare il codice e una delle cose che mi ha sempre rallentato nell’imparare un nuovo linguaggio è la difficoltà di consultazione della documentazione. La situazione tipica è, ora che ho compreso la sintassi e la filosofia di utilizzo e che a grandi linee qualche libro mi ha presentato un po’ di esempi generici e qualche statement: come diavolo lo apro ’sto file? Mi manca sempre la funzione “search” presente nella documentazione in alto a DX di PHP.net (la amo) e che tante volte ho dovuto e devo utilizzare. E preciso che la maggior parte delle volte, mi sono stati più utili i commenti degli utenti nel manuale sopra citato che il manuale stesso.
# - postato da Yuri - 11 Ottobre 2007 - 09:45