Ruby: the love is really gone
Mar. 14th, 2008 11:09 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
topazAs a postscript to my previous complaint about Ruby, I received today a fantastic exploration of Ruby's closure and execution semantics, via ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
zsquirrelboy: http://innig.net/software/ruby/closures-in-ruby.rb. This covers some of the ground that I did but then goes much, much deeper. I have only covered about half of it and probably will not get any farther today. If you are a Ruby fan or any kind of a computer language nerd I strongly recommend that you take 30 or 40 minutes to read through it.
The upshot is: Ruby is even more fucked than I recognized. I'm an understanding guy, and would be willing to accept a lot of the language's foibles if they were well documented up front, but some of these conclusions are really damning. See section 3 in particular, especially if you think that "I thought I knew all there was to know about the 'return' statement" is a funny joke.
Ruby seems like a very interesting but ultimately unsuccessful experiment in functional language semantics, where some of the novel concepts just do not pan out. Blocks in particular are a failure: if they were just implemented as first-class closures it would solve a lot of problems, but that doesn't seem likely. A pity.
zsquirrelboy: http://innig.net/software/ruby/closures-in-ruby.rb. This covers some of the ground that I did but then goes much, much deeper. I have only covered about half of it and probably will not get any farther today. If you are a Ruby fan or any kind of a computer language nerd I strongly recommend that you take 30 or 40 minutes to read through it.The upshot is: Ruby is even more fucked than I recognized. I'm an understanding guy, and would be willing to accept a lot of the language's foibles if they were well documented up front, but some of these conclusions are really damning. See section 3 in particular, especially if you think that "I thought I knew all there was to know about the 'return' statement" is a funny joke.
Ruby seems like a very interesting but ultimately unsuccessful experiment in functional language semantics, where some of the novel concepts just do not pan out. Blocks in particular are a failure: if they were just implemented as first-class closures it would solve a lot of problems, but that doesn't seem likely. A pity.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2008-03-15 02:26 am (UTC)Are Ruby's blocks based more closely on parallel programming coroutines than on functional closures? Not that it's a parallel language, but in terms of philology maybe we can regard Ruby as [good scripting] + [good objects] + [barely passable functional] + [a hint of parallel] + [great reflection]. It's the combination of reflection and objects that has made Ruby prominent, and the somewhat garbled functional semantics were fortunately "good enough" for Rails.
As a point of comparison, Python is more of a [good scripting] + [I really hate Python objects] + [good functional]. (I haven't explored Python reflection.)
Or take something like OCaml, which I seem to recall is [great functional] + [great objects] + [nothing else].
I think we're still waiting for [scripting] + [objects] + [functional] + [multithreaded] + [reflection]. Not to mention [extensible] and [aspect oriented]. Groovy, F#, and Boo all have some new ideas to put on the table, but this is very much an ongoing conversation about finding the right compromises for different problem domains.