Slashdot Mirror
Three Books About the Ruby Programming Language
DJSpray writes "I've written a review of three books about the Ruby programming language, available on my weblog here. The three books are Yukihiro Matsumoto's Ruby in a Nutshell from O'Reilly, Hal Fulton's The Ruby Way (Sams), and Programming Ruby: The Pragmatic Programmer's Guide by Dave Thomas and Andrew Hunt (Addison-Wesley). Note that the third book is available online here for those who prefer that sort of thing. Executive summary: while I have found several of the other O'Reilly Nutshell series books to be excellent, this one is riddled with errors, confusing writing, and omissions, and does not live up to O'Reilly's usual standards. Fulton's book is filled with good cookbook examples and well-written explanatory material, as well as solid tutorial examples, but it is not structured as a reference. The Pragmatic Programmer's book works well as a reference and covers language features in increasing depth, but with fewer examples. Ruby beginners may find that the latter two books actually complement each other nicely, while I can't recommend this edition of the Nutshell book at all."
or rather where can it be placed. python and perl are fighting so hard for the place, and if you step out to real compiled languages, the dominance of c, c++ and java cannot be shaken. Languages like LISP and cobol and fortran have been mercilessly killed, but the remnant diehards will still insist its alive in some remote forest. So where does Ruby fit in... what is it anyway?
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I've always read that many people consider Ruby to be an excellent programming language.
I wonder, then, why it doesn't seem to have that many developers using it? Is it only because it is new?
Karma: Chevy Kavalierma.
I like what I've seen of Ruby. There's just one snag: no UNICODE support except via libraries.
I already know Perl. I'd like to learn something cleaner, and Ruby looks like exactly what I'm looking for. However, I'm not prepared to put in effort learning yet another language that doesn't have native multilingual text support.
Doing everything via library calls to get UNICODE support is an ugly hack... and like I say, I know Perl, so my ugly hack requirements are already adequately met.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
note: these books are all several years old; nothing new here
However, I think the Practical Programmers' book is much better than you give it credit for. It does a credible job of introducing an experienced programmer to the Ruby Language (although it's really not for those who are not familiar with an Object-Oriented Language). I have found that that is my standard Ruby resource.
Incidentally, I only picked up Ruby a few months ago, and have found it to be a great language. Unfortunately, some of the support is not yet there. I've ended up doing my latest project in Java because I don't want to lock myself into a language that will not support high-end scalability features.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
A 4th book on Ruby that I kind of like is _Ruby Developer's Guide_ by Robert Feldt, Lyle Johnson, Michael Neumann (Editor), Lyle Johnson, Jonothon Ortiz.
This has a series of chapters on more applied topics that would be good for the Slashdot programmer audience: DBI, XML, SOAP, Performace, Parsers, etc... The book is a little wordy, but the topics covered are very useful and it imparts a lot of useful information for people who don't want to relearn basic syntax.
I use it for all my basic scripting needs though, and like I said, I really love it. It's OO makes a lot of sense, the block-passing stuff is awesome, and you can do perl-esque stuff like easy regular expressions.
Basically I was looking for a good OO language, and although Python is okay, and I like the whitespace blocks, the language doesn't "feel" right to me. Also it seems to be changing every now and then so I'll probably wait until a few more evolutions before I look at it again.
I have the O'reilly book and yes it does read like it was translated from Japanese but I haven't found any factual errors. I use it regularly for reference.. I don't think I'd avoid it like the reviewer does.
The Pragmatic Programmer book is probably the best one, I have the paper copy and I'm currently trying to reformat the HTML version to fit on my Zaurus.. there is an XML version but it's really weird. For instance it uses
between paragraphs rather than AROUND them.........
Anyway if anybody out there is interested in a good OO language and is getting impatient waiting for Perl 6, check out Ruby.. I'd love for it to mature some more and move in from the fringes................
I have to make a couple of comments, some of which have been made elsewhere, some of which have not.
Where do you get off saying that Lisp and Fortran are dead? Are you trying to start some flamewar? Maybe they're not used routinely by the majority of programmers, but they're very important in the fields they do get used in--which may be more broad than you think.
And that doesn't mean to say that I'm "insisting they're alive in some remote forest." Unless you consider numerical computing remote, of course. Lisp is enjoying a renaissance of sorts, I believe, as people are beginning to understand how flexible it is. Recent discussions of aspect-oriented programming have many realizing that Lisp effortlessly incorporates every "new" programming paradigm that comes about, and often has had it for some time with a different name.
In any event, language utility shouldn't be evaluated entirely by how many people are using it. Libraries and user bases help, of course, but every language starts somewhere, and that somewhere is with people who love the language for itself.
I have no apologies for COBOL, on the other hand.
About your question: where does Ruby fit in?
As another poster noted, Ruby suffers a bit from its late introduction into the scripting trinity. Perl is the most established, but is ugly in many ways (and I say that as a routine Perl writer). People who got sick of Perl went to Python, but a bit too soon in many peoples' opinion.
Somtimes I think that if Ruby had been released at the same time as Python, there probably wouldn't be a Python right now. I tend to feel it's everything that Python tried to be but wasn't quite.
Ruby gets it right. Now, the question is, will it be able to catch up? I don't know, but I hope so. It will all depend on new programmers and how they are taught. My guess is, at best, those who are new to programming will take a look at the three languages, and those who admire Perl's resource base will use that, those who admire Ruby's cleanliness will use that, and Python will either get shafted or draw adherents of those who want a little of what Perl and Ruby have to offer.
So what's my answer to your question? That it doesn't do anything different from Perl or Python, really. But you could turn that around and say that Perl doesn't do anything different from what Python or Ruby does, or that Python doesn't do anything different from what Perl and Ruby does.
It's really a matter of syntactical preference and resource base. And with scripting languages, you have the two issues opposed on different ends of the continuum, with Perl being the ugliest but the most resourced, Ruby being the cleanest but the least resourced, and Python being somewhere in between.
It's all a matter of where you fall in that classic programmer's dilemma: how much do I give up old and ugly but established for new and clean but unestablished?
Let's be thankful that we have the choice with scripting languages--there's really room for everyone. I don't honestly think that's true of lower-level languages.
Does the latest FORTRAN standard still allow you to assign to constants (pass "3" to a call-by-value parameter and you risk getting that number redefined!)? I'd think that 50 years is plenty of time to fix that particular design bug, but you never know!
But doesnt that make my language LESS faster than C,
:-)
The standard Pythonista answer is that in most programs, 80% of the time is spend in 20% of the code. Profiling and careful optimization usually gets the performance hit down to the magic phrase "less than noticable".
The other half of the Pythonista answer is that working at a very-high level makes rapid application development possible. Your programs end up well factored because it's easier to rearchitect things.
Kent Beck calls it "First Make it Work, Then Make it Right, Then Make it Fast" and Don Knuth says "Premature Optimization if the root of all evil in programming". I think in the long run, C will end up occupying the same niche Assembler once held: You use it to extract extra performance when you need it, otherwise you use the higher level language.
(Caveat: I recently read the Debugging chapter in Python in a Nutshell. Most of the arguments are paraphrased from Alex Martelli's excellent writing. I'm simply not this intelligent usually...
My father is a blogger.
I respect people's love of Python.
For me, though, there's a distinction between whitespace and @ and $ operators.
It's at a different level of cognitive problem.
"@" and "$" are each just another symbol. Maybe weird, but not that weird relative to other symbols that get used in progamming languages (e.g., "&", "&&", "|", "::", etc.).
Whitespace, on the other hand, has a different meaning. It's empty space--it doesn't have much meaning in an absolute sense. Python advocates point out that we all put spaces in to denote blocks of code, but really, it's a very flexible thing--very fuzzy, so to speak, and not really integral to the meaning of the code in an absolute sense. The space is more akin to nonverbal human language--it helps, but isn't necessary.
The whitespace issue is comparable to the parenthesis issue with Lisp: something that's such a mindfuck that you can't handle it easily. I agree that weird symbols are weird, but some symbols just induce insanity.
Just picked it up at Borders a couple weeks ago and I'm only a few chapters in, but so far it's very well written and succeeds in anticipating the programmer's questions. The book claims it can't teach you Ruby, but they underestimate themselves. Granted Ruby's "just another language" for me, so if you're a new programmer this isn't your book, but if you're an experienced programmer this book does a great job.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Matz has made it clear that the design of Ruby is based first and foremost on making it easier for him to do his own work, which he has stated is primarily in the Japanese Unix encoding EUC-JP. He says "EUC-JP is good enough for me" and "Ruby's internationalization strategy is whatever doesn't interfere with my Japanese work".
.Net or Java Strings might be a great tool if the performance could be made acceptible.)
Well, if EUC-JP good enough for him, then he clearly doesn't build globalized apps. It's the Japanese equivalent of a US language designer saying, "I want my language to be optimized for 7-bit ASCII, which is good enough for me." (Which, of course, is the history of many old programming languages from the days of standalone, unconnected computing, but he still takes that approach today in the era of the WORLDWIDE Web.)
His provincial attitude about Unicode tells me that though Ruby's design is full of great ideas and he is a gifted language designer, ultimately Ruby can't be taken seriously as a production platform if you have any international ambition at all.
(On the other hand, something like a Ruby.Net or JRuby that used
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."