Ruby is...
Nov. 10th, 2006 10:51 pmSo, I've been wrapping my head around Ruby and Rails this week in my copious spare time (by the way, I hit by wordcount deadline for today, passing the halfway mark at 25860, yes! And the month's only a third over!) and listening to some simply incredible classical music (see the music tag) when I came to some annoying realizations about Ruby.
Ruby is Lisp. There's no other way to describe it. Ruby is Lisp the way Javascript is Lisp: both are descendents of the Lisp Way, but both have worked very hard to obscure that fact and look as if they had much in common with Algol's descendents, such as C and Pascal.
Ruby is Perl and Python. It's a scripting language as powerful as either of these, with a little of each's philosophy thrown in: from Python, ruby stole a sense of clarity with which it has not yet made peace, and from Perl, it stole the idea that there was any number of ways to do something and, oh yeah, Perl had some great ideas about what should be available by default.
Most frightening of all, Ruby is C++. Every major Ruby project creates a domain language unique to that project. Invoking the keywords of that domain language may result in great cascades of code that have little to no resemblence to "the core Ruby way of doing things," and whole chunks of your system may invoke excessively clever environmentally dependent templatizing routines that, without sufficient documentation, may deliver whole metaclass subsystems with execution trees that were never meant to be held inside the human head. Ruby's philosophy is that the domain language should be appropriate to the domain. Rails does an excellent job of living up to this expectation, but other projects I've seen do not.
I like Ruby, but that last is a major pitfall. Ruby experts love to show off their inner knowledge, often confusing the heck out of those of us new to the language, and the last aspect of the language makes it easy for said experts to mangle the brains of beginners. The Ruby community is currently going through an infatuation phase with itself, and helping new folks (like me) is going to take a while.
Ruby is Lisp. There's no other way to describe it. Ruby is Lisp the way Javascript is Lisp: both are descendents of the Lisp Way, but both have worked very hard to obscure that fact and look as if they had much in common with Algol's descendents, such as C and Pascal.
Ruby is Perl and Python. It's a scripting language as powerful as either of these, with a little of each's philosophy thrown in: from Python, ruby stole a sense of clarity with which it has not yet made peace, and from Perl, it stole the idea that there was any number of ways to do something and, oh yeah, Perl had some great ideas about what should be available by default.
Most frightening of all, Ruby is C++. Every major Ruby project creates a domain language unique to that project. Invoking the keywords of that domain language may result in great cascades of code that have little to no resemblence to "the core Ruby way of doing things," and whole chunks of your system may invoke excessively clever environmentally dependent templatizing routines that, without sufficient documentation, may deliver whole metaclass subsystems with execution trees that were never meant to be held inside the human head. Ruby's philosophy is that the domain language should be appropriate to the domain. Rails does an excellent job of living up to this expectation, but other projects I've seen do not.
I like Ruby, but that last is a major pitfall. Ruby experts love to show off their inner knowledge, often confusing the heck out of those of us new to the language, and the last aspect of the language makes it easy for said experts to mangle the brains of beginners. The Ruby community is currently going through an infatuation phase with itself, and helping new folks (like me) is going to take a while.
You missed the most (?) important one
Date: 2006-11-11 10:37 am (UTC)I would argue that much of the clarity you ascribe to Python, actually comes from the Smalltalk side of the house.
As to the current plethora of not-so-good domain specific languages, I think that is just an artifact of the early stage that Ruby developers are at. Good style for developing a DSL takes a while to shake out via trial and error. At least that was the case with Smalltalk and Lisp. Also, the slow Ruby runtime forces you to write code templating code to get performance, the need for this goes away as performance improves.
Another of Ruby's lacks that makes it harder to work with is that there is currently no proper IDE or in-image development tools. There are projects to build such, but nothing is really ready yet. DSL's really work best when you have a live object system and can examine generated code in context, like in the Smalltalk and Lisp runtimes (or, for that matter, EMACS and Elisp).
Re: You missed the most (?) important one
Date: 2006-11-11 06:40 pm (UTC)I used to hear that one of the goals of Python was to be "so obvious that an IDE would only get in the way," and my experience with doing Python projects in both Emacs and Eclipse leads me to believe that Guido may have gotten what he wanted. I can't help but wonder if Ruby could learn from that.
Re: You missed the most (?) important one
Date: 2006-11-11 08:16 pm (UTC)I also think that the idea of it being "so obvious that an IDE would only get in the way," is another blind spot. If you have used any of the totally integrated language environments (an Image based Smalltalk, Lisp Machines, etc.) you will find that the always live object environment with the totally integrated tools, though unfamiliar at first, rapidly become very comfortable and you start wondering how you lived without them. This has little to do with the language design.
James Robertson, the product manager for Cincom's VisualWorks Smalltalk, has a blog (http://www.cincomsmalltalk.com/blog/blogView) where he pushes Smalltalk and has screencasts (http://www.cincomsmalltalk.com/blog/blogView?searchCategory=screencast) (57 so far) showing various Smalltalk features. A good place to start is with the Sept 18, 2006 screencast whew he starts a daily "I've downloaded VW non-commercial and installed it...what now?" series.