The Ruby Programming Language

bdelacey writes "In January 2008, just in time for Ruby's 15th birthday, O'Reilly published The Ruby Programming Language. The co-authors make a strong writing team. Yukihiro (Matz) Matsumoto created Ruby. David Flanagan previously wrote Java In a Nutshell and JavaScript: The Definitive Guide — he has a CS degree from MIT with a concentration in writing. Drawings are the work of Rubyist-extraordinaire why the lucky stiff and technical reviewers include well known Rubyists David A. Black, Charles Oliver Nutter, and Shyouhei Urabe." Read on for the rest of Brian's review. The Ruby Programming Language author David Flanagan & Yukihiro Matsumoto with drawings by why the lucky stiff pages 444 publisher O'Reilly rating 9/10 reviewer Brian DeLacey ISBN 0-596-51617-7 summary A classic and comprehensive guide to Ruby. According to the Preface, Flanagan and Matz modeled this book after the K&R "white book" — The C Programming Language by Brian Kernighan and Dennis Ritchie. Like the "white book", The Ruby Programming Language has a simple structure and provides complete coverage. Just as K&R served as the de facto standard for "C", The Ruby Programming Language will likely be seen as the most authoritative language book for Ruby. Flanagan and Matz provide the following guidance for their readers:

"Because this book documents Ruby comprehensively, it is not a simple book (though we hope that you find it easy to read and understand). It is intended for experienced programmers who want to master Ruby and are willing to read carefully and thoughtfully to achieve that goal. ... [T]his book takes a bottom-up approach to Ruby: it starts with the simplest elements of Ruby's grammar and moves on to document successively higher-level syntactic structures from tokens to values to expressions and control structures to methods and classes. This is a classic approach to documenting programming languages." (p. 17)

You'll read all about boolean flip-flops, duck typing, lambdas, maps, metaprogramming, reflection and patterns of rhyming methods (collect, select, reject, and inject!). You'll also learn about new features in Ruby 1.9, like fundamental changes to text for Unicode support and the introduction of fibers fo coroutines. If it's in Ruby, it's almost certainly in this book. Chapters flow together nicely, although some could even stand on their own as educational materials for a computer science course (e.g. Chapter 7: Classes and Modules covers object-oriented programming and Chapter 8: Reflection and Metaprogramming elaborates on concepts like hooks, tracing, and thread safety).

In Ruby programming, difficult tasks are typically not only possible but often easy. It seems the authors take the same approach in their writing. For example, the complex topic of Domain Specific Languages (DSLs) sometimes creeps into deep discussions involving Ruby. Flanagan and Matz describe it simply and clearly: "A DSL is just an extension of Ruby's syntax (with methods that look like keywords) or API that allows you to solve a problem or represent data more naturally than you could otherwise." (p. 296)

During Ruby's first ten years, nearly two dozen books were in print in Japan but very few were available in English. That changed in 2004 when the introduction of Ruby on Rails created momentum for the language. A flood of new books followed, including Programming Ruby (2004, 2nd edition), The Ruby Way (2006, 2nd edition), Ruby for Rails (2006), and Learning Ruby (2007).

Programming Ruby, with lead author Dave Thomas, is self-described as a "tutorial and reference for the Ruby programming language." The Ruby Way, by Hal Fulton, was intended to complement Programming Ruby. Fulton noted: "There is relatively little in the way of introductory or tutorial information." Ruby for Rails, by David A. Black, has a clearly defined audience: "This book is an introduction to the Ruby programming language, purpose-written for people whose main reason for wanting to know Ruby is that they're working with, or are interested in working with, the Ruby on Rails framework." Learning Ruby, by Michael Fitzgerald, is a 238-page survey for "experienced programmers who want to learn Ruby, and new programmers who want to learn to program."

Programming Ruby and The Ruby Way each weigh in at over 800 pages. The binding on my copy of The Ruby Way came unglued and split in the middle after a year of use. The Ruby Programming Language is a slim, more manageable 444 pages and, in contrast, is the only one to cover Ruby version 1.9. In general, this is a great example of "less is more". Informative text boxes are sprinkled across the book with brief highlights on key technical thoughts. The first chapter's text box on "Other Ruby Implementations" (e.g. JRuby, IronRuby, Rubinius) could, however, be expanded into a several-page discussion of Ruby's various interesting architectures. Inclusion of IDEs and development tools (e.g. Eclipse, NetBeans, and TextMate) might also be helpful. These topics would nicely round out Chapter 10: The Ruby Environment.

The Ruby Programming Language has excellent cross-referencing. Section signs () feel like embedded HTML links that enable you to easily follow your coding curiosity around the book. Or you can just read it the old fashioned way, straight through. As an example, Chapter 3: Datatypes and Objects has subheadings (e.g. 3.1 Numbers) and well defined sections (e.g. 3.1.3 Arithmetic in Ruby.) The page-footers, table of contents and index also provide efficient navigational aids.

Artwork at the "edge of abstract expressionism" is something you might expect from The New Yorker magazine, but a computer book? The Ruby Programming Language introduces readers to "the edge of graphite expressionism". Original "smudgy residue" pencil drawings by why the lucky stiff creatively start each chapter.The Beatles' album cover for Sgt. Pepper's Lonely Hearts Club Band sparked intrigue and investigations into coded messages with hidden meanings. The same could happen here.

In Words and Rules: The Ingredients of Language, author Steven Pinker asks a simple question: "How does language work?" When I think about a new programming language, I have the same type of question in mind: "How does this language work?" Flanagan and Matz provide the answers in outstanding fashion. The Ruby Programming Language should help seasoned programmers who want to master Ruby. In addition, there is enough structure and sample code for determined novices to begin their programming explorations. Better than any other, this book defines the language. It is a classic and comprehensive guide for Ruby and a great 15th birthday present.

One long-time Rails developer sent me an email with their first impressions of The Ruby Programming Language: "I have been finding the book very useful, and I'm glad I did get it sooner rather than later." Matz said "Ruby is designed to make programmers happy." It looks like similar design thinking went into this book.

Brian DeLacey volunteers for the Boston Ruby Group

You can purchase The Ruby Programming Language from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

frist psot

[Anonymous Coward]

finally.

Re:frist psot

[jdinkel]

Ah too bad you posted as AC, now you'll never get the street cred.

Let's face it:

[teknopurge]

Ruby doesn't scale. Discuss.

What, it's good for RAD you say? Use something like http://wavemaker.net/ and get RAD with Java.

Ruby: Memory issues, less scalable than Java. Lame.

Regards,

Re:Let's face it:

[teknopurge]

Ack! Post preview Nazi's will get me! Try http://wavemaker.com/ instead!

Re:Let's face it:

[Fast Thick Pants]

Use something like http://wavemaker.net/ and get RAD with Java.

Sounds tempting, but all they're offering is ringtones, carpets, and scuba equipment. Try wavemaker.com.

Re:Let's face it:

[fr4nk]

Nazi's
No, but Grammar Nazis will.

Re:Let's face it:

[DragonWriter]

Ruby doesn't scale. Discuss.

Ruby isn't lightning fast, but its fast enough for lots of things, and its easy enough to interface with C (if you're using the main implementation) or Java (if you are using JRuby) if you need to refactor identified bottlenecks in a lower-level, higher-speed language.

As to scalability, I don't know of any particular problems with Ruby there. Green threads pre-1.9 and a Python-style GIL in 1.9 limit the ability to benefit from SMP architecture in one process on the one side, but the standard library comes with some fairly useful distribution tools. Is not, say, Erlang or Oz, but then neither is Java.

What, it's good for RAD you say? Use something like http://wavemaker.net/ and get RAD with Java.

WaveMaker seems to offer a Web application framework and a visual builder for web apps that is tightly tied to that framework. This might be a viable Java alternative to Rails for some web applications, but its certainly not a general alternative to Ruby. And its suggests that your scalability complaint is probably similarly a misplaced reference to the various complaints (the main and most frequently cited one of which was retracted by the people making it) about the scalability of Rails, for which there are many alternatives even within the Ruby universe (Waves, Camping, Nitro, Sinatra, Wuby, etc.)

Re:Let's face it:

[tcopeland]

> As to scalability, I don't know of any particular problems with Ruby there.

Yup. It's strange - folks will post comments like "Ruby can't scale for a huge enterprise app!". The odd thing there is that for a huge enterprise app the opcode execution speed is probably not going to be the primary bottleneck. In fact, almost anything that reaches over a socket into a database is going to have bottlenecks that have nothing to do with how fast the Ruby interpreter can navigate an AST or set up a stack frame.

Re:Let's face it:

[SanityInAnarchy]

Rails scales, it doesn't perform. As a language, it's impossible for Ruby to scale or not scale -- that is up to the app, unless you were going to suggest Erlang.

The difference between scalability and performance is important, and dirt-simple. And it will help you no matter what your platform is.

Re:Let's face it:

[Fear the Clam]

get RAD with Java.

These kids. In my day we used to get funky with Fortran and we liked it.

Re:Let's face it:

[Anonymous Coward]

The difference between scalability and performance is important, and dirt-simple.

If the difference is so important and so simple, why didn't you say what the difference is?

Re:Let's face it:

[darthflo]

It usually boils down to scalability referring to the amount of memory used and performance meaning the time taken. Or, to explain it Ted Stevens Style: The computer's not a big truck you just dump something on, it's a tube of a given length and diameter. Applications are cylinders. Performant apps are flat cylinders, scalable apps are thin cylinders. A long cylinder with a big diameter will require the tube's full capacity for a long time; during which lots of big-diametered cylinders could pass thru sequentially or lots of thin, long cylinders in parallel.

Re:Let's face it:

[SanityInAnarchy]

It was more an invitation to RTFM, but I just realized that Google isn't helping much, and I can't find the original articles. So here's the short version:

Performance is how fast an app runs for a given amount of hardware. This is usually measured in how fast it is with respect to a single core of a single CPU.

Scalability is how well the app behaves when you just throw more hardware at it. That is, if you give it another ten CPUs and five gigs of RAM, will it be able to take advantage of that?

Ruby performance sucks. It is impossibly slow, even compared to languages like Perl or Python. I make no excuses for that. Look at the performance improvements of rails 1.9, and you'll get an idea of just how bad 1.8 is.

But Rails scales very well -- in the simplest example, the default configuration for Rails nowdays is a mongrel cluster, even on a single machine. It's a really strange and perverse design where you put a load-balancing proxy in front of at least three Rails/Mongrel webservers, each listening on a different local port. And unless you've done something stupid, this will Just Work, right out of the box.

But as long as your database server can handle it, you can just throw another server behind that load balancer. A lot of work has gone into making load balancers and database servers scalable, and you can take advantage of that, if you really need to. (For awhile, Ruby is still going to be the bottleneck.)

What this means is that I probably would not write a performance-critical desktop app (like, say, a game) in Ruby. But for web apps, it makes sense. If you can write the same app twice as fast, with half the people, you can afford to throw four times the server resources at it -- and as a bonus, you got it up in half the time as your competitor, who thought scalability == performance.

Re:Let's face it:

[DragonWriter]

Ruby performance sucks. It is impossibly slow, even compared to languages like Perl or Python. I make no excuses for that. Look at the performance improvements of rails 1.9, and you'll get an idea of just how bad 1.8 is.

Clearly, you mean Ruby 1.9 vs. Ruby 1.8. Rails went from 1.2 to 2.0. Ruby went from 1.8 to 1.9, and in that step also switched to a bytecode compiler/VM (YARV) for a big performance improvement.

Re:Let's face it:

[ezzzD55J]

Also, if the slowdown is a constant factor, as slow execution of interpreted languages or RTS-heavy languages are on average, then that has zero impact on scalability.

Re:Let's face it:

[thermagen]

The scalability rap falls on Rails, not Ruby. Rails effectively requires one image per concurrent client. The Rails variant Merb is designed for concurrency and scales much better.

Re:Let's face it:

[SanityInAnarchy]

You're right, I did mean Ruby 1.9 vs Ruby 1.8. Sorry about that.

Re:Let's face it:

[tcopeland]

> Rails effectively requires one image per concurrent client.

Hm, well, one concurrent HTTP client, yes. But if a Rails process can serve up 30-40 requests a second and a human using a web browser is only doing a request every 2-3 seconds, and you've got a cluster of 10 Rails processes... it seems to work out ok.

Re:Let's face it:

[FooBarWidget]

That's why you're supposed to use multiple Rails processes. Multiprocessing is functionally no different from multithreading, except for the fact that processes don't share memory with each other, so if 1 Rails instance crashes the others are still alive.

FYI, an Apache worker process can also handle 1 request at the same time. And Apache solves that by... spawning multiple Apache worker processes!

Re:Let's face it:

[oliderid]

Yup. It's strange - folks will post comments like "Ruby can't scale for a huge enterprise app!".

I'm not a Ruby fanboy but I agree that this argument is quite poor. A lot of entreprise apps don't need to be scaled. I mean we all need easy to code little apps that you run once a week, or a "glue" language for a specific non mission critical task. Most of the time you end up with things like Perl or Bash.

My main concern about Ruby is that very few developers know it. And you still don't know if this trendy language (whatever its features are) will still be around in ten years.

Re:Let's face it:

[Furry Ice]

Ruby isn't going to just disappear any time soon. It started in 1995, so given that it's already been around for over ten years, I don't think it will disappear in the next ten. I can't guarantee that usage will continue to climb, but it seems likely. It's the most pleasant language I've ever coded in!

Re:Let's face it:

[Anonymous Coward]

FYI, an Apache worker process can also handle 1 request at the same time. And Apache solves that by... spawning multiple Apache worker processes!

Haven't exactly kept up, have we?

BTW, apache in prefork mode scales like crap. The apache devs will tell you that much.

Re:Let's face it:

[darrinallen]

I have a couple RUBY books at home. These will be great additions to my LIBRARY

Re:Let's face it:

[Stamen]

No, not really.

Performance is how fast a program can accomplish a task on a given piece of hardware. If a C program can perform some task 10x faster than Ruby can do on the same hardware then the C program has much higher performance. How that performance is achieved, wether through better memory usage, faster calculations, or a better algorithm doesn't matter. It is simply the amount of work you can perform in a duration of time.

Scalability is simply that when apply more resources the output increases proportionally. If something is perfectly scalable and you increase the resources by 10, then output will increase by 10. Rarely is anything perfectly scalable as there is overhead for adding resources (communication between the resources, etc).

This is all that scalability means, and in most large applications it is much more important than performance. If I have an application that outputs a certain amount of work in a certain time, and this application will have growth, I want to be able to achieve increased output simply by adding new resources (new servers usually, but could be faster CPUs or more memory). I'd rather have an app that performs 50% slower than another app, if it had very good scalability, rather than a high performant app that couldn't' scale well (first server gets 100% output, second server only adds another 60% output, third server only adds another 30% output, etc).

Re:Let's face it:

[DragonWriter]

The Rails variant Merb is designed for concurrency and scales much better.

Merb, AFAIK, isn't a "Rails variant", just one of the (many) other Ruby web frameworks, designed from pretty much the opposite philosophy of Rails: where Rails is opinionated software that bundles lots of components and is premised around the expectation that you'll use the bundled components, though you can beat on Rails to replace those with alternatives (some more easily than others), Merb advertises itself as "ORM-agnostic, JavaScript library agnostic, and template language agnostic".

Re:Let's face it:

[thermagen]

This is an accurate description of the philosophical difference between Merb and Rails. "Variant" is used loosely here. A Rails practitioner would immediately recognize Merb's debt to Rails. Perhaps "Rails alternative" would be more accurate.

Re:Let's face it:

[danyprundus]

Things has changed... now is web 2.0 rich applications... a way new world

Why can't this book be free?

[hackingbear]

Why do computer software worth less than paper-printed books? Last I check, software codes do not destroy rain forest like books.

Re:Why can't this book be free?

[Anonymous Coward]

There is a free online version of this book. It's called Google "ruby index_word_of_topic_your_looking_for".

Re:Why can't this book be free?

[swimmar132]

It can't be free because the author wants to get paid for his work on it.

Re:Why can't this book be free?

[Anonymous Coward]

Why do computer software worth less than paper-printed books? Last I check, software codes do not destroy rain forest like books. Last I checked, using proper verb tense doesn't destroy rain forests either...

Re:Why can't this book be free?

[bladesjester]

It can't be free because the author wants to get paid for his work on it.

But they can make their money selling documenta.... oh wait.

(sorry. I *had* to heh)

Re:Why can't this book be free?

[Anonymous Coward]

Books don't either.

Re:Why can't this book be free?

[initdeep]

it can be "free" if you have no or very low morals.....

torrents, the new shoplifting.....

Re:Why can't this book be free?

[bladesjester]

I really prefer paper, but I have to admit that I do try to find electronic copies of my books so I can take them with me if I'm on the road. It's sort of a pain to take a bookshelf full of paper books with you all over the place.

I wish more authors would just include a CD with the book that has an electronic copy of the book on it so I didn't have to hunt all over the place for them.

Re:Why can't this book be free?

[chromatic]

Why do computer software worth less than paper-printed books?

It's somewhat easier--and consequently cheaper--to make a bit-perfect duplicate of a piece of software than a physical book.

Re:Why can't this book be free?

[Dutch Gun]

I wish more authors would just include a CD with the book that has an electronic copy of the book on it so I didn't have to hunt all over the place for them. This really isn't up to the authors. It's up to the publisher. Take a peek at who's name is in the copyright notice.

Re:Why can't this book be free?

[Anonymous Coward]

why you write like china man?

Re:Why can't this book be free?

[Unoti]

Why do computer software worth less than paper-printed books? Last I check, software codes do not destroy rain forest like books.

Every computer language I've ever learned since BASIC I learned initially by reading in the bathroom, or while taking a break outside at work. Paper has always had the upper hand there over electronic, and will continue to have the upper hand there for a few more years.

Re:Why can't this book be free?

[MillionthMonkey]

Every computer language I've ever learned since BASIC I learned initially by reading in the bathroom

So which language wastes more water, Ruby or Java?

Re:Why can't this book be free?

[Breakfast Pants]

Take a look at both names on the contract.

Re:Why can't this book be free?

[nuzak]

Books aren't exactly printed on rainforest hardwood either. Primarily it's cattle ranching that destroys rain forests.

Re:Why can't this book be free?

[emag]

Every computer language I've ever learned since BASIC I learned initially by reading in the bathroom... Brings new (old?) meaning to the term "shit code"...

Re:Why can't this book be free?

[Anonymous Coward]

The book exists in electronic format as well.

The ruby programming language

[Anonymous Coward]

Is very much like smalltalk. The remainder of this book has been intentionally left blank.

Huh? Is this the "new" English?

[smooth wombat]

Drawings are the work of Rubyist-extraordinaire why the lucky stiff and technical reviewers include well known Rubyists David A. Black, Charles Oliver Nutter, and Shyouhei Urabe.

Error parsing sentence. Unable to comprehend.

Is this like the use of the word "your" instead of the correct "you're" as seen in more and more sentences, including a graphic on MSNBC.

Sorry, I'll stick to the old three score and twain. That's 62 in the "new" math.

Thanks for the review!

[davidflanagan]

Thanks for the kind review Slashdot! Thanks, Brian!

You can browse the table of contents of the book and read the beginning of each section at O'Reilly's website.

You can find another review of the book at rubyinside.com

Re:Thanks for the review!

[_14k4]

Having just started with Ruby, after Perl and Java and the usual collection of others... I must say that Ruby is a total relief. I actually have this "child like" joy with Ruby programming for simple things, complex things, and things in between. On that note, my oldest is working on his first program, in Ruby, and it's coming alone nicely...

Re:Thanks for the review!

[almiray]

David, I love your Java & JavaScript books, on your latest Ruby book: Where is the testing chapter? its 2008, unit testing is an old meme (According to Alberto Savoia in 2004), dynamic languages are very expressive but also require more thought process, which means testing should be second nature to people working with them.

I can't see a testing reference from the TOC, I hope there is something (meaningful) related to it included in the book, if not then I'm sad to say this book will help little to the next generation of Rubyists.

Re:Thanks for the review!

[davidflanagan]

almiray, As its title implies, this book is strongly focused on the language itself. It includes one (long!) chapter on the core platform, but it hardly touches on the standard library. Since Ruby's testing frameworks are not part of the language or of the core API, I do not cover them. That doesn't mean that they're unimportant, just outside of the scope of this book. This is not a book about programming methodologies, or about web application development, or about design patterns. But it does cover the Ruby language in detail.

Re:Thanks for the review!

[almiray]

Thanks David, I understand your point now.

Re:Thanks for the review!

[pileated]

Well whilst the author is here, and while I'm part way through the book, let me ask a couple of questions. I should preface this by saying that I think Javascript the Definitive Guide made me hate Javascript all the more, while Java in a Nutshell and Java Examples in a Nutshell seemed to exemplars of good programming books. So needless to say I've puzzled over David's writing over the last few years. Why do I have such mixed feelings about books by the same author? I still don't know but maybe the following questions will help.

I was reading along today when I came to this: "Assignment to a constant that already exists causes Ruby to issue a warning. Ruby does execute the assignment, however, which means that constants are nor really constant." Now this is a bit of a surprising statement. Isn't this an elephant in the room? Shouldn't it get more of an explanation?

A few pages further on, while discussing parallel assignment, we get this: "a,(b,(c,d)) = [1,[2,[3,4]]] # Parens: a=1; b=2;c=3;d=4". Now I can figure out what is happening and what the book is trying to explain. But at the same time the book seems to ignore a second elephant in the room. Why in the world would someone ever write just a difficult to comprehend statement? Is is a common Ruby idiom? If so might it not be wise to offer some explanation of why it's an idiom?

As I think back on what I've read by David, and I realize I'm sort of leaving Matz out right here and don't know how much of the writing is his, I think I see a sort of matter of factness to it. My recollection of Ruby for Rails is that it is much more interested in explaining some of the odder parts of Ruby and Rails. Perhaps the authors just prefer a matter of fact style and figure that readers can go elsewhere for a explanation of what seem to me to be rather odd elements of Ruby?

I don't say this as a criticism but really more of a question. Don't the two examples I cite seem sort of odd? If so could someone explain why they are not explained any further. Is that not the intent or style of the book? If the answer to the last is true I think that's fine. All authors write in the way that best suits them. But I ask out of curiosity. If that is the case I think it might give other readers a better clue as to what to expect from the book. Some will like the matter of factness; while others probably would like something else to augment it.

And one last, sort of unrelated question: is anyone else disappointed by the drawings? When I read that the book would be illustrated by whytheluckystiff I thought that this would make a probably good book even better. But I find them very disappointing and far less visually interesting than what can be found on whytheluckystiff's web site.

Re:Thanks for the review!

[davidflanagan]

Well whilst the author is here, and while I'm part way through the book, let me ask a couple of questions. I should preface this by saying that I think Javascript the Definitive Guide made me hate Javascript all the more, while Java in a Nutshell and Java Examples in a Nutshell seemed to exemplars of good programming books. So needless to say I've puzzled over David's writing over the last few years. Why do I have such mixed feelings about books by the same author? I still don't know but maybe the following questions will help. Have you read the JavaScript book recently? The 5th edition is an improvement over the fourth... It is different than Java in a Nutshell--simply because it is a "definitive guide" rather than a "nutshell". This Ruby book is probably more like my JavaScript book than my Java books, so if you end up liking it well enough, maybe you'll give the JavaScript book another chance :-)

I was reading along today when I came to this: "Assignment to a constant that already exists causes Ruby to issue a warning. Ruby does execute the assignment, however, which means that constants are nor really constant." Now this is a bit of a surprising statement. Isn't this an elephant in the room? Shouldn't it get more of an explanation? Frankly, I don't know the reason that constants are not constant. I could have pressed Matz to enlighten us on this point, but I suspect that the answer is not a simple one and would have been difficult to explain. In earlier drafts of the book I did actually draw attention to these rough spots in the language because they did, indeed, seem strange to me. As I spent more time with Ruby, however, I came to appreciate it more, and re-reading my drafts I felt I was being unnecessarily critical of the language I was documenting. So, as you surmise, I was left just being matter-of-fact about it.

A few pages further on, while discussing parallel assignment, we get this: "a,(b,(c,d)) = [1,[2,[3,4]]] # Parens: a=1; b=2;c=3;d=4". Now I can figure out what is happening and what the book is trying to explain. But at the same time the book seems to ignore a second elephant in the room. Why in the world would someone ever write just a difficult to comprehend statement? Is is a common Ruby idiom? If so might it not be wise to offer some explanation of why it's an idiom? This is not a very common idiom, nor is it even very well known. The particular line of code you cite is, of course, extreme: I'm taking the destructuring parallel assignment syntax to an unreasonable level of nesting to test the reader's understanding of the concept. Its not a common idiom, but it is part of the language, so I document it. It actually seems pretty cool to me, not really an elephant in the room. In this case, were I writing a less formal book, I might have commented on how cool it is. In the same way, in a less formal book, I could have commented on how strange it is that constants can have their values changed.

And one last, sort of unrelated question: is anyone else disappointed by the drawings? When I read that the book would be illustrated by whytheluckystiff I thought that this would make a probably good book even better. But I find them very disappointing and far less visually interesting than what can be found on whytheluckystiff's web site. Please keep in mind that we had to get these drawings through the internal bureaucracy at O'Reilly--we were asking a lot of the production and design teams to include them. I shouldn't speak for _why, but I think his goal for these drawings was to keep it mellow, and to be stylistically distinct from his work for the Poignant Guide.

Re:Thanks for the review!

[pileated]

Thanks for the detailed response David. If I do need to use Javascript again (I currently don't) I'll take a look at the new edition. I must say I'm very fond of the newest Java in a Nutshell and Java Examples in a Nutshell.

I suppose what I've written are more questions about the style of the book than anything else and I think you've answered them well. I hope they'll be useful to other potential readers of the Ruby book. And I look forward to finishing it myself.

I realize that my comments on the drawings might seem like needless criticism and I certainly don't want to be critical. On the other hand I just went back to whytheluckystiff's web site to see the drawings again and I'm more impressed than ever by them. So I was hoping for something special in the drawings for the book. I ended up being a little disappointed. Maybe they'll grow on me, and if not there's always the web site..........

Thanks again for your response.

Re:Thanks for the review!

[scragz]

For anyone else with programming-inclined progeny, take a look at one of why's other projects, Hackety Hack. It's an interactive Ruby environment for beginners.

In the 1980s, a language called BASIC swept the countryside. It was a language beginners could use to make their computer speak, play music. You could easily draw a big smiley face or a panda or whatever you like! But not just BASIC. Other languages like: LOGO and Pascal were right there on many computers.

In this century, you may have dozens of programming languages lurking on your machine. But how to use them?? A fundamental secret! Well, no more. We cannot stand for that. Hackety Hack will not stand to have you in the dark!!

Re:Thanks for the review!

[DragonWriter]

I was reading along today when I came to this: "Assignment to a constant that already exists causes Ruby to issue a warning. Ruby does execute the assignment, however, which means that constants are nor really constant." Now this is a bit of a surprising statement. Isn't this an elephant in the room?

In the context of Ruby, where "private" methods and instance variables are just a wee bit harder to get at rather than actually private, not enormously, though it would probably be cleaner (and consistent with how private methods, etc., are handled) if a "normal" assigment to an assigned constant raised an error, but there was a special method call that could be used to get around it.

Shouldn't it get more of an explanation?

What else is there to say to explain it? I mean, I could see providing an example where taking advantage of the fact that it only produces a warning rather than blowing up might be useful (if you can construct one), but as far as explaining, what more is there to say?

A few pages further on, while discussing parallel assignment, we get this: "a,(b,(c,d)) = [1,[2,[3,4]]] # Parens: a=1; b=2;c=3;d=4". Now I can figure out what is happening and what the book is trying to explain. But at the same time the book seems to ignore a second elephant in the room. Why in the world would someone ever write just a difficult to comprehend statement?

I would guess the only reason for anything that complicated in a multiple assignment would be because the author was writing a book using a needlessly complicated case to illustrate how the feature functioned so that people could understand the feature, even though they would never, ever, use it that way in practice.

At least, I hope so.

Is is a common Ruby idiom?

I've rarely seen a multiple assignment much more complex than the simple swap case ("a, b = b, a") in Ruby; I don't think anything remotely like that example is common.

As I think back on what I've read by David, and I realize I'm sort of leaving Matz out right here and don't know how much of the writing is his, I think I see a sort of matter of factness to it. My recollection of Ruby for Rails is that it is much more interested in explaining some of the odder parts of Ruby and Rails. Perhaps the authors just prefer a matter of fact style and figure that readers can go elsewhere for a explanation of what seem to me to be rather odd elements of Ruby?

As I recall, K&R is pretty matter-of-fact, too, and that's what the authors held out as their model. Really, I'm glad that The Ruby Programming Language is different in its tone and approach from The Ruby Way, Programming Ruby, and Ruby for Rails, because we already have those books, and they do what they do pretty well.

Re:Thanks for the review!

[swimmar132]

Classes are constants in Ruby, so it's good to be able to modify constants (so you can modify classes).

Re:Thanks for the review!

[jdinkel]

personally I like the idea of a shorter, concise book that documents the entire language. Too much lip-service just means there's more you have to wade through to find the information you need. If you want a lengthy book that draws things out and explains everything more than is necessary to know the raw syntax, then pick one of the other books. I'm not saying one way is better than the other, but it's better to have the choice. Ironically, I would say this parrellels the Ruby language -- sometimes things can be done multiple ways just because it's nice to have the option there in case you would ever need it.

Re:Thanks for the review!

[shirai]

There is a very good reason that constants are not constants which relates primarily to the way the Ruby is "compiled." I put "compiled" in quotes because as Ruby users know, there is actually no difference between compile time and run-time. There is, however, a phase where you load the code in from your Ruby files at which point the classes are defined through executable statements. Constants are usually defined in classes at this point as well.

If you couldn't redefine constants, the second time you loaded a file you would throw errors. The reason why you would reload files is in a running development environment such as a framework like Rails or Merb. I also have a web framework (currently private but possibly we'll open source later) so I know this issue pretty intimately.

To clarify, the way it works is this: You are viewing a web page through a Ruby framework. The page rendering code is in a class. You want to make a change to a class so you go to the file and edit it. This may include changes to a constant. When you view the page again (by hitting refresh), the Ruby framework checks to see if the file has changed. If the file has changed (e.g. the constant we changed), then the file gets reloaded. Although we don't want to be changing constants in production, the ability to change constants in development mode is valuable. The alternative is we have to restart the server. The fact that it throws a warning is actually a good compromise because it means it's not normal behavior, but it is acceptable in certain circumstances.

Re:Thanks for the review!

[Anonymous Coward]

A few pages further on, while discussing parallel assignment, we get this: "a,(b,(c,d)) = [1,[2,[3,4]]] # Parens: a=1; b=2;c=3;d=4". Now I can figure out what is happening and what the book is trying to explain. But at the same time the book seems to ignore a second elephant in the room. Why in the world would someone ever write just a difficult to comprehend statement? Is is a common Ruby idiom? If so might it not be wise to offer some explanation of why it's an idiom? My hazy recollections of the analogous destructuring-bind macro in common lisp was that it was mainly useful in code generators, and it would also serve as a pretty useful tool for the type of RAD you get with interactive programming of a live system. In that capacity, it's sort of like duck typing to the logical extreme.

Re:Thanks for the review!

[_14k4]

That's awesome! Thanks! Right now, he's nine and still working up the typing skills... but at the same time really wanting to program. So I've made little modules for things like "Hangman" games, and printed "recipes" he can use that utilize those modules... keeping the dirty dirty work hidden, but at the same time helping him LearnCamelTyping and other great skills.

Re:Thanks for the review!

[doti]

I've rarely seen a multiple assignment much more complex than the simple swap case ("a, b = b, a") in Ruby; I don't think anything remotely like that example is common. I don't do Ruby yet, but in Perl I see this multiple assignment is often used.
Examples:
my ($x, $y) = ($i % $width, $i / $width);

my ($from, $to, $subject, $date) = get_email_info($email_header);

my ($dirname, $basename) = $path =~ m{^(.*/?)([^/]+)$};

Re:Thanks for the review!

[dylan_-]

Thank you! I've been considering stuff for my nephew and I was actually thinking of a ZX Spectrum emulator (Speccy was my first computer), to show how things worked, but this seems to have actual modern applications that can be understood. Helpful people like you are the reason I still read Slashdot comments. Thanks again!

Re:Thanks for the review!

[pileated]

I agree with you that it's good to have a variety of books and styles on Ruby. I didn't mean to criticize this one, just to get a better explanation, esp. when the author was available. To me it seems odd to say that "constants are constant" and then move on without further explanation. I believe David's response explained just why he did so: he felt speaking about some of the languages rougher spots might seem overly critical.

I come from a different background that thinks something is more easily understood if its fully explained, warts and all. So I'd prefer to see an extra line perhaps explaining why constants are constant than a line of very unlikely usage, i.e. the extravagant parallel assignment. But that is just me and my personal preferences.

I also asked these questions because I've had such mixed reactions to David's books in the past. Again this is just me. I really disliked the Javascript book, even though I forced myself through most of it. So I was shocked to find out how much I enjoyed Java in a Nutshell and Java Examples in a Nutshell from the same author. When I found the two parts of the Ruby book that had caught my attention while reading the book yesterday it seemed like a good time to just ask David. I liked his answers and they helped explain to me why I've had a mixed reaction to some of his books. They have a matter of fact style that I sometimes wish was more expansive. That's just me and his answers helped to clarify that.

As an aside I'm still looking for the perfect Ruby book. So far Ruby for Rails has been the most enjoyable to me personally, even though it is not as in depth, nor does it intend to be, as the Pickaxe book, the Ruby Way, etc. And I am enjoying The Ruby Programming Language.........

Re:Thanks for the review!

[pileated]

Since I've had a couple of questions if not criticisms I thought I ought to say how useful I found the section on flipflops today. I've needed to parse a log file where it's important to match and grab more than just one line. I used to do this in sed and awk but this script is not for a *nix platform. Then I read this:

ARGF.each do |line|
print line if line=~/TODO/..line=~/^$/

Perfect for what I needed to do! It's now a 15 line ruby script. And though the paragraph begins by saying "flipflops are a fairly obscure feature of Ruby" it turns out to be exactly what I needed.

Re:Thanks for the review!

[DragonWriter]

Yeah, I see things on that order of complexity in Ruby, too. But to me, that's pretty much the same level as a swap; each of those cases is destructuring a simple, non-nested sequence (either an express sequence or one generated by a function call that returns a sequence) on the rhs into multiple variables on the lhs. Its not the kind of nested nightmare that the (deliberately unusually involved) example the The Ruby Programming Language used.

What I was saying is that beyond the simple, non-nested cases, it doesn't seem to be common in Ruby, not that no one uses multiple assignment.

I love Ruby

[Anonymous Coward]

I have a ruby red palm from jacking it to pictures of Kathleen

Re:I love Ruby

[jdinkel]

Kathleen Sebelius? Gross.

Trash

[bluefoxlucid]

Having used Ruby, I can say it's trash.

Re:Trash

[dedazo]

You're going to get modded as troll here, but I think there's been a huge backlash against Ruby lately (just read programming.reddit.com once in a while), and rather than blaming the language or the toolset itself I think the problem is that it was so excessively hyped (mostly because of Rails) that whenever people find a problem somewhere then the whole thing is declared as lacking.

Personally I don't like Ruby, but that doesn't mean the language is not good. It has some interesting syntactic sugar. And Rails didn't really invent anything new. MVC and ActiveRecord for example had been done to death before, but it packaged them in an attractive and simple little box with a nice glue language that made 80% of building a web app simple. It's always the remaining 20% that's hard, and I think Rails was not designed well enough to enable developers to jump the last hurdles. Much of the criticism I've read in the past few months about Rails is related to problems with how the public Rails API is designed and how too many developers are using runtime hacks to extend objects instead of having sane, language-specific inheritance/override methods for extension purposes. Again, nothing to do with Ruby the language, but you can't reall discuss Ruby without Rails because in the real world it's what currently drives its adoption. I doubt many people are writing desktop apps with it.

Let this be a warning to framework designers: your language, runtime and toolset better match the amount of hype you pile on your work. It's not good enough to have a cool language to go along. The popular Perl (Mason, etc), Python (Django, etc) and PHP frameworks prove it can be done.

Re:Trash

[Foofoobar]

Yeah RUBY devs will definitely MOD you as troll but the fact is you are right. The hype was far greater than the language could deliver and the fanboi's made it worse as they cannot face the limitations of the language. I mean no language is perfect and they all have serious flaws but for some reason RUBY devs think they are immune to criticism which seems to make it a bit worse.

I have sympathy for your loss of mod points due to others ignorance.

Re:Trash

[crayz]

Yeah, I feel really sorry for Ruby

Re:Trash

[sheldon]

Going from 1 user to 6 users may be 600% growth, but I'll take 2% of all jobs posted versus .02% for $1,000, Alex.

Re:Trash

[crayz]

And small but rapidly increasing numbers of jobs is evidence of a "huge backlash against Ruby lately"? Or were you just attacking a straw man?

Re:Trash

[DragonWriter]

Much of the criticism I've read in the past few months about Rails is related to problems with how the public Rails API is designed and how too many developers are using runtime hacks to extend objects instead of having sane, language-specific inheritance/override methods for extension purposes. Again, nothing to do with Ruby the language

Actually, the absence of features for explict overriding (vs. implict overrides as the default) is something to do with Ruby the language (just like dynamic rather than static typing, etc. are inherent to Ruby as a language.)

OTOH, the complaints about "monkeypatching" are pretty much just a variation on the complaints about dynamic typing: "the language doesn't bind your hands enough, and someone else might do (or has done) something I don't like that was enabled by that."

Fine, look, everyone knows where to find Java and C if they need them. Beyond that, if you don't like the way the Rails team (or certain third-party plug-in writers) have used the power to reopen classes and objects, its not like there aren't plenty of other Ruby web application frameworks, ORM solutions aside from ActiveRecord, and libraries available for most uses in Ruby. Maybe the one library you really want was programmed by someone whose ideas about how best to use the language don't match yours, but that's possible with any language no matter what features it has. If you want code written to your specs, you've either got to write it yourself or pay someone else to do it for you, and complaining about a language because someone has used it to write a library using techniques you don't like isn't going to solve anything.

but you can't reall discuss Ruby without Rails because in the real world it's what currently drives its adoption.

I dunno, I find it pretty easy to discuss Ruby without Rails. Rails is certainly the framework that made Ruby really visible in the US (though I gather it was fairly popular in Japan even before Rails), but I think that as it is getting exposed, the size of the non-Rails Ruby community compared to the Rails segment is probably growing.

I doubt many people are writing desktop apps with it.

I would imagine that if there weren't quite a few people doing that, you would have fewer GUI toolkits for it. And, of course, its also useful for system scripting; not every programming task is about a big app, whether web or desktop.

Re:Trash

[HiThere]

You can say it, of course, but that doesn't make it true.

Personally I find Ruby to be stylistically a superior language in many ways, though of course it's not suited for all problems. My chief gripe with it has to do with the difficulty with doing binary I/O. It seems to presume that everything should be translated into characters. And the lack of a non-text database connection. (I've even seen a manual on Ruby that declared that the external representation of numbers SHOULD be text...which is only true sometimes.)

But if what you're doing is web design, those aren't problems. And in many other circumstances those aren't problems.

Another problem with Ruby is that it can be difficult to locate errors generated by typos, or by forgetting to close a block. This is noxious, but it seems to be difficult to fix.

Re:Trash

[bXTr]

Is fanbo(i|y) like the new N-word or something?

Re:Trash

[sheldon]

strawman? Looked to me like you were having fun playing with statistics.

He said there had been a backlash against ruby in blogs, not necessarily amongst startups who are looking to be buzzword compliant.

Re:Trash

[zigamorph]

I dunno, I find it pretty easy to discuss Ruby without Rails. Rails is certainly the framework that made Ruby really visible in the US (though I gather it was fairly popular in Japan even before Rails), but I think that as it is getting exposed, the size of the non-Rails Ruby community compared to the Rails segment is probably growing. Possibly because it's the Rails part of RoR that doesn't scale? Without rails it's a capable scripting language. Not as fast as python or perl perhaps but fast enough for a lot of applications. Rails OTOH, like a lot of web frameworks, falls into the framework trap. It makes simple things (getting some data from a DB) easier and difficult things (scaling) more difficult.

Re:Trash

[DragonWriter]

Possibly because it's the Rails part of RoR that doesn't scale?

Not really. Its because Ruby is a really nice language for lots of people, and once those people are exposed to it, through Rails or otherwise, they tend to use it for things (whether they start with Rails or not) that aren't web applications, and thus for which Rails is pretty much irrelevant.

Rails OTOH, like a lot of web frameworks, falls into the framework trap.

I've yet to see any evidence that Rails "makes scaling more difficult". I've seen a few complaints that particular applications didn't scale well on Rails that even the source of the complaints later backed off from claiming was a problem with Rails rather than their own approach to scaling, and a lot of complaints that the way to scale a Rails app to handle larger loads isn't the way you scale up an application on some particular other framework. What I don't see a lot of is any indication that scaling Rails is actually generally more difficult.

hyperbole

[Anonymous Coward]

"The Beatles' album cover for Sgt. Pepper's Lonely Hearts Club Band sparked intrigue and investigations into coded messages with hidden meanings. The same could happen here. "

ummm talk about bringing something in completely out of the blue.....yes, I'm sure this programming book will be very similar to Sgt. Peppers......
Besides, what exactly is "intrigue and investigations into coded messages....."? Will we all start deciphering treasure maps? Or perhaps purchasing books of arcane linguistic rules which allow us to manipulate complex electronic devices? Or has that already occurred? At least introduce some sort of musical/artistic metaphor theme in the beginning so this attempt to inspire some sort of creative dynamism isn't entirely bizarre. And can't we give the Beatles a rest? Do the Beatles always have to be the standard [creative reference] insert that brings up all the untrammeled free market capitalism + technology = wonderfulness tech-geek ideological koolaid shit? /end rant.

Other than that I find the review to be useful and thorough-sounding though not entirely critical (as in analytic i guess)...

Ruby Saved Us From Perl

[Anonymous Coward]

I can't believe our company at one time actually had a good portion of our tools written in Perl. Those were the dark days back before Ruby.

Ruby has been a godsend. Clean, clear, powerful and maintainable.

Re:Ruby Saved Us From Perl

[cmdr_tofu]

Please mod the parent up. I am a fellow PERL->Ruby convert. While PERL always has a soft spot in my heart and has one of the best communities in the world, Ruby really is an *easier* language. It is clean, simple and extremely easy to write readable code. I am not a Rails expert, but for sysadmin stuff, Ruby and Python are great alternatives to PERL.

Re:Ruby Saved Us From Perl

[failedlogic]

I wanted to ask a question related to this, and yours is the perfect response! ;)

I've looked at the Ruby syntax through a couple of books in the bookstore and from what I saw, I liked it a lot. For most stuff I want to do, Reg Ex, SQL Database search/output and Unix shell stuff, Ruby seems like a substantially easier language as you mention. I think C or C++ would be more complex than what I need and I never quite wrapped my head around why Perl is written the way it is. I haven't looked much at Python or similar languages.

As it sounds like you're doing some (or all) the things in Ruby that I'll ever need and are not using Rails, is Ruby the "best" alternative, or is there another language all-purpose I should look into? Please bear in mind as I ask this that I'm not an I.T. worker and don't have a comp-sci degree. I'm just looking for some efficient ways of automating some tasks I need to do or do everyday and would rather use a program than a GUI. :)

Re:Ruby Saved Us From Perl

[Anonymous Coward]

Ruby really is an *easier* language. It is clean, simple and extremely easy to write readable code.

I don't believe you. There is a language that is easier to write readable code than Perl??? It must really wtfpwn Perl if it is that good.

Re:Ruby Saved Us From Perl

[Hognoxious]

Are you saying it's impossible to write readable code in perl?

I'm not saying you're wrong but I don't think we can really be 100% sure until someone actually tries.

Re:Ruby Saved Us From Perl

[bitingduck]

I've done some, but it looks like C.

Re:Ruby Saved Us From Perl

[Anonymous Coward]

My company relies on Perl for running its unix systems.

As long as you use Perl for what it's intended and don't try to be too smart, then it's generally readable.

At least, that's my opinion as a C++ developer having to read other people's randomly placed scripts every couple of days.

Re:Ruby Saved Us From Perl

[mikehoskins]

I, too, am a Perl to Ruby Refugee (tm) and I don't ever want to go back, in spite of the positives of (shudder) Perl. I spent 12 years in solitary in a Perl Prison. (OK, I exaggerate the pain a bit).

I have tried (strived) to write (and clearly document) Perl code and still have a harder time reading "well written" Perl that *I* wrote than (almost) anybody's Ruby code, not being a Ruby expert (yet).

Try reusing Perl code, outside of stuff written to be part of a Perl Module (.pm). Blech.

Anyway, rather than merely cursing the darkness, I suggest that Rails is a terrible way to learn Ruby. Rails is so much of a DSL that it hides Ruby underneath. It makes Ruby seem very web-centric and people don't realize that there's a quite stunningly elegant programming language underneath all of that (albeit) nice Rails DSL (Domain-Specific Language).

Is Rails nice, too? Yes, from what I've seen, but it made me say "what is that?!?!?" every time I tried to take up Ruby, when Rails was part of the equation.

"Plain Jane Ruby" on its own, is not hard to pick up, for Perl programmers. RoR might be, however, until you understand Ruby, itself and understand metaprogramming/DSL's. DSL's let you mold Ruby into something else that you'd like Ruby to be.

Learning from a DSL, like Ruby on Rails (RoR), muddies the water for quite awhile.

Re:Ruby Saved Us From Perl

[cmdr_tofu]

Ruby is very good for that, and very easy. I am not qualified to speak on other languages (except maybe perl, or c/java/c++ which you are not interested in). However without being a Python expert, I think Python will do all the things Ruby does equally well. You may also consider PHP for all the same tasks, but PHP definitely seems more web-oriented to me.

Re:Ruby Saved Us From Perl

[Anonymous Coward]

Ni, I say! Ni! There is neither a whim or a whill amonst the republick to hast written ledgeadidble perl code.

Perl Cookbook: 13.0-13.2
And god, (parser), said unto him: Bless you child, err cordially: bless($self, $class);, for your are a class... no no no umm err object.... err scalar? thingamajig?... maybe..., anyways, and you return a reference or scalar or thingamajig that will confuse and annoy all perl programmers to the end of time with your wierd and often misunderstood ability to transcend many different programming paradigms often within the same script and in most highly, within the same subroutine. Amen.

Re:Ruby Saved Us From Perl

[Stamen]

Pure opinion of course, but: I think Perl was the best language for these things. But now I would choose either Python or Ruby; I personally would be happy with either. I choose Ruby because it fits my style better, but Python is an awesome language also. Both have great communities, both have a lot of libraries (python is better at this), and both have modern language features. The style and decisions each made are different, so neither is better, but one is better for you.

Re:Ruby Saved Us From Perl

[chromatic]

Ruby has been a godsend. Clean, clear, powerful and maintainable.

... and full of magic unicorn fairy dust powers which suddenly turn teams unable to write decent code into gods among men.

Re:Ruby Saved Us From Perl

[chromatic]

Try reusing Perl code, outside of stuff written to be part of a Perl Module (.pm).

It's often easier to reuse code designed to be reused. You're dangerously close to tautology here.

DSL's let you mold Ruby into something else that you'd like Ruby to be.

... sort of like APIs in other languages, except that most other APIs don't require you to learn the ins and outs of Ruby's particular parser corner cases if you want to debug things.

Coroutines

[Simon (S2)]

Did someone here actually use callcc for something "real" in production code that could not be done someway else or was best implemented with callcc? For what? Can you make an example? I am really just curious (personally I love callcc, but only ever used it as a style exercise).

Re:Coroutines

[sfraggle]

You can use it to implement the Intercal COME FROM statement. No serious modern programming language should be without this feature.

Re:Coroutines

[Simon (S2)]

This is actually the coolest thing ever :)
I didn't know about COMEFROM. This is pure genius:

$ cat test.rb
require 'comefrom.rb'
 
come_from 'a label'
puts 'hello'
label 'a label'
 
$ ruby test.rb
hello
hello
hello
hello
hello
hello
hello
hello
...

Re:Coroutines

[krog]

Call/cc can become useful in web applications where you have a batshit insane workflow. Seaside, the Smalltalk web framework, bets the farm on it. It's in other places like Perl's Jifty too.

Most of the web apps I write wouldn't benefit from this sort of treatment, so I haven't jumped in too far, but call/cc has its uses for sure.

Re:Coroutines

[arevos]

I've seen some rather nice syntax sugar for monads implemented with callcc in Ruby.

Re:Coroutines

[pnewhook]

didn't know about COMEFROM. This is pure genius:

Why is joke syntax genius?

Re:Coroutines

[Abcd1234]

Just to be clear, Seaside isn't "batshit insane". :) Frankly, I love the way it works... will it be the Next Big Thing (tm)? I have no idea... I don't even know if it's really a good idea in the long run. But it should makes building stateful transactions in the stateless world of the web incredibly easy.

Re:Coroutines

[krog]

I never said Seaside was batshit insane, only the workflows of the apps which are well-suited to it. Seaside isn't insane, it's just esoteric.

Re:Coroutines

[Abcd1234]

Actually, I would disagree. In traditional webapps, we build systems that are stateful and transaction oriented. Thus is fundamentally a consequence of the way the web works. Basically, the nature of the web has dictated how we build our systems. Seaside, OTOH, allows one to build apps in a much more straightforward manner. Workflows with the user are, in code, represented as just that. Workflows. It is, I think, a much cleaner way to look at the problem.

But, we are getting off the topic, here, which is, of course Ruby. OTOH, I think Ruby is just Smalltalk's bastard, warped stepchild, so maybe it's not so off-topic after all. ;)

Re:Coroutines

[Simon (S2)]

Why is joke syntax genius?

Just because it remained me the old times... you know

10 PRINT "I am the coolest guy"
20 GOTO 10

Making it the other way around is funny and brilliant.

Re:Coroutines

[Anonymous Coward]

How can that be "the coolest thing ever"? Isn't Brad Pitt making movies any more?

Re:Coroutines

[krog]

In traditional webapps, we build systems that are stateful and transaction oriented. Thus is fundamentally a consequence of the way the web works.

Not so fast! I think you trivialize how well 90% of websites fit into a stateful, transaction-oriented architecture -- especially when hosting and serving requirements are factored in. I don't think that's a consequence of the way the web works, but rather the opposite; I think the way the web works is a consequence of the tools that power most of it.

Of course Seaside is not limited to crazy workflows and such; it just gets its chance to shine in situations like that, because the 90% solution falls apart quickly.

But, we are getting off the topic, here, which is, of course Ruby. OTOH, I think Ruby is just Smalltalk's bastard, warped stepchild, so maybe it's not so off-topic after all. ;)

Smalltalk has so many children! Ruby and Objective-C are my favorites, but in general, I'm happy to see pure message-passing semantics wherever I run across them.

Re:Coroutines

[Anonymous Coward]

Why is joke syntax genius?

Go back to Java.

Re:Coroutines

[Estanislao Mart�nez]

I've written production code using backtracking in Scheme, implemented with call/cc. In Ruby, IIRC, there's a library that uses callcc to convert Ruby-style internal iterators (that take a block as an argument and call it with each element of the sequence) to Python-style external iterators (where the iterator client advances it manually by using a next() operation on the iterator).

This is just one example of a more general use of call/cc--inversion of control. You have a piece of code that's designed in such a way that it wants to be the main routine, and use your code as a subroutine. You actually need the thing to work the other way around. Call/cc is an operator that allows you to solve this problem: you start up the other code's main loop, but you capture its continuation, which allows you to suspend its execution; then the bossy code calls back another piece of your code that captures a continuation that resumes bossycode, and invokes the suspend one.

The example that's been cited in this thread, continuation-based web frameworks, fits exactly into this framework. A servlet container (to use the Java term) is a bossy piece of code that expects your code to be written as stuff that it calls. However, you want to write your servlet as if it was the boss, with its own main loop that stays alive during multiple requests. So, your servlet captures a continuation that escapes back to the container, captures a second continuation that resumes the servlet's loop's execution, and uses the first captured continuation to return back to the container. When the container invokes your servlet again, it uses the second captured continuation to restore the servlet's loop.

Of course, the big problem is that there are very few production languages that implement call/cc efficiently...

Re:Huh? Is this the "new" English?

[farker haiku]

Let me parse it for you.

Drawings are the work of Rubyist-extraordinaire "why the lucky stiff" and technical reviewers include well known Rubyists David A. Black, Charles Oliver Nutter, and Shyouhei Urabe.

The rest of it should be passable English.

Re:Huh? Is this the "new" English?

[iluvcapra]

why the lucky stiff is one token. Try enclosing it in quotes and recompiling.

Sketchup

[Quiet_Desperation]

I may have to grab this. The Ruby scripting capability of Google Sketchup is calling out to me, and I loves me some 3D modeling. :-)

Another good book to pick up...

[tcopeland]

...if you're doing Rails apps is Advanced Rails by Brad Ediger. It's got a ton of helpful hints on all sorts of things - sessions, memcached, how Rails uses Ruby's dynamic features, how plugins work, how to do complex associations, details on REST, etc etc.

The nice thing is that he doesn't fool around with explaining the simple stuff that you know already if you've done even one Rails app; he gets right down to business. Of course there are always interesting gotchas, but this is a book every Rails developer should have.

HEY TACO!! I'M TALKING TO YOU!!

[Anonymous Coward]

Come on, Taco - let's get rid of this new discussion system already. It's a PITA to use.

Oh, and this new thing with starting A/C's off with a Score: -1 isn't going to shut me up. Every time I post a comment like this, someone agrees with me, so I'm not the only one out there who feels this way. So let's stop taking lessons from the mafIAA's in assuming that everyone has corrupted morals. That's what the wonderful moderation system is for, innit?

What an appropriate CAPTCHA: unhappy. Was that calculated on your part?

Ruby 1.9 and Programming Ruby

[DragonWriter]

The Ruby Programming Language is a slim, more manageable 444 pages and, in contrast, is the only one to cover Ruby version 1.9.

This is true of the dead-tree editions of the three major books you list, though it may be worth noting that the 3rd Edition of the Pickaxe (Programming Ruby) is currently available (in PDF) as a beta book and covers Ruby 1.9.

Re:Ruby 1.9 and Programming Ruby

[Peter Cooper]

That it does, but it's not as good as this one.

Re:Ruby 1.9 and Programming Ruby

[DragonWriter]

That it does, but it's not as good as this one.

The Ruby Programming Language is a great book, from what I've seen of it (I've read a bit on Safari), but I still like Programming Ruby (and The Ruby Way and Ruby for Rails -- a great general Ruby book that doesn't have as strong a Rails focus as the name might suggest -- even though neither of those two has yet been updated for 1.9), too. I wouldn't particularly want to do without any of them, though if I had to choose only one right now, I might lean toward The Ruby Programming Language. But, fortunately, I don't have to choose only one.

David Flanagan

[drgroove]

David Flanagan is responsible for writing O'Reilly's old, unreadable JavaScript books... not a lot of confidence that he did much better on Ruby. If an O'Reilly book has been written by Flanagan, I don't buy it.

Re:David Flanagan

[davidflanagan]

"Unreadable" is a pretty subjective opinion. If you didn't like JavaScript: The Definitive Guide, then you probably won't like The Ruby Programming Language, either. But many people do like my JavaScript book and consider it the definitive book on the language. I've tried to do the same for Ruby in this book.

Great review, Brian!

[xertroyt]

Very informative review . . . Off to Amazon!

This book can be "free", legally even...

[DragonWriter]

it can be "free" if you have no or very low morals.....

It can also be "free" (of marginal financial cost) if you subscribe to Safari.

Struggling to parse the submitter's blurb

[zakkie]

Is it me, or is there something missing right before "why the lucky stiff..." in the submission?

Re:Struggling to parse the submitter's blurb

[jdludlow]

"why the lucky stiff" is a person's nickname.

collect, select, reject, and inject

[A nonymous Coward]

Sounds like they should have listed Arlo Guthrie as co-author.

I bet mods don't get the reference and mark me down.

Re:collect, select, reject, and inject

[asylum_street_blues]

Remember Alice? There's a song about Alice...

Re:collect, select, reject, and inject

[Anonymous Coward]

Ruby takes those method names from Smalltalk. I believe Dan Ingalls created the names of those methods in Smalltalk and was inspired by Alice's Restaurant. I believe I remember that from a post on Squeak-dev back in the 1990s.

But does it scale?

[Anonymous Coward]

Mmm. Duck typing and superficially nice code.

Ruby. Fast, Reliable, Cheap - Pick 1.

fuc4 a s4onge

[Anonymous Coward]

Posts on Usenet are bring your own feel obligated to the NetBSD project,

Ruby book

[Anonymous Coward]

Two words Common Lisp.

NEXT!

Give me a hard problem here, people, COME ON!

BTW Slashdot's comment system sucks donkey balls. Probably it is implemented in Ruby.

(LOL, v-word == "buries")

Re:Huh? Is this the "new" English?

[Anonymous Coward]

Thank you!

Which to learn first: python or ruby?

[Anonymous Coward]

I'm a programmer and for some time now I want to learn both Ruby and Python.
Due to real-life time constraints I believe I'll manage to master only one in the near future.
Which one should I learn first? Do you think the order matters? Which one will bring a more immediate benefit to me? Maybe I should learn Ruby now and wait for Python3000?
What are your thoughts on this?

Re:Which to learn first: python or ruby?

[sciurus0]

There are more free resources for learning python.
http://docs.python.org/tut/
http://diveintopython.org/
http://www.swaroopch.com/byteofpython/
http://openbookproject.net/thinkCSpy/
http://www.greenteapress.com/thinkpython/
http://en.wikibooks.org/wiki/Non-Programmer's_Tutorial_for_Python

Re:Which to learn first: python or ruby?

[codepunk]

Depends if you ever want to learn ruby or not?

Once you learn python you ain't gonna get past hello world in ruby. You will
sit there, look at the syntax and say what the hell do I want to learn this for.

Re:Which to learn first: python or ruby?

[mooingyak]

It's all a matter of taste. I felt the exact opposite way when looking at the two languages.

I'd take either one in a heartbeat over perl though.

Re:Which to learn first: python or ruby?

[mikehoskins]

I agree. I'm having the same issue. In learning Ruby, I don't want to go past "Hello, World!\n" in Python, for exactly the same reasons.

After 12 years of Perl, though, I hope I'm done with it. Either Ruby or Python are going to take you far as a programmer, since both languages are modern and elegant, in different ways. Perl 5.x is like BASIC, in that it teaches you bad habits.

Ruby does have a sense of enlightenment, though. I can't comment about Python, concerning this aspect. It seems that its "Lispiness" gives you a sense of "Aha" quite often. I feel that I am learning a lot about comp sci using Ruby that I never got in C, C++, Assembly, Perl, or PHP. All languages gave me an occasional "Aha" moment, but not as often as Ruby (combined, maybe). This is part of the fun, IMHO.

I am no Rails user, either. I'm currently limiting myself to straight Ruby and JRuby. I'm doing "pure shell scripting" and tiny apps.

The whole ideas of DSL's and Metaprogramming and the fact that "everything is an object" (like Smalltalk but not like C#/Java) are way cool and modern. These concepts are changing the way I think about programming in ways Perl couldn't. To my dismay, every full-time Perl developer I talk to (so far) isn't convinced "unless there are lots of Ruby jobs."

I could be wrong, not actually learning much about Python (donning asbestos suit), but I feel that Ruby is a more powerful, more elegant language than Python, for most problems at hand (but certainly not all). Python, on the other hand, is more mature (including speed) and has more code libraries. Both are incredibly powerful and elegant, however, and are worth learning. (I may pickup Python some day, myself).

I'm not really commenting much on PHP at this time, having had several years in this (mostly web) scripting language. Perl is more directly comparable to Ruby and Python.

Whatever you pick, both languages have a C (native) version and have active Java and .net projects (both compiled and interpreted). This, in and of itself, has the potential to help overthrow Perl and PHP as rulers of the scripting universe. Who knows?

Pick one and consider taking a look at the other. Ruby is really fun, for most everyone who has sat down and really tried it. I assume Python can say much of the same.

I picked Ruby, for now, and have (mostly) not been disappointed.

Re:Which to learn first: python or ruby?

[cabazorro]

I don't know python but if you can do something as succinct as

myList = []
10.times do |i|
      mList.push(i)
end
myList.each do |l|
      puts l
end

Again it is not about Rails of structuring things, Is the organic aspect of the language that works as an extension of your action with so little translation/morphing. With Ruby, my actions are more transparent. With Ruby I see the actions, not the syntax, which is what I want. Now, If this looks very similar to Python, great. I heard that python requires you to count your spaces, that stopped me right on the start. Cheers.

Re:Which to learn first: python or ruby?

[DragonWriter]

Once you learn python you ain't gonna get past hello world in ruby. You will
sit there, look at the syntax and say what the hell do I want to learn this for.

I learned Python pretty much immediately before learning Ruby, and I personally find Ruby more attractive, from a syntactic perspective, even before considering Python's interesting use of whitespace, which doesn't bother me as much as it does some people, but still isn't as attractive to me as it appears to be to Python fans.

Re:Which to learn first: python or ruby?

[Anonymous Coward]

I used to be a professional Python programmer, which is to say I used to write Python scripts for a living amongst other things. I switched to Ruby. That's all I use when I have the choice.

Why? the things I write are more naturally and easily expressed in Ruby (I use closures a lot) for me, and forced in Python. And I don't need multiple inheritance or Rails. When I programmed in Python I banged my head against the wall in frustration at least once a day.

I will say this is favor of the Python community: they do a *much* better job of producing printable English language documentation than any other scripting language community on the planet. It's been 15 years and there's *no* printed standard library book for Ruby. It's a major source of irritation, and one that's worth sacrificing a Rails book or four to fix.

Re:Which to learn first: python or ruby?

[smellotron]

I don't know ruby, so I may not totally understand that snippet, but here's a few python equivalents:

# ruby
myList = []
10.times do |i|
      mList.push(i)
end
myList.each do |l|
      puts l
end

# python (normal loop, more straightforward)
for l in range(0, 10):
    print i # or sys.stdout.print("%d\n", l)

# python (list comprehensions, more direct analogy)
import sys
myList = range(0, 10)
[ sys.stdout.print("%d\n", l) for l in myList ]
# note this is a bit wasteful, since list comprehension is a "map" operation, giving us a list that we immediately discard afterwards

Regarding python counting your spaces... if you don't already have consistent whitespace for indentation, your code probably looks like crap.  The whitespace
"requirement" in Python is a non-issue, since 99% of the sane world already indents by blocks.

From what I've seen, anonymous blocks in ruby have more lightweight syntax than Python (which requires either a lambda function, which can only have expressions but not statements; or a locally-defined and named function).  Other than that, there's not a great deal I've seen different between the languages.

Re:Which to learn first: python or ruby?

[Gonwin]

Whitespace is an issue when you want to use python as an embedded language in, say, an html page or an SQL script or XML... Suddenly where you statements appear is dictated to you. Ruby is far more flexible in this area.

Re:Which to learn first: python or ruby?

[Breakfast Pants]

You could have used a generator comprehension instead of a list comprehension.

Re:Which to learn first: python or ruby?

[WNight]

It's more about the iterators than the printing.

To just print that you'd type

puts (1..10).collect

And if you just wanted it in a variable you could write:

puts nums = (1..10).collect

Personally, I dislike the do/end block style and the multi-line nature. It's wordy and means I can't see as much on the screen. I'd rewrite the example as:

nums = []
10.times {|n| nums << n }
nums.each {|n| puts n }

Though the benefits IMHO come only when you start chaining commands together, as with a pipe (|) in shell.

# take numbers, multiply all by 2, discard any evenly divisible by 3, turn to strings, reverse, join around commas, and print
(1..10).collect {|n| n * 2 }.reject {|n| n.remainder(3) == 0 }.collect {|n| n.to_s }.reverse.join(', ')
=> "20, 16, 14, 10, 8, 4, 2"

Admittedly, that's kind of a strange set of things to do, but very often it lets me stick to one line per intent, instead of letting the necessary actions dictate the shape of my code.

Re:Which to learn first: python or ruby?

[SyntheticTruth]

I think that is a bit unfair. I love python; after years of Perl and various shell languages I came to find Python and was blown away by the language. But...it has it's warts too. Lately (in the last year or so) I have learned Ruby, and for more than just Rails. I've done games, a couple gui apps, and an IRC chat-bot in Ruby. (Incidently, it was the first version of this bot that I used as my "learning app" in Python.) Y'know what I found? Both languages have their strong points and have their warts. Right now, I'm a bit split on which I like better, but leaning a -bit- towards Ruby simply due to syntax preferences. (I -like- "end" keywords, which I found out when I was learning Lua.) Python is still more readable in my opinion, but Ruby allows me to get the code ideas outta my head and into the machine faster and sometimes, more elegantly (especially with case/end blocks that are still lacking in current Python (though I am aware it's soon to be had.))

Saying you can't get past Hello World, I know, is a purposeful stretch, but I say play fair. ^.^

print "Hello World!" # Python
puts "Hello World!" # Ruby

...and the difference really is what again? :D

.ST.

Re:Which to learn first: python or ruby?

[happyfrogcow]

I'm still convinced that no conversation of python or ruby is complete without mentioning the intriguing Common Lisp. If you want a web framework with it, check out Weblocks

Re:Which to learn first: python or ruby?

[nuzak]

> You could have used a generator comprehension instead of a list comprehension.

Sure, but something would have to consume it or it would never start. At that point you may as well just use a loop. I think the OP was just showing off syntax -- no one would ever actually write real world python like that.

Re:Which to learn first: python or ruby?

[remitaylor]

actually, to be truly fair, "Hello World" is *identical* in Ruby / Python


print "Hello World!" # Python
print "Hello World!" # Ruby


They both work and both satisfy "Hello World." Only different is that Ruby's print doesn't print a newline (puts does, as in your example).

Re:Which to learn first: python or ruby?

[DragonWriter]

I don't know python but if you can do something as succinct as

myList = []
10.times do |i|
            mList.push(i)
end
myList.each do |l|
            puts l
end

Its more succinct (and, to me at least, somewhat more intuitive) to replace this:

myList = []
10.times do |i|
      myList.push(i)
end

with this:

myList = (0..9).to_a

Re:Which to learn first: python or ruby?

[DragonWriter]

# python (normal loop, more straightforward)
for l in range(0, 10):
        print i # or sys.stdout.print("%d\n", l)

# and the ruby equivalent
for i in 0..9 # or: for i in 0...10
    puts i # or STDOUT.puts i
end

Re:Which to learn first: python or ruby?

[cabazorro]

Thanks for the examples.

I like your examples, yet
the do the very thing I no longer have to do with Ruby.

And that is.
Call c like operators like for, while etc.

I create objects and use the operators that the object provides.

So instead of calling for upper range lower range inside some list....bla bla bla.
(I have done Perl for many years now)

I just call the inherited operator ..

each

which is part of the Ruby Array Class ...check it out,

http://www.ruby-doc.org/core/classes/Array.html

it shows you the smogarboard of operators you automatically
inherit (more than 50) the moment you type something as simple as

myList = []

In Ruby EVERYTHING is an object.

Even the number 10 is an object.

So you can still do good'ol a-la c-style loops in Ruby, but
you shouldn't.

So I still want to learn Python, but mostly to understand it, not
for my every day scripting.

Cheers.

Re:Which to learn first: python or ruby?

[Anonymous Coward]

Q: what the hell do I want to learn this for?
A: lambda (and no, simply calling something vaguely lambda-ish 'lambda' does not count)

Re:Which to learn first: python or ruby?

[darrinallen]

i think i am going to learn python first, it will help with game programming

Uses of continuations in the real world

[MarkusQ]

Did someone here actually use callcc for something "real" in production code that could not be done someway else or was best implemented with callcc?

I don't have the code for either handy, but I've used it to implement an asynchronous discrete event simulations environment (loosely based on DEMOS) and a stateful-backtracking set up for intertwining syntax and semantics in a natural language system.

In the first case, a multi-threaded version has proved easier to maintain, and in the second case Moore's law caught up with me and it's now reasonable to just compute everything and not worry about the backtracking at all.

--MarkusQ

closet collectivist

[epine]

The hype was far greater than the language could deliver and the fanboi's made it worse as they cannot face the limitations of the language. Almost every serious book begins with a preface where the author praises his/her primary sources and then concedes "all the errors are my own".

Yet when random, excitable, anonymous forum-crawlers hype a software concept or language, if the hype doesn't come true, it's now the fault of the software. Isn't that an implicit form of collectivism? The entire Ruby community is smeared by hype generated from no particular quarter?

I've always had a soft spot for Perl 6. The engines of hype briefly chuffed into action, but then ... nothing ... as the Perl 6 initiative safely retreated into their hype-impervious cocoon of "maybe never". They must positively revel in their obscurity.

AI as a discipline has been forever tainted by some excitable fellows at MIT in the 1950s who fed the press what the press wanted to hear in the era of grandiosity leading into the space program.

No, actually, I simplified that. The whole discipline of AI has been forever tainted because millions of people *who ought to know better* refuse to forget what a couple of excitable guys once told the media back in the 1950s. The technological sophistication of the average journalist in the 1960s: "you mean like the Jetsons?" or "you mean like HAL?" In actual fact, improvements in computer chess was incremental and mostly linear. The correct answer in 1960 was "check back in about 40 years when the computers are a billion times faster and the software has become 100-fold more sophisticated". What actually happened: the journalist looked at the guy wearing dark-framed glasses, with a slipstick in his pocket protector, and said to himself "that's as close to sex as that guy will ever get, now who can I interview I can actually quote?" Our collective memory for accurate predictions: the 10ms time slice it takes our brain to write-off a social loser.

Hype itself is a short-term problem. The credence given to that hype (actually, the credence given to the obvious and unsurprising fact that the hype was hopelessly stupid) continues to cloud matters for decades afterward.

http://xkcd.com/386/

With hype, it's even worse: someone with no credibility whatsoever in the first place (a pimply "fanboi" in an excitable moment) once made unrealistic claims about the future greatness of a new and unproven programming language (these predictions always work out), but my god, let's not ever forget this incident, as it must necessarily continue to shape and constrain the debate forever after.

Ruby has managed to survive the hype. Even more impressive, Ruby has managed to survive the people who won't forget the original hype and its excesses (but are strangely reluctant to name the parties responsible).

It's quite the impressive feat for a language to thrive under such a burden. I don't know a whole lot about Ruby, but given those facts, deep down it must be pretty good.

Re:closet collectivist

[Foofoobar]

If you feed into the hype of your own product, as an engineer, you and your producn\t are equally to blame for it not meeting the standards when you could have so easily corrected any over statement. Zealous marketing is no excuse.

Mormon!

[Anonymous Coward]

Around here, the problem with Mormonism isn't the denomination, but the religion itself. Does this influence you?

Continuation-based web frameworks and Ruby

[DragonWriter]

But, we are getting off the topic, here, which is, of course Ruby.

To bring it back on topic, there is a Ruby continuation-based web application framework (Borges) that is (or began as) a port of Seaside 2 to Ruby.

I read a bit of this last night

[GWBasic]

On Friday, a bunch of people asked me about Ruby on Rails. I decided it was time to educate myself. After reading O'Reily's book that provided an overview of Rails, I felt that I should spend some time understanding the underlying language.

By pure coincidence, I bought this book. It's well-written. Last night, I couldn't put it down.

Ruby is a complex, but expressive language. I can't speak from real-world usage, but Ruby appears to provide many subtle variations in its syntax as a way of simplifying how the programmer expresses something. Overall, I'm highly impressed.

What I'm curious about is how flexible the language is. Will I be able to make an API that allows the programmer to use it with a convention that's not normal Ruby?

chunky bacon ... vs ... spam and eggs

[remitaylor]

Actually, hello world is *exactly* the same in ruby as it is in python

The only difference is what they use for "foo" and "bar"

ruby:
print "chunky bacon"

python:
print "spam and eggs"

( personally, i prefer cartoon foxes but ... when i don't have access to ruby, i use python because ... well ... THIS IS AN EX-PARROT!!! )

Here be Dragons

[remitaylor]

Depends on what you mean by "normal Ruby." Because Ruby is so flexible, it's a great language for writing domain-specific languages (DSLs). You could argue that these aren't "normal Ruby" because they're specific to certain libraries/gems, but ... they really are just Ruby.

Take this bit of Ruby code, from _why's poignant guide to ruby ...
class Dragon < Creature
    life 1340 # tough scales
    strength 451 # bristling veins
    charisma 1020 # toothy smile
    weapon 939 # fire breath
end

or checkout some Ruby code, using Markaby ... ( also written by _why )
html do
    head do
        title 'Ruby is Fun'
        link :rel => 'stylesheet', :type => 'text/css', :href => '/style.css'
    end

    body do
        p flash[:notice], :style => "color: green"
        self << @content_for_layout
    end
end


... is that conventional Ruby? Well ... it's plain-old Ruby ... it's just uses Ruby's meta-programming magic to make DSLs. Ofcourse, DSLs aren't always what you may want, but Ruby is really, really great at making them, so you can make your code better represent what you're really programming. Like the Dragon class above ... if you've got lots of creature classes in your application, isn't that a nice and clean example of some syntax you could use?

Ofcourse, cleverness isn't good simply for cleverness' sake. If a DSL really helps, or using some other Ruby "magic," then you should use it ... but these things shouldn't be used just because you can. It can lead to overly complicated code.

Re:Here be Dragons

[GWBasic]

As you can probably tell, I haven't made it to the part of the book that covers DSLs... But it looks like they are what I want.

Re:Here be Dragons

[chromatic]

You could argue that these aren't "normal Ruby" because they're specific to certain libraries/gems, but ... they really are just Ruby.

Then they're not really DSLs, are they?

Learning Ruby from Rails

[remitaylor]

As much as I agree with the parent that learning from DSLs / specific libraries can make it more difficult to learn Ruby, I disagree that Rails isn't a good way to learn Ruby.

Why? Because Rails gives you a *reason* to learn Ruby. How often do people learn a certain programming language "just cause"? While I love to learn new languages, I tend to learn them when I need to or when there's a great reason to ... for instance, to learn Rails!

I actually didn't learn Ruby by learning _all_ of Rails ... I learned Ruby by using Rails' ActiveRecord implementation.

With 1 line of code ( to set the database connection ), I found that I was more productive in an interactive Ruby console than I was using SQL or using many of the libraries that wrapped the databases I was using. That was my *reason* ( or rather, *excuse* ) to learn Ruby.

So ... while I agree that DSLs can lead to one learning a language slower, I think that they're a great *excuse* to learn the language, and the slowdown is worth it ( because you probably wouldn't have learned the language, otherwise! )

P.S. If you're curious about what I'm talking about, using Ruby / Rails' ActiveRecord to work with your database(s)? Let's say I wanna interact with a little sqlite database ... open up $irb and:

require 'activerecord'
ActiveRecord::Base.establish_connection :adapter => 'sqlite3', :database => 'mysites.db'

class User < ActiveRecord::Base; end
class Site < ActiveRecord::Base
    has_many :users
end

puts Site.count
puts Site.find_by_name('Slashdot').users.map &:email


Or, if I have Dr. Nic's Magic Models ...


require 'dr_nic_magic_models'
ActiveRecord::Base.establish_connection :adapter => 'sqlite3', :database => 'mysites.db'

# don't even have to define a classes ... (uses database tables and relations)

puts Site.count
puts Site.find_by_name('Slashdot').users.map &:email

Does Python have something equivalent? Sure, I'm sure Python's database ORM's make it just as easy (altho I doubt something as dynamic as Dr. Nic's Magic Models exists ... but maybe it does).

Re:Learning Ruby from Rails

[mikehoskins]

To each his own. We each have different learning styles. I have a more bottom-up approach, I guess. I also have an inquiring mind that wants to know "Why" and if what I do is repeatable.

Rails *is* the excuse people use to learn Ruby and it is what made it popular, staring in 2004. I will definitely pay it homage, here.

As uber cool as DSL's are, however, they do obscure the language. The irony of Rails is that it's so close to natural language (English) at times! :-) That makes it difficult to come from say Perl/CGI or PHP to RoR. The shiny new DSL looks beautiful, but how do I really program in it on my own and how do I know what to do, next?

If they are like me, most if not all newbs (to Ruby but not to programming) who come to Ruby see this and are puzzled (from your example):
    require 'activerecord'
    ActiveRecord::Base.establish_connection :adapter => 'sqlite3', :database => 'mysites.db'

    class User ActiveRecord::Base; end
    class Site ActiveRecord::Base
            has_many :users
    end

    puts Site.count
    puts Site.find_by_name('Slashdot').users.map &:email

Now, they ask themselves, if they are thinking like I did, "Where did I declare users?"

The answer is, "You didn't...." Rails did.... Why? The has_many method inside the Site class, which inherited from ActiveRecord::Base passed in a symbol called :users as a parameter. How do you explain this to a first timer?

Then, you string together method calls in "Site.find_by_name('Slashdot').users.map &:email".... Good code, but a newb sits there scratching his head asking, "Why?" Then, the newb asks again where they declared "users" and all that other stuff. While we're at it, what's this "&:email"?

A good teaching tool/training guide give some basics, lets you work in some rails, and spoon feeds some more Ruby at each point, making the Ruby clear. I haven't seen this for RoR, yet. The idea of "DSL's" (not just "frameworks") needs to be explored early in RoR.

Coming to Java/PHP/Perl, there is less "Why" but more groans (and, unfortunately, far more code). Their code is far more explicit. Rails is very implicit and sugary. This is excellent for those who know Ruby already, since they can be so productive with so few lines of code. An expert can also take the ever so malleable Ruby and craft a work of art.

There's nothing wrong in your code (you even include the sqlite connection string when most people just use the config.db) and there are so many elegant features in there that make coding so short and readable -- to the initiated. This just makes newbs ask "Why" at several points along the way, which needs to be explained.

Re:Learning Ruby from Rails

[nuzak]

> Does Python have something equivalent?

Take a look at SQLAlchemy. You'll cry at how primitive ActiveRecord is by comparison. If you really need to get your ActiveRecord pattern on (it's the name of a pattern, not a product), there's always the much less powerful, but much simpler and still popular SQLObject.

Then there's Django's ORM, GeniuSQL, Storm, Axiom...

Re:Learning Ruby from Rails

[remitaylor]

I'm with you 100%, except, I think the parts where the newbs say "wtf? how does this work?" is the important part, where they DO get to learn how Ruby works.

But you're right ... a lot of the answers that newbs find to their "why?" questions won't actually teach them Ruby, it'll teach them about Rails magic, instead.

However ... I probably wouldn't know any of the meta-programming magic that I *love* about Ruby if it weren't for my learning cool DSLs. Take something like Builder, where you get code like:

builder = Builder::XmlMarkup.new
xml = builder.person { |b| b.name("Jim"); b.phone("555-1234") }
xml #=> <person><name>Jim</name><phone>555-1234</phone></person>

You, the Ruby newb, say "woah ... wtf is going on there ..." and you get to learn about method_missing, which you otherwise might have missed.

When you answer all of your "why" questions about the Rails code above, you learn about to_proc and metaclasses and ... all kinds of great Ruby magic.

But ... then again ... as I'm typing this, I realize that's a LOT of "magic" and it can easily drown a new programmer, putting them in *way* over their head and making it harder to learn Ruby.

In the end, I think you're right, but the fact is - lots of people learn Ruby from Rails. If I could recommend anything, it would be to find a small project that Ruby can help you with *before* digging into Rails, so you feel somewhat comfortable with Ruby before being confused by Rails' magic.

If you're going to be using Ruby on the web, *learn eruby first!!!!* Use Ruby just like you use PHP, so you get to know Ruby before Rails.

If you're going to be using Ruby for sysadmin stuff, *learn irb first!!!!* Use Ruby in the interactive console, just like you might use BASH, so you get to know Ruby before Rails.

( etc etc etc )

Re:Learning Ruby from Rails

[remitaylor]

If you really need to get your ActiveRecord pattern on (it's the name of a pattern, not a product) ... We know what ActiveRecord is ;)

Thanks for the reply - SQLAlchemy looks great, tho it kindof "feels" like talking to a database, rather than objects, with "fetching" and "executing." I like ActiveRecord because you could swap out the backend of your objects, re-implement the API, and everything would still feel right. Even when I use plain text files as my backend, I try to implement an API compatible with ActiveRecord so, if I move to a database, it'll be easier to refactor.

Ruby's got tons of ORMs, as well. I knew there were lots of great Python ones out there, I just didn't know them.

These make for a sweet excuse to play with Python :D

Re:Learning Ruby from Rails

[nuzak]

When you've got mappers configured right -- which is undeniably cumbersome, but you get a lot of power from it -- SA really is as orthogonal as AR or SQLObject. More, really, since you don't have to use special datatypes or declarations for your fields (they're in the mapper).

The only difference is that it isn't set up to autocommit by default, so you do have to manually flush the session, but even that could be done with a simple wrapper, be it WSGI middleware or a context manager or what have you.

Storm's probably worth looking at too. It's also a mapper pattern ORM, but it has a claim to fame of supporting multiple databases simultaneously. I don't believe it has the same kind of sophistication that SA has in its low-level DB access though.

Re:Learning Ruby from Rails

[mikehoskins]

Yep, it is magic and very, very cool magic. There is nothing wrong with the magic, itself, just the presentation in training references.

I think that manuals should toggle between background and wizardry, exactly as we have mentioned.

I agree about eRuby -> RoR and IRB -> sysadmin/"Plain Jane Ruby" (how I'm learning it).

Then, the depth of what you are doing and the way Ruby and the framework are interacting give you an enlightenment that few Ruby and few RoR newbies and intermediates can appreciate.

I started trying RoR and went ahead and learned it from the sysadmin side, instead. Now, when I switch back, RoR should be really easy.

Ruby is

[Martin Spamer]

When will /. grok the fact that is well know in parser/grammar circles, that Ruby is a language with a problem so big it can only be considered fundamentally Borked. Slashdot used to be a place where most people where on the ball and a crude attempt like this to gain traction by leeching the good standing off K&R would have been spotted and binned.

This Ruby Grammar tree shows part of the problem, that god like Primary token in the middle. Ruby requires an arbitrary look-ahead parser, an LL(k) parser which are notoriously problematic. LL(k) parsers are inefficient, difficult to implement and result in ambiguous semantics. The result is that the Ruby grammar requires the token analyser and parser to be tightly coupled, a code smell in most programs. Token lexical analysis is dependent on syntactic context and syntactic context is dependent on semantic information from dynamicaly typed local variables. This is lethal for parsers.

It is not possible to separate the lexical grammar from the language grammar, nor is it possible to properly describe the language grammar in a rigorous way. What defines a good language is that its semantics are well defined and consistent without reference to an underlying mechanisms, The fact that Ruby needs a LL(k) makes the semantics ambiguity, the parser implementation must make arbitratory assumptions about the semantics.

The Ruby syntax cannot be defined with by rigorous context-free grammar, it is ambiguous. This is lethal in Parsers, because two different parser implementations can attach different semantics to the same source code. YES, that's right a Ruby program can run differently on two platforms, even if they have correctly implemented parsers.

This cannot be fixed because this big problem with Ruby is the very thing that makes it attractive, the syntactic flexibility. That flexibility cannot be decoupled from semantic ambiguity, making it error prone to write and more importantly read.

Wirth said of good languages, a language is not so much characterized by what it allows to program, but more so by what it prevents from being expressed.
If you want a dynamic typed languages there are better choices with rigourous grammars.

And Businesses Should Care Because ... ??????

[remitaylor]

WOW. You go, Mr. Computer Science.

Now go tell that to the managers of programming teams that have dramatically increased their output since moving to Ruby.

Get a job!

I did a small project in python

[Anonymous Coward]

I forgot a space. ONE SPACE. the thing crashed and I got fired. The wierd thing is that I thought the space was there, but turned out the space where the space was supposed to be looked like a space so I thought the space was there but instead of the space, there was just an empty, uh, space. Ruby may be crap but you won't have this space or no space issue.

Re:Huh? Is this the "new" English?

[Anonymous Coward]

home based business But why did you say that?

Wirth was Wrong

[bill_mcgonigle]

Wirth said of good languages, a language is not so much characterized by what it allows to program, but more so by what it prevents from being expressed.

Wirth was wrong. At least for common definitions of 'good'. I dumped pascal for perl in the 90's, and the only people I know of who still actually use it are maintaining old Delphi. Yeah, there are some others I'm sure, but the practitioners of the art have decided Pascal is no longer useful.

Bill says, "a good language encourages a strong community, so your language gets ported and supported and people write libraries for it."

You do make a good point - a standard definition of Ruby behavior in ambiguous corner cases would be good to have. I suppose, as it is now, the Matz compiler is the correct behaviour. Strange - it never occurred to me that there might have been other perl compilers out there I should worry about. Back in the day I spent all kinds of hellish time trying to resolve compatibility between Pascal implementations (really their extensions that were made to make them more useful).