Learning Ruby, and Ruby-vs-Lisp | Hacker News Reader

Learning Ruby, and Ruby-vs-Lisp

netzhansa.blogspot.com

54 pointsabdulhaq16 comments

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.

Having used both OO systems, I far prefer Lisp's with so much more flexibility.

But I agree that Ruby is a very good language.

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.

What do you mean by "the issues would have been transparent"?

Someone who was familiar with Ruby would have almost certainly overcome the issues I had without even thinking about it.

Ah...

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.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_... looks to be the current status of the ISO standard, found a draft version but its in japanese, severely limiting what I can glean from it.

http://www.wiki.ruby-standard.org/index.php?title=Main_Page&... looks to have been part of the standardization process but hasn't been updated for years.

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.

Sorry for the rambling, back to my cage.

Having programmed a lot in Common Lisp in the past these comparisons between Ruby and Lisp kind of puzzle me. The things that make Lisp Lispy (i.e. homoiconicity, hygienic macros, quoting ) aren't part of Ruby. From my standpoint Ruby looks like most dynamic language these days in that strongly encourages highly stateful programming with a sprinkling of metaprogramming.

Perhaps someone else has a different view?

This is just a guess, but someone who only knows C++, Java and/or C# who learns Ruby (or Python, Perl, JavaScript, etc) and Lisp will find the two languages closer to each other than to what they know. I think that's why comparisons are drawn between the two frequently. Note that people have made the same observations about Python and JavaScript (Peter Norvig writing about Python, Douglas Crockford writing about JavScript)

In my experience, people who haven't programmed much in any Lisp think that higher-order functions and map, filter, and reduce are the essential elements of Lisp rather than homoiconicity.

Yeah it appears that the use of higher-order functions seems to be equated with functional programming these days.

I've done Ruby for about 7 years and can tell you that after a while, things fall in place, including (most of) the syntax. For me, the most annoying thing is trying to create and pass around functions -- the syntax for that just isn't as easy as in CL or even Python. Having first class functions and a good function-passing syntax would be a nice addition to Ruby 2.0.

But yeah, marketability notwithstanding, I slightly favor Lisp.

"I've done Ruby for about 7 years and can tell you that after a while, things fall in place, including (most of) the syntax."

I would expect any adroit HN reader to be comfortable in a programming language after 7 years :) What is odd is that you say "most of the syntax". Would you please elaborate (aside from what you said about function creation/passing)? I like ruby, but I'm not to the point where the syntax falls into place as easily I wish it would.

As another data point, I had been doing Ruby for five years when I switched to Clojure. After a single year in Clojure, I knew the language much better than I had ever known Ruby and was able to read the source for the compiler itself and spot issues in it. Common Lisp is a lot more complicated than Clojure, but certainly simpler than Ruby.

Personally I had a hard time remembering the difference between Procs, blocks, and lambdas in Ruby, though I believe this is partly due to the fact that the differences shifted in minor point releases.

The things that I still don't like about Ruby's syntax & semantics (even though it's my second favorite language):

  - No keyword arguments
  - No good syntax for creating pure functions
  - Metaprogramming seems tacked on
  - HERE doc manipulation is atrocious
  - There is no 'fundamental unit' of a Hash
    (other than a destructured key-value pair),
    so mapping a function onto hash keys or values
    is always a call to #reduce or a Hash[array]
  - Creating a Hash with #reduce is not pretty
  - Destructuring isn't so sophisticated
  - Local variables become defined even if they aren't in your
    current code path
  - I already mentioned method passing

These are all things, by the way, that Clojure does much, much better.

For anyone trying to learn Ruby I highly recommend you get a copy of Eloquent Ruby.

I wish I had learned it with this book by my side. I consider it one of the best introductions into the language and how to write idiomatic Ruby.

Reply on news.ycombinator.com