But then, Ruby is an interpreted language and this fact is re-stated throughout the book. With Just In Time compilation, this could become a non-problem, but I'm not sure how well Ruby can be optimized due to its very dynamic nature.
Ruby 1.8 is interpreted, in the classic sense. Ruby 1.9, the current production version, 'compiles' to bytecode internally. TRPL was written when 1.8 was still the production version of Ruby (although it does cover most, but not all, of 1.9's syntax). Also, JRuby's JIT works well and typically yields better-than-MRI performance after a short running time.
The lack of a formal specification and the ugly grammar put me off.
It's not entirely complete yet but a formal specification, targeted for ISO, is on the way - there's a 300€ PDF floating around somewhere ;-) Due to the length of the process, it focuses on Ruby 1.8 for now, I believe. More interesting, however, is the http://rubyspec.org/ project, but the MRI core team's engagement with it isn't strong from what I've heard.
And while Ruby certainly has its warts, calling the language "ugly" is like calling a Mercedes ugly when parked next to a Ferrari ;-) Lisp's syntactic simplicity is certainly beautiful but compared to mainstream languages, Ruby fares well.
I can see the appeal of Ruby, but there seems little it has to offer to me that Common Lisp cannot provide.
Certainly. That's a good thing. If you can be more productive with Common Lisp, its ecosystem suits you, and you're not a huge OO nut (which I'm inferring), there's nothing particularly compelling about Ruby. For certain folks though, including me, Ruby has significant advantages in many areas.
I was working on being better with Lisp and learning Ruby at the same time I was working on some of my thesis code. I initially was going to do it in Ruby but found the variants of syntax offputting - I needed to get functionality down, not remember the exact !@# symbol or syntactic construct. Binary bindings proved to be difficult, since there was a 1.8/1.9 split going on; I had to do some jury-rigging with my Mac.
I got tired of the duct-taping and syntax, then rewrote it in Lisp. Almost no problems comparatively. I'm wholly certain if I was a Rubyist coming in, the issues would have been transparent.
The post reminded that Ruby is interesting language having many merits.
But your about "rubyspec" reminded that ZS is correct that Ruby is also chock-full of BS artists. Rubyspec is a test suite - Lol. Whatever the merits of test suites, they aren't formal specifications, they shouldn't pretend to be test specifications and the people who pretend they are such are, uh ... BSing.
"Test Driven Development", meaning writing your tests as some kind of specification, is total crap. Tests aren't abstractions that get you anywhere. They are just tests and writing tests first only in systems so simple they probably don't need much testing or design anyway...
Also, Ruby expressions may not be ugly but "Ruby Syntax", as a BNF expression is super-ugly even compared to other mainstream languages.
rubyspec isn't intended to be a specification per-se, its more meant to be able to test against mri behavior for other ruby implementations. Which isn't much help since the mri maintainers seem to ignore it. Until there is a proper actual spec, rubyspec is about the most complete "here's kinda how mri works, we think" without digging through the c source. Which is at times, maddeningly annoying with comments that are wrong etc... I'd say hop in #jruby or #rubinius on freenode and you'll quickly learn how annoying conforming to mri ruby behavior can be.
My biggest gripe with ruby is that unlike most other languages its development is rather opaque unlike say python. I think this has to do with the primary group being Japanese.
But yeah TDD is pretty heavily promoted, but primarily from the rails side of rubyists. I've used ruby for 10 years, only just now made a gem with tests in it, mainly to see what all the rage is about. Is it nice? For some things yeah, but not entirely necessary, I agree with Rich Hickey, only throw up guard rails where accidents will occur. Don't hit them all the way to the store.
Ruby 1.8 is interpreted, in the classic sense. Ruby 1.9, the current production version, 'compiles' to bytecode internally. TRPL was written when 1.8 was still the production version of Ruby (although it does cover most, but not all, of 1.9's syntax). Also, JRuby's JIT works well and typically yields better-than-MRI performance after a short running time.
The lack of a formal specification and the ugly grammar put me off.
It's not entirely complete yet but a formal specification, targeted for ISO, is on the way - there's a 300€ PDF floating around somewhere ;-) Due to the length of the process, it focuses on Ruby 1.8 for now, I believe. More interesting, however, is the http://rubyspec.org/ project, but the MRI core team's engagement with it isn't strong from what I've heard.
And while Ruby certainly has its warts, calling the language "ugly" is like calling a Mercedes ugly when parked next to a Ferrari ;-) Lisp's syntactic simplicity is certainly beautiful but compared to mainstream languages, Ruby fares well.
I can see the appeal of Ruby, but there seems little it has to offer to me that Common Lisp cannot provide.
Certainly. That's a good thing. If you can be more productive with Common Lisp, its ecosystem suits you, and you're not a huge OO nut (which I'm inferring), there's nothing particularly compelling about Ruby. For certain folks though, including me, Ruby has significant advantages in many areas.