Visto che stanno fiorendo un po’ di post su Ruby, approfitto per dire la mia rispondendo qui al blog di Luca:
Caro Luca, Ruby è una strada molto perigliosa!
Dopo due anni d'uso posso dire che nasconde molte insidie. Specialmente in ambienti dove diversi plugin devono coesistere e devi solo sperare che gli altri siano stati abbastanza educati da non toglierti la sedia sotto il sedere...
Mi spiego: Essendo un linguaggio dinamico, è banale poter ridefinire i metodi di qualsiasi classe anche di base. In particolare, è possibile TOGLIERLI.
Io uso Ruby come linguaggio di programmazione per l'API di Google SketchUp dove praticamente chiunque può creare dei plugin in ruby. Il che significa che nelle macchine dove viene installato il tuo plugin possono manifestarsi problemi d'uso che non dipendono dal tuo ma da altri plugin "maleducati". In generale questo ti costringe ad una programmazione "estremamente" (ed a mio avviso eccesivamente) difensiva.
Ma vi sono casi in cui alcuni plugin (anche rinomati) fanno uso di librerie altrettanto rinomate (e mi riferisco in particolare ad una libreria molto usata che estende i metodi di datetime) che purtroppo sono bacate, in senso grave, in quanto rimuovono alcuni metodi senza verificare se tali metodi non siano stati eventualmente già rimossi (non ho parole) e visto che in tale caso Ruby genera un errore (e anche qui avrei da ridire, visto che se ti dico di togliere una cosa che non c'è, per lo stile di programmazione tipicamente lasco dei linguaggi dinamici, me lo dovresti tranquillamente ignorare) non c'è difesa.
E' come cucinare la pasta in due in modo indipendente (tu vai in cucina e metti l'acqua a bollire, poi arrivo io a buttare la pasta quando bolle, O VICEVERSA) :
Io posso pure controllare se c'è il sale prima di metterlo nella pentola e se vengo dopo di te va tutto bene. Ma se tu lo metti senza controllare, e vieni DOPO di me, sicuramente mangeremo una pasta molto SALATA...
Questo rischia di crearti un'infinità di problemi che paiono (al cliente) appartenere al tuo plugin...
Io ho risolto perché il cliente ha uno stretto controllo sul parco macchine utilizzate, ma prova a fare un plugin da vendere liberamente... sono cavoli amari. Ciò non significa che non si possano fare, ci sono molti plugin commerciali (ma molti di questi hanno due versioni, una per Mac e una per Win. E visto che esite un'API (obsoleta) per il c++, ho tanto l'idea che molti pezzi siano scritti in c++ ...
Cio non di meno, Ruby ha una sua eleganza e un suo fascino, e ci sono molte storie di successo sviluppate in Ruby On Rail. Ma francamente, se devo usare MVC, io preferisco l'implementazione Microsoft, Visual Studio e .NET è troppo comodo!
Con tutta sincerità, di Ruby ne ho piene le scatole.
Perché la libertà è bellissima e le sue potenzialità infinite, ma la potenza senza il controllo, è niente! (<cit.>). Quando sei libero di fare tutto e quel tutto può nuocere agli altri, nasce l’esigenza di un “corpus” (il più possibilmente piccolo) di regole condivise e di un sistema di controllo e applicazione di quelle regole. Cosicché si è forzatamente meno liberi, ma in cambio si può coesistere pacificamente. E per me questo vale anche nel campo dello sviluppo software.