Slashdot Mirror
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.
"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.
Why do computer software worth less than paper-printed books? Last I check, software codes do not destroy rain forest like books.
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.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
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
No, but Grammar Nazis will.
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).
I just don't trust anything that bleeds for five days and doesn't die.
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.
Your sig(k) has been stolen. There is a puff of smoke!
why the lucky stiff is one token. Try enclosing it in quotes and recompiling.
Don't blame me, I voted for Baltar.
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. :-)
...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.
The Army reading list
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.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
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.
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.)
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.
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.
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.
> 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.
The Army reading list
Very informative review . . . Off to Amazon!
It can also be "free" (of marginal financial cost) if you subscribe to Safari.
Is it me, or is there something missing right before "why the lucky stiff..." in the submission?
Sounds like they should have listed Arlo Guthrie as co-author.
I bet mods don't get the reference and mark me down.
Infuriate left and right
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.
Don't thank God, thank a doctor!
Thank you!
I have sympathy for your loss of mod points due to others ignorance.
This is my sig. There are many like it but this one is mine.
Yeah, I feel really sorry for Ruby
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.
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.
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?
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
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?
get RAD with Java.
These kids. In my day we used to get funky with Fortran and we liked it.
If the difference is so important and so simple, why didn't you say what the difference is?
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I've done some, but it looks like C.
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.
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
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.
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.
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.
Don't thank God, thank a doctor!
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.
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 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.
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.
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.
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.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
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.
You're right, I did mean Ruby 1.9 vs Ruby 1.8. Sorry about that.
Don't thank God, thank a doctor!
> 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.
The Army reading list
Is fanbo(i|y) like the new N-word or something?
It's a very dark ride.
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?
No, I will not work for your startup
Actually, hello world is *exactly* the same in ruby as it is in python
... when i don't have access to ruby, i use python because ... well ... THIS IS AN EX-PARROT!!! )
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
Ah too bad you posted as AC, now you'll never get the street cred.
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.
...
... ( also written by _why ) :rel => 'stylesheet', :type => 'text/css', :href => '/style.css'
:style => "color: green"
... 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?
... but these things shouldn't be used just because you can. It can lead to overly complicated code.
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
html do
head do
title 'Ruby is Fun'
link
end
body do
p flash[:notice],
self << @content_for_layout
end
end
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
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.
... for instance, to learn Rails!
... I learned Ruby by using Rails' ActiveRecord implementation.
... 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! )
... open up $irb and:
:adapter => 'sqlite3', :database => 'mysites.db'
:users
...
:adapter => 'sqlite3', :database => 'mysites.db'
... (uses database tables and relations)
... but maybe it does).
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
I actually didn't learn Ruby by learning _all_ of Rails
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
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
require 'activerecord'
ActiveRecord::Base.establish_connection
class User < ActiveRecord::Base; end
class Site < ActiveRecord::Base
has_many
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
# don't even have to define a classes
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
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.
Kathleen Sebelius? Gross.
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!
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.
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.
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!
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.
I have a couple RUBY books at home. These will be great additions to my LIBRARY
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).
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.
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!
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".
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.
... and full of magic unicorn fairy dust powers which suddenly turn teams unable to write decent code into gods among men.
how to invest, a novice's guide
It's often easier to reuse code designed to be reused. You're dangerously close to tautology here.
... 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.
how to invest, a novice's guide
Things has changed... now is web 2.0 rich applications... a way new world
CPM Group LTD http://www.cpm-group.co.uk/
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).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.