Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ruby In Practice

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Books 104

littleidea writes "Ruby In Practice is like a sampler platter that picks up where The Ruby Way leaves off. Depending on your tastes each of the different offerings are delicious, but sometimes leave you wishing you had a whole order of just that. Then again, if you eat the whole thing, chances are you won't be hungry." Keep reading for the rest of Andrew's review.I really jumped headfirst into Ruby and the Ruby ecosystem when I started working on Puppet around Fall 2007. I had spent years writing code in compiled imperative and object oriented languages and just dabbled with interpreted languages before that. I've met Jeremy and several of the authors of Ruby In Practice at Ruby conferences since then.

I had a particularly hard time rating this book. If you have just learned the Ruby basics and you need to hook up your jabber server to a message queue that will spawn workers that interact with RESTful web services exposing indexed logs to twitter by tomorrow, then this book is a 10. If you are a hard core Rubyist plugged into the Ruby ecosystem, and 'Ruby In Practice' is what you do all the time, then this book is probably a 6, useful and enjoyable but hard to recommend. I'm somewhere in the middle, so I'm giving the book an 8.

The books starts out with the premise that the reader can read Ruby code. I wouldn't call the style 'code heavy' but this book is definitely 'code ample'. If you haven't been through the Pickaxe or at least a Ruby primer of some sort, be prepared to spend some time head scratching and googling before all the code syntax makes sense. That being said, you don't need to understand the subtleties of 'yield' or 'inject' to understand the examples and the book does a reasonably good job of walking through and explaining them. The exceptions to that are some of the examples involving Rails make the assumption that the reader is familiar with those idioms, which is probably fair statistically speaking and those bits can be filled in rather quickly with one of the many books on the topic or your search engine of choice.

The book credits a number of Rubyists with contributions for each of the sections. This makes for some noticeable variation in the stylistic presentation from topic to topic. As I alluded to earlier, each of the sections is more of a taste of a topic than a full exploration, but there are also references to the resources one would need to pursue each topic more fully.

The book starts out with chapter on 'Why Ruby' followed by an attempt to convert readers to become 'Test Infected', then the real Ruby fun begins in chapter 3. The first example is scaling images, stuffing them in Amazon S3 and printing the link to Twitter in 30 something lines of code. If you don't understand Ruby syntax and passing blocks, you will probably be a little lost here, but the good news is: if you take the time to sort out these first examples the rest of the code in the book should be relatively accessible. The application domain will vary throughout the book, but the level required to understand the ideas expressed in the code remains relatively constant. (which one might argue is one of the strengths of Ruby as well)

By this point, the rest of the book basically follows this pattern, discussion on a technology topic, gem install, code examples, links to more resources. I'm not going to list all the topics, though I alluded to many of them when I discussed the rating. (Here's the TOC to give you some idea.) The book definitely covers ground.

There is some really choice stuff in there and I definitely learned things, but there are a few things that are presented through Ruby colored glasses (as one would probably expect). The one that will always stick out is 'Say goodbye to dependency hell!' in reference to setting up a gem repository and using RubyGems (gems is Ruby's network library/package manager, similar to CPAN for perl or apt for Debian Linux) . I had a little chuckle and eye roll at that one. (Sorry Jeremy)

One quick note, and this is a comment about the Ruby ecosystem as much as anything, Ruby libraries change relatively quickly. On the one hand, gems are mostly up to date and tracking new versions of whatever they integrate with, on the other, this can sometimes break backwards compatibility. I didn't run every line of code in the book, but I played around with a good portion of it. There were a few gem updates which were not compatible with the code in the book. The twitter gem in particular had non-backward compatible changes to authentication (to support OAuth). I was able to get the example working with a few minutes of Google and looking at the code, but that might have taken longer and been frustrating if I didn't have a Ruby background. Ruby In Practice provides enough context and information that you can probably find the maintainer or community for a project without much trouble if you really get stuck.

I would strongly recommend this book to someone who has come to Ruby through Rails and is ready to learn more about what is possible with the language or someone who is coming from another language background with experience and perspective on things like stomp servers or Lucene and who's interest in dynamic languages has been piqued (if you have a background in any OO language, a simple primer is probably enough to make this book accessible. Also, you should remember irb, the interactive ruby interpreter, is your friend.) Anyone in either of those groups will get working examples and resources that could realistically be used in useful applications right away.

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

cancel ×

104 comments

Sorry! There are no comments related to the filter you selected.

Ruby (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#30573986)

Did they get rid of that whitespace crap yet?

Re:Ruby (1)

phallstrom (69697) | more than 4 years ago | (#30574224)

That would be Python, not Ruby... and since I have to wait for Slashdot, the book is good. So is the Well Grounded Rubyist (also by Manning).

Re:Ruby (0)

Anonymous Coward | more than 4 years ago | (#30574542)

Why mess with Ruby at all? Just use a real language such as VisualBasic.NET.

Re:Ruby (1)

LOLLinux (1682094) | more than 4 years ago | (#30574590)

Or QBasic.

Too many words (-1)

Anonymous Coward | more than 4 years ago | (#30574006)

And that dude's hat is scaring me.

But is it (poignant)? (3, Interesting)

Picass0 (147474) | more than 4 years ago | (#30574020)

Still my favorite:
why's (poignant) guide to ruby http://mislav.uniqpath.com/poignant-guide/book/ [uniqpath.com]

Re:But is it (poignant)? (0)

Anonymous Coward | more than 4 years ago | (#30574072)

TFS isn't even as good as something from PizzaAnalogyGuy.

Re:But is it (poignant)? (0)

Anonymous Coward | more than 4 years ago | (#30576112)

More like whiney's poignant guide.

Awesome (1)

dilemmachine (1708584) | more than 4 years ago | (#30574048)

I highly recommend this book. There are so many amazing things one can do with ruby, and knowing them can save a lot of time and make the code easier to read too.

Re:Awesome (0)

Anonymous Coward | more than 4 years ago | (#30574104)

And you didn't write it yourself .. mod this [slashdot.org] up ...

Re:Awesome (0, Troll)

Anonymous Coward | more than 4 years ago | (#30574164)

There are so many amazing things one can do with ruby,

Yeah like making a server run like a 386 due to bloaty, slow code like Ruby on Rails.

Re:Awesome (0)

Anonymous Coward | more than 4 years ago | (#30574270)

who cares if it runs like shit, we only had to write 2 lines of code :)

Re:Awesome (0)

Anonymous Coward | more than 4 years ago | (#30576220)

Yeah, and had they worked, it would have been great.

Re:Awesome (1)

bberens (965711) | more than 4 years ago | (#30574834)

The same was true for Java in its early days and now it's quite fast. I'm no Ruby fan, but I am confident that it will get over its speed issues in time. It's definitely an up-and-comer. Personally I'm pulling for Groovy and GRAILS, but I don't think it'll ever get past being a knockoff.

Re:Awesome (1)

e2d2 (115622) | more than 4 years ago | (#30575132)

I'll go back even further. PERL was once touted as the newness but in the web world it had issues scaling. Most things had issues scaling back then so it wasn't a surprise. But look now, one would be hard pressed to say PERL is slow. Now that eventually went to PHP, and then to Ruby, and Python. The simple fact is it's more about handling requests, ie writing server software like fastcgi or apache mod_x modules, then the actual language implementation itself. Ruby is at this spot right now. The problem is this isn't the "good old days", like PERL in it's golden age, and there are good alternatives to Ruby so it may be losing some steam. But just like PERL it's not the language itself, but the platform it runs on ("Rails is a Ghetto").

Groovy/Griffon/Grails (1)

Foofoobar (318279) | more than 4 years ago | (#30575388)

Gotta second that. I liked Ruby but hated the speed and scalability issues. Beginning to loathe PHP because of its inconsistencies and inability to advance the language.

Groovy on the other hand has a community that is advancing (without much recognition) a rich platform with Grails (for web apps) and Griffon (for swing apps). It's amazingly fast, simple and easy and integrates with traditional Java without any additional configuration needs. This will definitely kill JRuby for the most part.

Re:Groovy/Griffon/Grails (1)

mcvos (645701) | more than 4 years ago | (#30581158)

I don't know. I like Groovy a lot. It's basically Java but flexible and with most of the cool Rubyisms added in, but it doesn't quite have that Ruby feel to me. I think I like Ruby's metaprogramming more.

Or maybe it's not Groovy, but Grails. I expected it to be a Rails rip-off, but it turns out Grails is built on top of Spring, which means I have to deal with all that Spring configuration below the surface. I'm not the biggest fan of Rails, but Rails definitely looks a lot cleaner than Grails. And Ruby is still my favourite syntax. Too bad it's so slow. I'm very much looking forward to Rails 2, which will hopefully be a lot faster, support threads properly, and maybe even fix that last metaprogramming hole.

Or maybe with every new language I learn, I pine for the previous language I worked in. No, that's not true. I didn't miss Java when I switched to Ruby. Maybe Ruby feels better because it was such a revelation after Java, whereas Groovy is just more of the same after Ruby and Java.

Re:Groovy/Griffon/Grails (1)

mgkimsal2 (200677) | more than 4 years ago | (#30584540)

We at http://groovymag.com/ [groovymag.com] are trying to help with the recognition bit, although it does at times feel a bit like an uphill battle ;)

Re:Groovy/Griffon/Grails (1)

Foofoobar (318279) | more than 4 years ago | (#30598794)

Yeah you guys rule. Do a couple more articles on Griffon. :)

Re:Awesome (0)

Anonymous Coward | more than 4 years ago | (#30574848)

For the record, ruby 1.9 is on par with python, speed wise.

yawn (0)

Anonymous Coward | more than 4 years ago | (#30574184)

[ ] newsworthy

PIZZA ANALOGY (0)

Anonymous Coward | more than 4 years ago | (#30574252)

What a great opportunity for a pizza analogy!

Anybody got one?

Re:PIZZA ANALOGY (0)

Anonymous Coward | more than 4 years ago | (#30574408)

Ruby is like ordering a pepperoni pizza only to find out that the pizza boy took a big steaming dump all over it before he delivered it.

Re:PIZZA ANALOGY (0)

Anonymous Coward | more than 4 years ago | (#30574460)

+1 ANAL

Re:PIZZA ANALOGY (0)

Anonymous Coward | more than 4 years ago | (#30574674)

I don't go for any of that "pizza boy took a big steaming dump" shit.

Girl turds FTW!

Frightening title (-1, Troll)

bluefoxlucid (723572) | more than 4 years ago | (#30574276)

"Ruby in Practice" makes me imagine a book filled with code samples of a modified, human-readable version of Brainfuck.

Ringing Endorsement (5, Insightful)

daceaser (239083) | more than 4 years ago | (#30574338)

"[If] you need to hook up your jabber server to a message queue that will spawn workers that interact with RESTful web services exposing indexed logs to twitter by tomorrow, then this book is a 10."

I think you have comprehensively explained why I don't want to read this book.

Thank you sir, for your service to humanity!

Re:Ringing Endorsement (1)

Mr. Bad Example (31092) | more than 4 years ago | (#30574814)

> message queue that will spawn workers

You have no idea of my level of disappointment when I realized that the above didn't say "message queue that will spawn hookers".

Re:Ringing Endorsement (0)

Anonymous Coward | more than 4 years ago | (#30581066)

Well screw ruby, I will make a message queue that will spawn hookers and blackjack. In fact, screw the blackjack!

Re:Ringing Endorsement (0)

Anonymous Coward | more than 4 years ago | (#30580556)

This is one of the things in the book I had to do, so I give it a 10 for clear instructions and simplicity.

Yeah, I remember ... (3, Funny)

neonprimetime (528653) | more than 4 years ago | (#30574346)

... Rudy [imdb.com] , he always practiced real hard, a real die hard ... but I don't recall if he ever got to play in any actual games.

To summarize: (0)

Anonymous Coward | more than 4 years ago | (#30574382)

"Depending on your tastes each of the different offerings are delicious, but sometimes leave you wishing you had a whole order of just that. Then again, if you eat the whole thing, chances are you won't be hungry. You need to hook up your jabber server to a message queue that will spawn workers that interact with RESTful web services exposing indexed logs to twitter!! That being said, you don't need to understand the subtleties of 'yield' or 'inject' to understand Rails!"

Why buy it? (1)

vlm (69642) | more than 4 years ago | (#30574464)

There were a few gem updates which were not compatible with the code in the book. The twitter gem in particular had non-backward compatible changes to authentication (to support OAuth). I was able to get the example working with a few minutes of Google

Time for my usual Slashdot book review rant. Why buy this book, if the review states its mostly a list of inspirational google searches?

MOST technical books are little more than edited concatenated google searches... However it is possible to write a technical book that is better than that, or at least different from that. For example, the "little schemer" series is certainly unique.

So, why buy this book?

'nuff said (1)

Jawn98685 (687784) | more than 4 years ago | (#30574494)

...Ruby libraries change relatively quickly...

[shakes head]

More importantly... (0, Troll)

LOLLinux (1682094) | more than 4 years ago | (#30574520)

have they fixed the problem of Ruby being slow as shit?

Re:More importantly... (3, Funny)

gregarican (694358) | more than 4 years ago | (#30574608)

Sure! As a matter of fact I'm reply to your comment through my Ruby command-line...HTTP ERROR 408 - REQUEST TIMEOUT#$(84@...NO CARRIER

Re:More importantly... (2, Informative)

steveb3210 (962811) | more than 4 years ago | (#30574638)

Ruby 1.9 moved to a VM architecture and with a sizable performance boost. unfortunately they also managed to break half the existing gems out there with changes to the language; slowly but surely things are moving in the right direction.

Re:More importantly... (1)

binary paladin (684759) | more than 4 years ago | (#30574808)

I can't believe how long the gem transition is taking either. That's been the most frustrating part of it. (I'm running 1.9 right now for just about everything though.) You'd think by the time 1.9.1 was out people would have been converting (and in many cases it's just not that hard).

Re:More importantly... (1)

steveb3210 (962811) | more than 4 years ago | (#30574860)

On top of it the patch levels for the 1.9 version break as things move along.. For example, 1.9.1p243 came along and decided that upon unlinking a file description we should close it first. This was not the previous behavior and broke Rack. I really hope the ruby community pulls together and we get to where we were 2 years ago on the upgraded platform.

Re:More importantly... (1)

binary paladin (684759) | more than 4 years ago | (#30574966)

I hope so. I enjoy the language immensely. I liked Python, but I LOVE Ruby and like doing my web dev there. I don't even use Rails either.

Re:More importantly... (1)

gregarican (694358) | more than 4 years ago | (#30574990)

That's why most of my programs are still at the Ruby 1.8.x revision level. A lot of admin scripts and things that I can afford to take performance hits since they automatically run after hours. My Rails implementation has relatively low user load as well. If I had to upgrade to 1.9 to get that performance boost I've seen a good amount of areas in my code that would be borked. Backwards compatibility is a concern when that times comes. It's one thing deprecating and gracefully warning you. Some of my code testing proved quite _interesting_.

Re:More importantly... (0)

Anonymous Coward | more than 4 years ago | (#30575080)

The way gems with native libraries are implemented has been (and still is in 1.9) a major weakness in Ruby. The module API exposes far too much of the inner workings of Ruby. There is a growing movement to change these gems to use FFI instead of wrapping the native API in a Ruby C module. This allows the gem to be pure ruby and call out to the native library, which in turn would make the gem much more portable, not only between ruby version, but also between different Ruby implementations.

Re:More importantly... (1)

jellomizer (103300) | more than 4 years ago | (#30574750)

Compared to what?

C,C++, Or any lanauge that needs to be compiled to an optimized for the platform binary form to run, at the expense it only runs on type of platform.
Java, Dot Net, or any language that compiles to a byte code with is optimized for its function and memory can be preallocated.
Python, Perl or other Scripting languages where there is little optimization that can go on as the code is running as it interprets the next line of code.

Speed isn't always what makes or break a language

Re:More importantly... (1)

LOLLinux (1682094) | more than 4 years ago | (#30574782)

Compared to what?

Basically every other language you mention in your post.

Re:More importantly... (0)

Anonymous Coward | more than 4 years ago | (#30575278)

Well, let's see...

Ruby 1.9 is about as fast as Python or Perl. JRuby is faster, and approaches Java.

When you actually benchmark it [merbcamp.com] , Ruby isn't slow. Rails, maybe (though faster than PHP), but not Ruby.

Re:More importantly... (0)

Anonymous Coward | more than 4 years ago | (#30575544)

JRuby is faster, and approaches Java.

That doesn't sound right.

So you are saying that by translating python code to ruby (same shit, different syntax) and running it in JRuby, I could get speeds that "approach Java"?

You may fool some of your computer illiterate ruby friends with that, but I wouldn't go around extolling that in public...

Re:More importantly... (1)

GooberToo (74388) | more than 4 years ago | (#30576600)

It doesn't sound right because its not.

Ruby is still far slower than Python on the typical basis. Jython, JRuby, and Java all perform about the same when running on the JRE, with Java still leading by a noteworthy margin; which isn't exactly surprising.

Re:More importantly... (0)

Anonymous Coward | more than 4 years ago | (#30576610)

So, you're saying that instead of running a native Ruby interpreter, I can use a Ruby interpreter which is written in Java (non-native).

So by adding another layer of abstraction on top of the hardware, you make stuff faster? Am I understanding this correctly, or are you just full of shit?

While we're at it, why don't we just run JRuby inside of Wine, inside of a Linux VM sitting on top of a Windows desktop. So fast!

Re:More importantly... (0)

Anonymous Coward | more than 4 years ago | (#30576732)

No, that's for real because JRuby benefits from Java's JIT compiler, just as Jython does. That means Ruby code running on the JRE can realize huge performance boosts as it has been compiled to not only native code, but in many cases, specialized native code implementations, where the passed arguments determine the actual native code path taken and the level of optimization/performance.

Re:More importantly... (1)

LOLLinux (1682094) | more than 4 years ago | (#30578332)

but in many cases, specialized native code implementations, where the passed arguments determine the actual native code path taken and the level of optimization/performance.

Has anyone actually proven this in practice? This is proclaimed in the theoretical sense over and over but I've never actually seen anything real to back this up.

Re:More importantly... (0)

Anonymous Coward | more than 4 years ago | (#30579774)

Not personally. Every time I've tried it, it failed to compile in JRuby, because its so far behind the C implementation. So if you have old ruby code lying around that just happens to do nothing that's not supported by Jruby, you're okay. Or if you write ruby code specifically with Jruby in mind. Those usually aren't the scenarios I run into. Usually its prewritten Ruby that's slow as crap, that I try and speed up by trying to compile it it Jruby.

Although to be fair, the Ruby implementation usually isn't too much slower than the python. And Jython is even worse than Jruby.

Re:More importantly... (1)

dkf (304284) | more than 4 years ago | (#30626870)

but in many cases, specialized native code implementations, where the passed arguments determine the actual native code path taken and the level of optimization/performance.

Has anyone actually proven this in practice?

I've seen it with mathematics-heavy code written in a style that's not very idiomatic for Java (but still nicer than Fortran, which is what was used for the comparison baseline). I suspect that typical Java code does not get as good a speedup as that due to poor memory management at the user code level and fragmentation of programs into lots of little pieces scattered over a deep inheritance hierarchy (happens too often, hard to optimize very extensively).

OTOH, what a good JIT does seem to do is get rid of the penalty of using an object format that is not native code. (It could go better, but rarely does because the gains from compiling with profiling data available - the typical equivalent in C programming - are usually very small.)

Re:More importantly... (0)

Anonymous Coward | more than 4 years ago | (#30578144)

.
Python, Perl or other Scripting languages where there is little optimization that can go on as the code is running as it interprets the next line of code.

Python is automatically compiled to portable byte code, and perl (and most other scripting languages) is not interpreted line-by-line.

Before commenting, please complete this form (5, Insightful)

Xunker (6905) | more than 4 years ago | (#30574540)

Before commenting, please complete this form:

Sec. 1 Ruby v Python

[ ] I am a Ruby/Python fanboy/fangirl
[ ] I already have a positive/negative entrenched opinion of Python or Ruby
[ ] I cannot tell the difference between the two languages

Sec. 2 Ruby on Rails

[ ] I assume Ruby == Ruby on Rails

Sec. 3 Other

[ ] I program in PHP for it's robust design, consistent syntax and architectural soundness
[ ] I do not understand sarcasm

Scoring: If you answered any of the above questions in the affirmative, your comments may be dismissed out of hand.

Insightful Funny (4, Funny)

aztracker1 (702135) | more than 4 years ago | (#30575514)

Parent should be modded insightful. Mine should be modded funny.. sheesh.

Ruby on Rails is for primadonnas (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30574692)

Ruby on Rails is for primadonnas who think their bloated one size fits all framework is the answer to the problem before they even hear the solution.

Their zealotry is best understood when you realize that since they aren't real programmers to begin with, this is the only option available to them. It's easier to badmouth all other languages than it is to fully learn a single language.

Re:Ruby on Rails is for primadonnas (0)

Anonymous Coward | more than 4 years ago | (#30574734)

agree. Since most of them think all the cool shit is unique to their language, its not ... or at least not anymore.

McAnally? (0)

Anonymous Coward | more than 4 years ago | (#30574866)

Google trends:

http://tinyurl.com/rubypython [tinyurl.com]

Good News / Bad News (1)

vlm (69642) | more than 4 years ago | (#30574880)

The good news, is I like the topic, I have fat stacks of cash and am willing to part with it for a good book. Emphasis on the word Good. A direct pipeline into the minds of the insiders, is worth some bucks.

The book credits a number of Rubyists with contributions for each of the sections.

Ah, and then the bad news. Naughty book editor, gimme my money back.

This makes for some noticeable variation in the stylistic presentation from topic to topic.

So, Mr reviewer, what say? You described the battlefield, now which side won? Do the direct insights of the words of the prophets outweigh cruddy editing, or is it too shaky to read? I've got a pocket full of cash and like the bank robber says in the movie Dirty Harry, indecisively struggling asking himself if Harry's revolver is empty or not, "... I gots to know ..."

Re:Good News / Bad News (1)

emj (15659) | more than 4 years ago | (#30575136)

Well what he does mention seems like they have the same style all over (lots of code).. You can read more than just the TOC [safaribooksonline.com] (1/3 of every page), at the site..

Hi, the author here... (2, Informative)

graznar (537071) | more than 4 years ago | (#30576120)

Looks like the stock is getting slim over on Amazon, so if you want to order it still and they're out, hit up the Manning site: http://manning.com/mcanally/ [manning.com] Thanks!

Re:Hi, the author here... (0)

Anonymous Coward | more than 4 years ago | (#30576422)

McAnally?

Re:Hi, the author here... (1)

graznar (537071) | more than 4 years ago | (#30576528)

Yes, let's all have a good laugh at my surname. I picked it out myself after all. I kid. I get that a lot. :)

McAnally? (1)

HNS-I (1119771) | more than 4 years ago | (#30581116)

And the co-author is Assaf Arkin, I'm afraid it doesn't get any better than this.

Really need a book on scaling ruby on rails (1)

fortapocalypse (1231686) | more than 4 years ago | (#30576464)

If there were a good book on how to (more easily) scale ruby/jruby on rails apps, I'd buy it. I don't think I'd buy a book on Ruby otherwise.

Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30576544)

I really never figured out exactly who Ruby appeals to. It seems those who would be interested in Ruby would also be attracted by the more mature Python.

So what projects and for what reasons are people picking Ruby over Python? Perhaps Python isn't even in the comparison? Is it just to be different? The antithesis of the heard mentality? Some critical feature Python is missing? Superior frameworks? Why?

Re:Who wants Ruby? (2, Interesting)

Lord Ender (156273) | more than 4 years ago | (#30576698)

Python is more mature than Ruby. But that's Python's only advantage. Overall, Ruby is simply a more elegant and powerful language. It is a dream to program in. This is why you find people migrating from Python to Ruby, but very few going in the other direction. And the maturity disparity is only a matter of time...

Also, JRuby is much more mature than Jython. If you want to work with Java libraries while still using a dynamic language, JRuby is the way to go.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30576968)

Python is more mature than Ruby.

Much more....and it shows in the library from all accounts I've read.

But that's Python's only advantage.

Clearly not just from reading the comments left here. Clearly Python's maturity provides for code stability and far easier migrations to receive the performance benefits of newer VMs. I suspect, but don't know, the list is actually far, far longer, all of which to be attributed to Python's maturity.

Overall, Ruby is simply a more elegant and powerful language.

That's extremely subjective. The same can be said for Perl (and yes, I've done large Perl projects too), but at the end of the day, Perl is Perl and I'd take Python or Ruby any day of the week for 99% of the projects I do.

This is why you find people migrating from Python to Ruby, but very few going in the other direction.

That doesn't really carry much weight. In fact, from what I've seen, those that have migrated to Ruby from Python have largely migrated back - viewing Ruby as an interesting experiment. Furthermore, those that did migrate largely did so because of rails. Now that Python has a huge bucket of competing solutions, some arguably superior, especially in ORMs, the draw of Ruby vs Python seems to have been drastically reduced. The python vs ruby trends link someone else provided seems to also support this position. Which is to say, Ruby drastically grew, then shrunk, and has largely not changed after that.

And the maturity disparity is only a matter of time...

Actually its not. Its all relative. Python has a much, much larger developer and user base and as such, its far more likely the divide will widen over time. This divide includes the language features, general VM performance, and the library itself. Having said that, it does appear Ruby is likely to simply mature and perform good enough in the very near future, which is likely to widen its general appeal. Perhaps that's what you meant?

Also, JRuby is much more mature than Jython. If you want to work with Java libraries while still using a dynamic language, JRuby is the way to go.

While I don't have direct experience, Jython is very mature. It supports 100% of Python 1.5 and a good chunk of Python 1.6. I suspect, Jython is as mature as JRuby. If not, please clarify in what regards JRuby is significantly moreso and to what degree is sets it apart. Interestingly enough, if Jython is a significant factor (it likely is for only a tiny minority), IronPython leaves both JRuby and Jython in the dust in both scope and scale. Likewise, both Ruby and Python are actively getting some LLVM-love. For Python, Google is actively pushing the LLVM effort forward, made initial steps to make it an OS project, and has already made significant strides in the JIT-Python realm. Whereas, Ruby is still a community effort. Take from that what you will.

In short, your post has only convinced me, aside from Rails, Ruby has nothing to offer other than language uniqueness. Worth mentioning, a multitude of Python frameworks level the Rails advantage. That seems to all boil down to the only advantage Ruby has is personal choice and preference.

Which brings me full circle - what am I missing. Thus far, it seems nothing. Seriously - what is luring developers to use Ruby over Python?

Re:Who wants Ruby? (2, Insightful)

Lord Ender (156273) | more than 4 years ago | (#30577116)

Clearly...clearly...much, much...drastically...drastically...

Wow, you're trying so hard to stress your opinion, it's as if you feel... threatened?

I've coded quite a deal in Python before switching to Ruby. As I said, Python is currently more mature. I like Python. It's my second favorite language. But the syntax? Metaprogramming? Python is chore to use by comparison. You are out of the loop, as evidenced by your errant performance claims. Ruby 1.9 is much faster than previous versions, and JRuby is faster than Python, while simultaneously providing access to all of Java's libraries! Jython performance isn't even in the same ballpark.

It's hard to articulate why one synatx is more beautiful than another, but let me give you an example of an entire Web App written with Sinatra:


get '/' do
    "Hello world."
end

Elegant.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30581478)

Wow, you're trying so hard to stress your opinion, it's as if you feel... threatened?

Hmmm... seems you're clearly projecting here. I'm asking questions to learn and to understand the attraction vs python and the only way to do so is by comparison. In return you attack? Why are *you* so threatened? Clear and expressive communication is entirely the point of communicating; and especially so in written form. If effective communication is threatening to you, you should seriously take time to re-evaluate your position.

JRuby is faster than Python

Pretty strong proof you're extremely threatened...which is absolutely not my intent. Comparing JRuby to CPython is bluntly, idiotic and you know it. Jython exists for the very same reasons jRuby does. Anyone not threatened by Python, as you clearly are, is going to compare Jython to RJuby and nothing else. You don't see other people running around making such odd claims. When people say Ruby they mean Ruby. And when people say Python, they mean Python. What they don't mean is JRuby and Jython, as when they mean that they say that - as I clearly have done so.

get '/' do
        "Hello world."
end

Elegant.

That may be elegant but its equally useless and slow. That example is exactly why we have static pages or at a minimum, cached pages. In other words, its not representative of anything anyone is likely to do with a Rails or TG like framework. That's why ORMs, templates, and all the other magic is so important.

I take it your position, if I may be so bold to read into your undertone, is Ruby's primary strength and elegance is strictly in web development?

Care to try take two and seriously address my questions in the above thread before you attempted to derail it? Hmm...wonder if the later part qualifies as a pun. ;)

Re:Who wants Ruby? (1)

Lord Ender (156273) | more than 4 years ago | (#30581974)

clearly...

Oh geeze, not this shit again. Moving on:

That may be elegant but its equally useless and slow.

Wow. Really? It's like you're trying to miss the point. No sense wasting my time trying to communicating with someone like that; I've got code to write!

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30582062)

I think you pretty well summed up; there is no advantage.

I didn't even address the fact that there is a big difference between elegance and terseness. What you provided isn't event elegant, its terse. Elegance is a simple solution to a [often complex] problem where a non-obvious solution exists. What you provided is a terse, meaningless example of rails. Big difference. Compared to your example, a static page is elegant.

In a nut shell, you really need to stop projecting your own inadequacies and fears onto other people. And if you don't have anything to contribute, simply don't. In this case, you shouldn't have, on every point I mention.

Clearly, you need to learn what communication is all about. Until then you'll only ever waste everyone's time. Period.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30582156)

In case you wanted to know what everything points to as the real answer to my questions. [slashdot.org]

That way, in case you run into such questions in the future, you'll have what appears to be a legitimate answer rather than the clearly bullshit and incendiary reply you gave me. Also notice the difference in tone and quality of exchange. Please note the difference between your bullshit and a meaningful effort to effectively communicate.

Happy Holidays!

Re:Who wants Ruby? (1)

Lord Ender (156273) | more than 4 years ago | (#30587284)

No matter how many times you use the word "clearly," your uninformed opinion becomes no less invalid. The fact that you dismiss a general example of web app syntax with "you could do that with just html" shows that you either have no idea what you are talking about (still in school?) or you're just a troll.

Either way, I'm not wasting my time on you. Good day.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30592960)

The fact you refuse to answer any of the questions offered in rebuttal, are easily confused by the words, "clearly", and, "elegant", and readily resort to projection and attacking can only be interpreted as biased fanaticism without nothing to contribute whatsoever, followed by accusations of trolling. The word, "clearly", is completely obvious to anyone with a smidgen of IQ. Made worse, your entire straw man argument hinges on a useless example whereby its entirely best to replace it with a static page; despite the fact many other factors (templates, ORM) where specifically mentioned as being significant.

Either way, I'm not wasting my time on you. Good day.

The sad thing is, YOU'VE wasted everyone's time and then go on to troll about how your trollish time was wasted. Nicely played but incredibly transparent; as is your entire, irrational and fanatic rant.

Next time you decide to not "waste your time", can you please do that BEFORE you've wasted everyone else's? Pot, kettle, you....holy shit.

Re:Who wants Ruby? (1)

DragonWriter (970822) | more than 4 years ago | (#30588554)

Jython exists for the very same reasons jRuby does. Anyone not threatened by Python, as you clearly are, is going to compare Jython to RJuby and nothing else. You don't see other people running around making such odd claims. When people say Ruby they mean Ruby. And when people say Python, they mean Python.

Ruby and Python are languages. MRI, JRuby, IronRuby, Rubinius, Ruby Enterprise Edition, etc., and CPython, Jython, IronPython, etc. are implementations. If you want to compare language-to-language on implementation-dependent features (like speed), the fair way is to compare the best implementation of each language across the feature set you are comparing. Jython and JRuby share a focus on Java integration, but beyond that aren't really similar; Jython is one of the slower Python implementation (in most tests I've seen, much slower than CPython), JRuby is in most tests the fastest Ruby implementation (although the main 1.9 implementation is often close to JRuby.) So, if you are talking about the speed you can get out of the language, comparing JRuby to CPython is fairly reasonable.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30594212)

Ruby and Python are languages.

With defacto reference implementations whereby when someone mentions that language they specifically mean the reference implementation. I guess since Ruby is coming from such a performance deficit that general rule is thrown out the window; but that's news to the world. Made yet odder is the fact you specifically compared JRuby to CPython to claim superiority. Again, something is amiss. But then again, I previously explained all this.

Jython is one of the slower Python implementation

I decided to look based on your insistence. It does appear I may have had smoke blown at me many a time about Jython's performance; but most of the benchmarks I found were fairly old (a year or more). I did find mention that Sun was actively working to bolster Jython's performance from again, over a year ago. Regardless, I'll back off my assertion here as I couldn't find anything to bolster my position. It appears you're right.

But, I did find something which is very contrary to your other assertions and my own expectations. In the benchmarks I found, cpython was generally a lot faster than ruby 1.9 in 60% of the benchmarks. Based on comments, that shouldn't come as a surprise, but the smaller gap compared to previously ruby versions is still noteworthy. In 30% of the benchmarks, ruby 1.9 was on par with cpython. And in only 10% of the benchmarks was ruby 1.9 faster than cpython. In short, while cpython was faster than ruby 1.9, it looks like its performance, like python, is good enough for all but those who have an axe to grind.

But more interestingly, it appears JRuby is actually a very mixed bag. In the benchmarks, cpython was a lot faster (33%-89%) than jruby in 36% of the benchmarks. Furthermore, cpython was as fast as jruby in a different 36%. Meaning, 73% of the benchmarks place cpython on par or better than jruby. In only 27% of the benchmarks was jruby faster than cpython, and in those benchmarks, jruby was considerably faster; 2x-3x than that of cpython.

To summarize cpython vs jruby, cpython is faster based on the sum of the benchmarks; cpython's 73% vs jruby's 63%, whereby the percent represents the percent of benchmarks which are faster or on par with the other. In other words, based on these benchmarks, ranked by performance you have cpython, jruby, and ruby 1.9, which isn't exactly as you've advertised and is even a surprising departure from my own expectations. It appears from a performance perspective, cpython vs rjuby performance is highly subjective based on the actual project and likely, its not accurate to claim jruby is faster than cpython.

Disappointingly, they do not provide benchmarks for jython or psyco.

As for psyco and my own experience, for two of my own projects (heavy network servers with cached and lightly accessed db backend via sqlalchemy), psyco resulted in a performance boost of 1.6 and 2.1 over that of stock cpython (version 2.5.something at the time. I forget exact version). Granted, the performance boost psyco provides is significantly affected by the project implementation. Having said that, with the addition of psyco to a python project, it would not be much of a stretch to anticipate cpython+psyco to be considerably faster than jruby, on average.

At the end of the day, I really did not desire to go down the performance comparison path, but I'm actually glad I did as I find these results rather surprising and interesting.

Cited benchmarks [debian.org]

Re:Who wants Ruby? (1)

DragonWriter (970822) | more than 4 years ago | (#30597996)

But, I did find something which is very contrary to your other assertions and my own expectations.

Where does anything in your long rambling recitation of results of the "Computer Language Benchmarks Game" contradict anything I've said?

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30608144)

That was actually to Lord Ender - didn't pay attention to whom I was replying.

And summarization to make a clear point is far from rambling. Seems rudeness goes hand and hand with most Ruby guys. Wow.

Re:Who wants Ruby? (1)

DragonWriter (970822) | more than 4 years ago | (#30608412)

And summarization to make a clear point is far from rambling.

Yes, properly done, a summarization to make a clear point is far from rambling. That doesn't affect my characterization of GGGP, though.

Seems rudeness goes hand and hand with most Ruby guys.

This is amusing coming when you -- by your own admission in the same post containing this accusation of rudeness -- just posted a "response" to someone claiming that their claims are contradicted by empirical testing, when no such claims were contained either in the post responded to or any other post by the same poster, because its too much effort to pay attention to who has posted different claims before attributing them to the poster they are responding to.

Re:Who wants Ruby? (0)

Anonymous Coward | more than 4 years ago | (#30583150)

You run mac, too, don't you?

Oh well, I needed to throw up today. It's my diet day.

The plural of anecdote (0, Troll)

metalhed77 (250273) | more than 4 years ago | (#30577646)

That doesn't really carry much weight. In fact, from what I've seen, those that have migrated to Ruby from Python have largely migrated back - viewing Ruby as an interesting experiment

The plural of anecdote is not data.

While I don't have direct experience, Jython is very mature. ... I suspect, Jython is as mature as JRuby.

Wow, I'd love to hear your opinion about things you have no experience with and have strong suspicious about.

How do you expect to be seriously talking about stuff you claim to not really know about?

I suspect you could benefit by taking a step back, re-reading your post, and spending some time reflecting on your own biases.

Re:The plural of anecdote (1)

LOLLinux (1682094) | more than 4 years ago | (#30578658)

The plural of anecdote is not data.

He never made any such claim. He was just responding to someone else's anecdote with his own.

Re:The plural of anecdote (1)

GooberToo (74388) | more than 4 years ago | (#30581500)

The plural of anecdote is not data.

Which means your entire rant is safely ignored as I clearly referred to DATA. The word idiot comes to mind.

Okay, something is entirely clear from the replies I'm getting. There is no advantage and anyone who questions is to be attacked, as that's the only recourse available to Ruby users.

That's sad.

Re:Who wants Ruby? (1)

rtb61 (674572) | more than 4 years ago | (#30578748)

Simpler to say Ruby is more compact, easier to read and understand. More compact you can see more code on screen especially when using an IDE, often a complete function, sometimes a complete module. Easier to read and understand has two benefits, less documenting required and, heh, of course poorly documented code is easier to understand. From this comes all the other benefits, like a large function library etc.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30581594)

First, let me say thank you for responding in a coherent, non-threatened manner. Seriously and sincerely.

More compact you can see more code on screen especially when using

So why not use Perl over Ruby if terseness is such a significant factor? You'd be hard pressed to be more compact than Perl.

From one rant I received, some seem to confuse terseness with elegance. Once again I find I'm thanking you for for not being so easily confused.

I do agree, from what little Ruby I've seen, terseness is a clear attribute of Ruby and seems completely contrary to the Python approach, which is concise readability and no more, if I may be allowed my own python impression vs Ruby's, I guess, compact readability. Then again, Perl's terseness borders on encryption territory so perhaps Ruby has figured out the right combination of terseness without encryption. ;) But I cant help but wonder if that's not a personal preference. That's one of the reasons Perl doesn't particularly appeal to me and yet Perl has no end of champions.

Please don't get me wrong. There is absolutely nothing from with personal preference of a language. After all, a language which really speaks to a developer's way of thinking and problem solving goes a long way toward speeding development and problem solving. IMOHO, it likely aids in debugging comprehension too. But at the end of the day, IMOHO, that's not necessarily a language feature either; unless perhaps its universally true. And I'm not sure there is a clear indication of the later...

Re:Who wants Ruby? (1)

rtb61 (674572) | more than 4 years ago | (#30587498)

I suppose you have to allow that I am not heavily into coding, as such, I have very little personal investment in it. Simply I like the language that's the easiest to code and debug. I forgot to mention another big plus for me, http://en.wikipedia.org/wiki/Interactive_Ruby_Shell [wikipedia.org] , nothing like being able to run and test a single line of code to see what is not working and to check for undesired output.

It just seems a very flexible easy language that can be used in a lot of different environments, so it gets the numbers, not so much from professional coders (the cranky ones, defending their expertise and dollar value, understandable) but from learner, amateur and hobby coders (as well as of course for those for whom coding is only an adjunct to the actual professional skill) and of course numbers means a lot for creating a growing user base and defining market penetration.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30594438)

I didn't know Ruby had an interactive shell. Thanks.

In case you're curious, if a script is not provided to python it goes into an interactive mode, allowing for much the same thing. And if you want such python interaction on steriods, you can always checkout ipython [scipy.org] , which is actually a complete command line shell replacement (as in replacement for bash, ksh, cmd, etc), in addition to its interactive python capabilities.

Re:Who wants Ruby? (1)

DragonWriter (970822) | more than 4 years ago | (#30585744)

Furthermore, those that did migrate largely did so because of rails. Now that Python has a huge bucket of competing solutions, some arguably superior, especially in ORMs, the draw of Ruby vs Python seems to have been drastically reduced.

I'm not really sure that's all that true: even if Python frameworks caught up with where Rails was, there are lots of Ruby frameworks -- inspired by people hitting places where Rails wasn't ideal -- that are better than Rails for lots of things (including Merb, which is merging into Rails with Rails 3), and for ORM particularly there are a lot better solutions than ActiveRecord for general use, like Sequel.

While I don't have direct experience, Jython is very mature. It supports 100% of Python 1.5 and a good chunk of Python 1.6.

You mean 2.5/2.6, instead of 1.5/1.6, right?

Even so, JRuby -- which supports essentially all of Ruby 1.8 except Continuations, and has a 1.9 mode that is close on the heels of the mainline Ruby 1.9 -- is a more current Ruby than Jython is for Python.

For Python, Google is actively pushing the LLVM effort forward, made initial steps to make it an OS project, and has already made significant strides in the JIT-Python realm. Whereas, Ruby is still a community effort. Take from that what you will.

Both JRuby and Rubinius (one of two--MacRuby being the other--Ruby implementations that leverage LLVM, Rubinius using it for JIT) are open sources projects that are coordinated by (small, to be sure) full-time teams at Engine Yard (the JRuby team was formerly at Sun). Sure, Engine Yard isn't Google , but it is a for-profit company with real sales that has dedicated full-time resources to Ruby, sponsoring the core teams for two of the most important Ruby implementations (and sponsoring full-time developers assigned to Rails 3, as well.)

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30594850)

You mean 2.5/2.6, instead of 1.5/1.6, right?

Err, yes...sorry...too many version numbers being tossed around.

Even so, JRuby -- which supports essentially all of Ruby 1.8 except Continuations, and has a 1.9 mode that is close on the heels of the mainline Ruby 1.9 -- is a more current Ruby than Jython is for Python.

I concede that now.

I'm not really sure that's all that true

Something I wish I had previously offered is, much of the modern Python web frameworks got much of their inspiration and direction directly from Rails; no bones about it. As a result, many of those same projects worked to implement a wanna-be rails equivalent.These first generation wanna-be frameworks fell short on many fronts. Regardless, various framework projects followed and all seemingly suffered the same issues as Rails, without all of the advantages. Which is to say, they all scaled horribly.

As a result, second generation frameworks for python came about hoping to resolve these issues. Many still have scalability issues but did a good job of closing the gap with many of Rail's many advantages; yet still lacked in the ORM department. As a result, a third generation of frameworks, which now fully embrace SQLAlchemy, exist which largely address both scalability issues and ActiveRecord advantages. As a result, projects like the current TurboGears go a long was toward addressing past deficiencies of past generational frameworks and neutering Rails' advantages; including ActiveRecord. In short, I believe it is fair to say parity exists and that SQLAlchemy likely even provides a superior ORM than ActiveRecord.

Sure, as you point out Rails isn't exactly standing still, just the same I don't have a problem offering Python has reached web framework parity with Rails. At this point, if each once to keep leap frogging each other, I can only smile.

Re:Who wants Ruby? (1)

DragonWriter (970822) | more than 4 years ago | (#30597754)

I believe it is fair to say parity exists and that SQLAlchemy likely even provides a superior ORM than ActiveRecord.

Sure, as you point out Rails isn't exactly standing still, just the same I don't have a problem offering Python has reached web framework parity with Rails.

Perhaps, but there are other, arguably better, Ruby ORMs (Sequel, DataMapper) -- which can be used with Rails, and some of which are the preferred ORMs on other Ruby web frameworks -- than ActiveRecord. ActiveRecord is dominant because it comes with Rails as part of the basic "all-in-one" solution, but its easily replaceable even when using the rest of Rails, and there are several alternatives within the Ruby ecosystem. Ruby -- even when it comes to web frameworks in general and ORMs in particular -- is more than Rails (and certainly more than the core components of Rails), though Rails is one of the big engines that drives Ruby.

Re:Who wants Ruby? (0)

Anonymous Coward | more than 4 years ago | (#30577142)

It seems those who would be interested in Ruby would also be attracted by the more mature Python.

Very often the reverse is true. I was attracted to Python, learned it, loved it (I still quite like it). Then I met Ruby. Of the two, I prefer Ruby.

Re:Who wants Ruby? (0)

Anonymous Coward | more than 4 years ago | (#30578388)

Do you also like to have dildos stuck in your ass?

Re:Who wants Ruby? (1)

jjohnson (62583) | more than 4 years ago | (#30580052)

The only meaningful distinction I've seen after spending time investigating the two and why some choose one over the other, is the underlying philosophy of each. With Python, there's almost always a "right" way to do a particular thing, an attitude of choosing the best practice summed up in the adjective "pythonic". Ruby follows Perl's TIMTOWTDI line, with a very flexible syntax that allows for a variety of ways to accomplish a particular end. So mainly, it's a temperament thing: coders who like a flexible tool that allows them to find 'clever' solutions prefer Ruby; coders (like me) who like for there to be a best practice, and don't break the rules without a decent reason to do so, prefer python.

A good snapshot of the difference was in Zed Shaw's now disappeared rant about Ruby, where what set him off was finding a bunch of hacks injected into a logging library he was using, and realizing that he was not only going to have to inject his own, but that this was expected and commended in the community. The idea that there should be a stable API forming the basis of a contract with the programmer was looked down upon by Rubyists, causing Shaw to dismiss them as cowboys and amateurs.

Re:Who wants Ruby? (1)

GooberToo (74388) | more than 4 years ago | (#30581720)

First, let me say thank you for responding in a coherent, non-threatened manner. Seriously and sincerely. Your reply seems well thought out and also seems to support much of what I suspected; though not to the level of detail you provide.

It appears it boils down to personal preference in that the language and underlying philosophy simply speaks to a developer. I can absolutely respect that. Not everyone thinks the same way and not everyone goes about solving problems the same way. So while Rubyists may be "cowboys and amateurs", they likely are more effective using Ruby vs Python as it likely jives more coherently with the way their brain solves problems. If true, professionally I am objectionable to Ruby; though personally I can understand their position.

Thanks again. Anecdotally you've seemingly confirmed my suspicions.

Re:Who wants Ruby? (1)

mcvos (645701) | more than 4 years ago | (#30582354)

The only meaningful distinction I've seen after spending time investigating the two and why some choose one over the other, is the underlying philosophy of each. With Python, there's almost always a "right" way to do a particular thing, an attitude of choosing the best practice summed up in the adjective "pythonic". Ruby follows Perl's TIMTOWTDI line, with a very flexible syntax that allows for a variety of ways to accomplish a particular end. So mainly, it's a temperament thing: coders who like a flexible tool that allows them to find 'clever' solutions prefer Ruby; coders (like me) who like for there to be a best practice, and don't break the rules without a decent reason to do so, prefer python.

This is a very good point. This also shines through in the culture of the communities. I've read from several people that they got annoyed by the Python community's rigid stance. Often someone would find an odd quirk (arguably even a bug) in Python and ask why it was like that. Instead of responding with possible fixes, the responses often amounted to "that's the only right way to do it, and if you disagree, you're wrong" (though probably phrased more diplomatically). In many other communities (including Ruby), the response is more likely to be something like "yeah, we need to fix that some day", "there's a plugin/gem for that" or "here's how you can fix that yourself".

A good snapshot of the difference was in Zed Shaw's now disappeared rant about Ruby, where what set him off was finding a bunch of hacks injected into a logging library he was using, and realizing that he was not only going to have to inject his own, but that this was expected and commended in the community. The idea that there should be a stable API forming the basis of a contract with the programmer was looked down upon by Rubyists, causing Shaw to dismiss them as cowboys and amateurs.

Valid criticism. Ruby is often more hacky, and there are a lot of issues that do need to get fixed some day. Then again, people generally do recognise them as broken and do plan to fix them, rather than claiming it's the way God intended it.

Re:Who wants Ruby? (1)

DragonWriter (970822) | more than 4 years ago | (#30585336)

I really never figured out exactly who Ruby appeals to. It seems those who would be interested in Ruby would also be attracted by the more mature Python.

Lots of Rubyists are also attracted by Python, though even many of those that like Python in general often dislike particular aspects of Python (the whitespace handling is a big one.) Also, lots of people prefer Ruby because they like particular Ruby frameworks (Rails, of course, is a big one) or because they found it an easier transition from Perl. And lots of people have particular features that make them prefer Ruby (blocks are the one I've seen cited most often.)

Re:Who wants Ruby? (0)

Anonymous Coward | more than 4 years ago | (#30590134)

I Just took a Ruby job, after spending the last 5 years doing Python.

Python is excellent because of it's maturity. Ruby is excellent because of it's modernity.

To use a metaphor, it's like the difference between dating a 35 year old career woman vs a 20 year old college girl. The former is set in her ways and will offer a stable relationship with a lot of benefits. The latter is full of potential and can teach you new tricks.

In practical terms, Ruby happens to have a lot of programmers trying to change *how* software is written. The 3rd party library and distribution eco-system (gems via gemcutter, rubyforge, github) is better than any other language. Rack and Sinatra are easier and cleaner than WSGI and what, web.py? Finally the Heroku platform is *incomparable*.

So yes, frameworks and platforms are a big part of the appeal of Ruby over Python these days.

As for why Ruby might be doing better here? For one, Ruby is a more expressive than Python, and better designed than Perl; it does have features other languages are missing. For two, Ruby hit the scene after computers and the web were ubiquitous so it's just good circumstance for something new, and perhaps better, to catch on.

Every Language I've Ever Worked With... (0)

Anonymous Coward | more than 4 years ago | (#30578472)

Has Pros and Cons but I'm more productive with Ruby than with any other language.

Sure, there's a learning curve and you have to take the time to explore the libraries but the same can be said
for every other language I've ever worked with (going on 18+ at point).

The language is still undergoing development and experimentation is a vital part of that process. Language lawyers,
conservatives, structuralists and retired-on-the-job beware! Thinking and investigation are required.

That said, the bottom line is still that I get more done and that's most important to me.

Ruby tag? (0)

Anonymous Coward | more than 4 years ago | (#30579148)

I'm not too informed on how Shashdot's tagging system works so I could be making a silly complaint here, but isn't it a little dumb that this article isn't tagged "ruby"? They're supposed to be tags to ease searching and categorization, not microcomments...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>