Rails has been a blessing and a curse for the Ruby community. It brought sudden popularity to the language with all the consequences, good and bad, that usually result from exponential growth. On one hand, it gave many developers the chance to appreciate the design of the Ruby language based on its own merit. On the other hand though, it’s been a cash cow that’s changed the community forever by attracting all kinds of attention. Rails has become the poster child for Ruby, blurring the distinction between the Ruby, and Rails, communities. A large number of web programmers got to experience the “ease of use” and beauty of Ruby development, but it also clearly exposed Ruby’s implementation shortcomings. Rails enabled Ruby to go from a relatively unknown programming language to a mainstream one within the frame of just a couple of years. Languages are made to be used, so overall, most would agree that the advantages for Ruby, brought forth by Rails’ success, far outweigh the negative aspects. In the words of Matz, Ruby’s creator:
Rails is the killer app for Ruby.
— Yukihiro Matsumoto
Whatever your take on the subject is, in this article I argue that Ruby on Rails is actually the best thing that ever happened to Python. Rails is a successful Ruby framework, so some may think that it would convince people to switch from Python to Ruby. In other words, naively, one could think of Rails as a Python exterminator, at least as far as web development goes (which is a big deal nowadays). This couldn’t be further from the truth. This year is going to be a great one in terms of the adoption of Python, and I think that Rails has had a positive influence in this regard.
Independently from Rails and Ruby, over the past few years Python has had a good deal of penetration within the market. It wasn’t Java, of course, but as far as dynamic languages go, Python was well represented in many companies and achieved a fairly adopted niche even within the enterprise world. What Rails did was to promote and popularize the usage of MVC web frameworks written in dynamic languages. What could have been considered an unusual choice in the pre-Rails era, is now viewed by most as the right way of developing web applications. The marketing abilities of the Rails community benefited the Python one, in the sense that they made the usage of dynamic languages for serious web projects a very acceptable and even well warranted choice.
Rails got the message out that MVC web frameworks and “scripting” languages could be very productive and much nicer to work with. Django and other web frameworks are indirectly taking advantage of this. A couple of years ago people were asking me whether it was better to adopt Rails or stick with Java for a given project. Nowadays, most emails and requests that I receive are about whether it makes sense to adopt Rails and Ruby or if it would be more sound to use Django and Python.
Initially, even Sun hired Ruby hackers to work on JRuby and have only recently announced that two pythonstas will work on Jython full-time. Yes, they are late to the party and should have done this years ago, but I think that Rails’ popularity and hype led them to consider Ruby first before eventually realizing that they should have done the same thing for Python. Rails has been, at least in part, a catalyst for Python’s success.
Don’t let this confuse you though. Python (and Django) are able to benefit from all the interest geared towards dynamic languages, only because they are technically excellent and make a strong case on their own. Their communities are much less about marketing and more about substance, in my opinion. I understand those who go from Ruby to Python, but there are far fewer motivations in favor of a switch from Python to Ruby. The reason for this is that, in a way, Python is currently an answer to Ruby’s MRI shortcomings. When I speak about Ruby’s shortcomings I always refer to the implementation and not to the design of the language, which is a well balanced and coherent mix of paradigms and features.
Things will change with Rubinius (and perhaps JRuby), but as it stands right now, Ruby’s implementation has critical limitations that affect the development of non-toy projects and its adoption within the enterprise world. Speed, I/O processing, threads, garbage collection and troubling deployment when compared to other languages, are serious issues. It doesn’t mean that you can’t use it, just that the limitations that are in place will make your life more difficult on certain projects.
In a way, Python is the only acceptable implementation of Ruby for certain values of Ruby. The two languages have different approaches and quite a few distinctions which make them both unique. Overall though there are plenty of similarities that make developing in one or the other a somewhat comparable mental process and coding experience. Sure, Python doesn’t promote the functional paradigm as much, and it’s less implicit/magical than Ruby (read import this). This could be a good thing when it comes to large and enterprise projects, but the two are all not that different from each other. They’re Capelli d’angelo and Spaghettini, as my fellow countryman Alex Martelli eloquently put it.
As much as I may like Ruby more as far as language design goes, not only does Python boast a very solid implementation, it has several advantages over Ruby that go beyond the interpreter. I’ve found that Python has an incredible amount of rock solid, high quality libraries that perform very well. Not all of them of course, but most are well coded, maintained and documented. In Rubyland we can’t claim the same levels of good reusable code. I use both and I see a big difference. Lingering for a moment on the subject of documentation, Python has a wealth of tutorials, guides and even entire books available for free online. Learning Python from these, without spending a cent, is a walk in the park. Ruby on the other hand has good books in print, but a long way to go as far as free documentation goes. And this is true for both Ruby and Rails.
The community attitude is much different too. The Python and Django communities generally keep a low profile, following the “shut up and show them the code” mantra. They do have some marketing issues but can’t be blamed for hyping their technology, like at least in part, Rails has done. For example, Django is a very mature framework that’s several years old, and yet it still hasn’t been tagged as a 1.0 version. If Twisted Matrix was implemented in Ruby it would be advertised as the second coming of Christ. 🙂 Jokes aside, I feel that the Python community has a very good attitude which is in no way altered by the Django one, because it happens to share the same traits. There are no exclusive private clubs or the feeling of experiencing a technological “gold rush”, even though the community is in no way smaller. This may seem like a minor point, but for many the maturity, pragmatism and attitude of the community is a big selling point for Python/Django.
I’ll refrain from indulging in a full length comparison of Rails and Django. But I must briefly mention that Django takes the cake when it comes to creating applications that do web publishing (for obvious background reasons). Despite attempts to put Photoshop online, I feel that most of the web is still about publishing and interacting with published data. This makes Django a good choice in most cases. Of course, should you develop a web application that intends to replace a desktop app, Rails will most likely have the edge there.
So what does this mean for me personally? I’ll use them both, as I’m a firm believer in using the right tool for the right job. I’ll give you an example. Stacktrace.it is a small revolution in the Italian IT publishing world. A few months ago I contacted about 30 people from amongst the best Italian hackers and IT professionals and I proposed that together we create a site in which we’d promote and influence software development and IT in general in Italy (even if I live in Canada myself). The site has been going very well and has attracted a group of highly technical people who follow and contribute regularly with high quality articles. The code was based on Luambo, an open source blog engine yet to be officially packaged and promoted to the world. What was remarkable about it was that most of the new features that were requested in our private mailing list ended up in the code in less than five minutes. An unbelievable level of productivity. Even our designer, who was not familiar with the language or the framework, was easily able to work on the project. Guess what? Despite loving Ruby and Rails, when it came to deciding on the framework and language to be used for that project, I strongly pushed for the adoption of Django and Python, and not Ruby on Rails. It was simply the right tool.
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.
I’m considering python and django much more seriously than I have since I’ve started playing with rails. Before that, I didn’t take interpreted languages seriously for building production apps. (a bias I got from vbscript and asp.) But I started looking for some new non-MS tech to teach myself and saw all the rails fanfare, so I tried it, liked it, and see the productivity benefits to it.
This article is quite good.
I must however protest against the notion that there is a blurring between the rails community, and the ruby community.
There never was a unified community. There were rails-only people, there were ruby-only people, and there were those that used both. Rails was a huge framework, it requires a lot of know-how to survive therein. And it requires to understand ruby as well.
From my point of view, the rails community attracted too many people in a short time that literally swarmed with rails-specific questions, into the ruby community. It felt as if the rails people did not provide sufficient help or documentation to aid these people. It still happens all the time that rails-specific questions are asked on #ruby-lang.
However often it seemed that these hardcore-rails people also did not understand ruby, and did not care about other things that makes ruby a great language. Just take away rails and look at ruby – is it still a good language?
For me it was. I compare ruby to php and writing a wrapper towards ruby’s internal cgi still beats php with ease. PHP is a shame.
Compared to perl – ruby is much much nicer. Perl will lose.
Compared to python – this depends. Python is an acceptable language. I think it is silly to make a ruby vs python flamewar, like zed shaw does.
In a way, the separation of communities, is still the same… But I think we should not let single people attack communities in a unified manner. This is totally unfair to the different people and their views.
For example:
You might see that the rails-community has a problem, but whenever someone claims that the folks that use ruby (who were there long before rails came), have a problem too with THE LANGUAGE RUBY – that is simply not true at all. Just because rails exists does not change how ruby is a single iota.
With guys like zed shaw I dare claim that he even purposely denies certain aspects that do not fit his argument.
This is very irritating.
People rally behind points and extend them towards others who have nothing to do with decisions done by i.e. in this example rails.
They try to coin derogative terms like “monkey patching” and claim that their statements are true.
Anyway, I think your blog was one of the better ones in the last few months about all these issues. And personally I think that Rubinius will break a LOT more ground than rails – but without the hype that the rails generated.
Agreed. I started out experimenting with building some apps with Ruby on Rails, learned that I love dynamic languages, but found lots of limitations using Rails.
So, I began to research things and found Python to be a better fit for what I was doing. Django looks well-suited for CMS-style systems, but that’s not what I’m doing. It turns out that TurboGears (which will soon basically be a layer combining Pylons, SQLAlchemy, and Genshi) was exactly what I was looking for. I discovered a great Python environment via RoR…
I work mostly with Python and Zope 3, but also a bit of Rails. My feeling is that Rails hasn’t had much influence in the Zope community. This is unfortunate, because Zope 3 has a long way to go in the way of AJAX and REST support. There is some active work in these areas though.
I haven’t looked closely at Django yet, but that’s next on my list. I suspect I’ll find more similarities to Rails than to Zope 3.
Nice article. re direction of switchers, there’s still seems to be way more jobs for Rails than for Django (or at least way more postings), thus I feel a slight temptation to learn the prior. Don’t think it will actually happen though.
Really I just wanted to post to see what shows up for me in your little characterizing icons! (I’m at work. What shows up is not my fault.)
Very good post but I just want to add that the biggest advantage of python in my opinion is that we have that kick-ass module and package system. Because monkey patching is something no Python programmer wants to do unless he has to workaround bugs in libraries, we have a huge compatibility between libraries.
While django does have a single-application concept, all of the cool libraries I work with do never modify a singleton object somewhere so I can use “multiple instances” of the library in my project. For example SQLAlchemy allows me to open multiple connections at once and they will not interfere, likewise can I use multiple Genshi/Jinja/Mako whatever configurations in the same project etc. I can even have multiple WSGI (via Pylons, Werkzeug, Paste, or custom) applications and instances of them in the same interpreter. This is a huge plus point for me because of so many reasons, most important because it allows me to “install multiple versions” of the application for different users without wasting more memory or combining applications with similar setups in one python process.
While this of course has nothing to do with the language as such it’s the community that designs libraries like that. And probably also the module system which makes it hard to impossible. And because of the same package system and the inability to reopen classes automatically it gives you a strange (and this is good) feeling when doing monkeypatches.
I’ve had a couple of situations in Ruby when a piece of code required some modify on objects applied by some other library not loaded in that module which made it sick to debug. And especially Rails is the best example for misuse of monkeypatching as it’s extending *all* the builtin objects by at least ten methods each. (Not exactly true, but you get the idea). Even nil behaves different after Rails is loaded.
Oh. And here the missing disclaimer: I love Ruby and the Ruby community. The language is fun and I love working with it. And that was no joke 🙂
You should check out Seaside if you really think that:
“… most of the web is still about publishing and interacting with published data…”
http://seaside.st/
If you want to see what it’s capable of just take a look at Dabbledb
http://dabbledb.com/
On the twisted matrix comment, have you seen eventmachine, rev, packet, etc?
raggi, I’m aware of these nice projects. 🙂 Unfortunately they are not as mature, complete, fast and reliable as Twisted Matrix.
I agree with the general sense of this article: I discovered Django after first hearing about Ruby on Rails, and then searching for an equivalent in Python (since at the time I knew that Google was big on Python). I haven’t looked back since.
Thank you for a fascinating and balanced point of view. As computer science graduate and for many years a medical doctor, I tend to see programming now more from a hobbyist’s perspective. I too have been amazed by the wealth of educational tools made available to novices by the Python community. This gives the casual observer the impression that, besides being more mature, that this community is more academically inclined and that it has a rich scientific application base. I do see something of a trend in that direction beginning now also in both the Ruby and Haskell sites that I visit. This is to be commended. (Viva Italia! – from Hamilton)
Why didn’t Zope popularize MVC since it came along long before Rails? I suspect it is because Zope is a much larger framework with a higher learning curve. But the Rails folks will end up re-inventing the wheel long before the Zope folks because Zope has so much more to it but is proportionally more complicated.
how is ROR much more appropriate than Django when developing desktop like web application?
@Julian Bonilla
“My feeling is that Rails hasn’t had much influence in the Zope community. This is unfortunate, because Zope 3 has a long way to go in the way of AJAX and REST support. There is some active work in these areas though.”
Rails has had influence on Zope in the form of Grok, from the original Grok design notes: “How does Grok aim accomplish these goals? We will try to follow the guidelines that work for Ruby on Rails: * DRY: Don’t Repeat Yourself * Convention over configuration”
http://svn.zope.org/grok/trunk/doc/design/grok_dev.txt?rev=72797&view=markup
Grok also has built-in REST support, and projects such as megrok.kss are providing integration with AJAX libraries.
http://grok.zope.org
@Tracy R Reed
“Why didn’t Zope popularize MVC since it came along long before Rails? I suspect it is because Zope is a much larger framework with a higher learning curve. But the Rails folks will end up re-inventing the wheel long before the Zope folks because Zope has so much more to it but is proportionally more complicated.”
Zope 2 began life as a web application, which was morphed into a framework. The original design was conceived in 1996, but it wasn’t very MVC. Model objects could publish responses directly. Often in Zope 2 you just had a Model and a Template (and some Python Scripts floating around in acquisition-land …). Zope 3 corrected all of these problems, but because it was a complete re-write many migrated to other projects in the meantime.
While Zope 3 has lots of great features, it is easily the “least approachable, least marketed” of the web frameworks out there (it doesn’t yet even have a proper web site!). It’s not the least developed though – the recent Snow Sprint 2008 had 50 developers in attendance for a week, I don’t think Rails has had sprints of that size? I would suspect that the main Zope source trees get more commits than the main Rails source trees.
http://www.openplans.org/projects/snow-sprint-2008/project-home
Zope also still has the whole object database as the default persistence mechanism. While many developers find working with object databases pretty awesome (good-bye complex ORMs!), there are a lot of people who are most comfortable approaching application development with an SQL schema as a starting point.
Work is being done to make Zope more approachable in the form of the Grok project.
http://grok.zope.org
Hey Kevin, thank you for your informative comments. 🙂
I’m a die-hard python guy that’s used Django quite a bit. Recently, I decided I’d give Ruby another try (the 3rd? 4th?). There are a couple of features of Ruby that really appeal to me, and I’m hoping that Py3k fixes a few of the warts of the Python language.
Concerning Ruby, the past couple of weeks I’ve been using Merb quite a bit. I’m liking the simplicity and functionality of Datamapper and loving the form of Haml.
For any large project, I would choose Python over Ruby in a heartbeat. Any language can be “ugly” and “confusing” but between Py and Ruby, to me, Python’s going to end up with more straightforward and maintainable code. A lot of times the ruby community seems to like to perform little tricks which are great for golf, but for maintainable code I’m going to look at 6 months from now, Python is it.
You’re completely right about the Python community being understated and placing an emphasis on code over marketing. It’s a tragedy that the squeaky wheel seems to get
the attention, although I love to see where Ruby will end up in a few years, as it’s got a lot of potential.
Side note: One thing about Ruby that really bugs me…
Many good points, Antonio (as usual!-), but Python does not have just “_A_ good implementation”: it’s got _several_. Ted Leung has just been hired by Sun to make Jython a top-quality implementation; Hugunin already did that for IronPython for Microsoft (now at the heart of Silverlight, with Hugunin getting responsibility for dynamic languages on CLR more generally, just as Ted will at Sun for dynamic languages in general on JVM), the pypy folks are getting many interesting results, and Nokia’s Python-on-Symbian, while definitely not perfect, is still a decent way to get some stuff running on many smart phones. Now these (as no doubt the “solid implementation” you mention, Classic Python aka CPython) are all implementations of Python 2.*, and it will be fun to see how long similarly widespread implementations of Python 3.* (aka Python 3000, or, as GvR’s new vanity license plate on his new red Prius puts it, “PY3K”;-) take to emerge (less than Perl 6, one hopes;-). I could care less — MY (and my wife Anna’s!-) vanity plate (on our boring 3-years-old silver Prius) is P-(heart)-THON… “all is grist that comes to this mill”!-).
As the “capelli d’angelo vs spaghettini” quote reflects, I like Ruby (as a language) almost as much as I like Python, but while Rails is STILL ahead of Django as a quick-deployment Web framework (IMNSHO), in almost all other “practical deployment aspects” Python has serious advantages (though by the time Hugunin and Leung, oops I mean Microsoft and Sun, are through with their challenge about dynamic languages on their respective virtual machines and tools/platforms, who knows what the state of the world will be — maybe the playing field will be flattened out, or maybe it will be further tilted Pythonwards…?-).
Alex
Hey Kevin, thanks for saying most of the things I wanted to say about Zope and Grok. Zope has been around for about 10 years now. Zope 2 (for all its flaws) had very powerful features very early, such as object publishing, and is still in some ways “in the future” with its seamless persistence with its object database. This is part of the reason of why it is still relevant. Another reason is its continuous struggle, and success, in evolving forward: one of the hardest challenges for any application framework.
From the perspective of Zope’s experience it’s interesting to watch the relative youngsters like Rails and Django. Things sometimes look a bit familiar. Zope had its early wave of massive attention back around the year 2000. We got the hype, and the backlash, and the isolation from the Python community, and the coming back to the Python community, and the reinventions and the re-reinventions.
The Zope community developed a real appreciation for the value of strong test-driven engineering, explicit interfaces, consistent application buildouts, and of long-term flexibility and extensibility of applications using a general component and pluggability framework. At least some of these experiences will need to be re-experienced by newer communities. The word “monkey-patching” was developed years ago in the Zope community, and while useful doesn’t treat it as a general mechanism for extensibility, for instance. 🙂
We’ve built important community infrastructure such as a business network and a foundation. We’ve had the experience to try to keep Zope relevant: Zope 3, Zope 2’s evolution to adopt Zope 3 technologies, and now Grok to try to make Zope 3 technology more approachable (learning some lessons from Rails, indeed).
In many ways I think the newer frameworks are still going to tackle some of these issues. Framework evolution is hard. Meanwhile we also don’t forget to learn valuable lessons from the newcomers – the value of agility, ORM integration (besides the object database), and marketing. Rails has been good for Python web frameworks in more ways than one.
Nice points Antonio, I’m 100% with you 😉
For me:
1) The reasons why Ruby is now so popular is because of Rails. If DHH would have chosen Python for writing Rails, a lot of people would ignore what Ruby is
2) I agree with Kevin: Zope is the only complete web framework at this time, but because of its complexity and the not-RDBMS architecture has a limit success
It has made ruby a bit more complicated though in some ways. But I have been using rails ever since. It is a blessing of sorts, really.
One point is that Ruby does *not* act more functionally than Python. You can pass functions as first class objects and there are actual immutable types in Python (tuples). Just my two cents.
I would like to strongly disagree with the contents of this article. I think its written to please the python enthusiasts.
Performance, deployment is rails ..
I/O threading are all issues mainly associated with ruby and that where the catch is. Problem found is 90% of the problem solved.
Rails has a very strong community thats getting stronger as i write this.
Whats happening with ruby:
1. Threading: A lot has been solved and will get solved when 1.9 comes out you have kernel threads YARV is implemented
Python style Global Interpregter Lock on threads 😉 which will be improved further as i speak the Jruby team is researching having Multiple VM’s and i know for certain a lot of things are going to change.
I/O : You are getting revactor to kick ass of all I/O using this actor model implementation
http://revactor.org/philosophy/
this is used in languages like erlang and scala..
Revactor “able to run Mongrel, using Actors instead of threads as the
underlying
concurrency mechanism. Initial tests of the performance of Mongrel on
top of
Revactor surpass the threaded version.”
Hence, mongrel,ngnix will start scaling better
Garbage collection: Should i tell you that in ruby GC was never an issue however, rails applications need the GC to be configured a litle bit differently and DHH’s love with symbols “was” so as i said problem found is problem solved its performance all they way these days.
Coming to rails: version 2.0 edge is nothing but performance improvements..The future can be nothing less than super fast with these brilliant minds (ok extra brilliant ) working and thinking about performance..
Deployment : If you can’t get the grasp of it just use jruby and goldspike war files over apache tomcat..
I personally have never had any issues with deployment of rails applications there are good books and resources out there. Thing is its changing and improving so fast I hope Django/Python catches up, if at all it ever will i doubt.
The only good thing about this article is that it highlights the fact that ruby on rails is mainstream..6 months on it will be dominant.
Like it or not rails cant be good for python because it was never written in Python anything else can only keep catching up..
for those who still have a choice to make..
Ruby/Rails is more about marketing than about code? Oh, c’mon! That’s not even an argument.
Rails was just code, then it got attention and then the marketing begun: you can’t “sell” a framework without marketing, most decision makers aren’t coders. It’s all about balance.
And that’s the “problem” with Django. It has the good (“beautiful”) code, but it lacks the marketing (I’m talking about good marketing, not about business bullshit) or someone like DHH. 🙂
It’s funny… Rails is precisely the reason I learned Python. My reasoning was thus:
(a) I need a web framework.
(b) I am so tired of perl.
(c) Rails looks cute, and there’s so much hype. Let’s check it out.
(d) I don’t really want to learn a language for just one framework. (Ruby is good, don’t get me wrong. I used to program in Eiffel. But…)
(e) Let me check out python again.
(f) After some fudging, I like python more than Ruby. Also, there seems to be more _general_ usage of python than there is of Ruby out there.
(g) Oooh, what’s this Django thing?
The end result is that, 9 months later, I’m deeply in love with python and I’ve written four substantial django-powered apps.
Thanks Rails!
Hi,
I get so angry at Python that I can’t program in it. It’s a personality defect that I have. If I can’t program, threads and IO don’t matter.
Personally, I’ll pick Ruby’s shaky elegance over Python’s diesel-powered buttplug any chance I get.
That’s why I’d hail Twisted Matrix, whatever that is, if it’s presented to me in Ruby: “Hey, a version of Twisted Matrix that I’ll actually use!”
Ps.: don’t forget to parse the whitespace in this message. It totally changes its meaning.
Lucas wrote: Ruby/Rails is more about marketing than about code? Oh, c’mon! That’s not even an argument.
That’s not what I said nor what I meant. Rails is an incredible framework and Ruby is my favorite language. They are both fantastic. But you must admit that, sometimes, Rails was sold by some as the solution to all the web development problems, which is not accurate.
To be honest, eventmachine, revactor etc are not as immature as you may be giving them credit for.
We’re using eventmachine in production, and it’s massively more stable than a comparable service written in pure ruby using threads or whatever processing paradigm on the pure ruby socket interfaces. (And I learned this the real hard way).
You’d be right in saying that there’s a signficant requirement for more protocol implementations and framework extensions for use by ‘the common man’, but other than that these async frameworks are pretty damn good.
Kirk Haines among other people, has software that will happily drown a 100mbit pipe. Almost no one who posted here ever fills a 100mbit pipe. Performance under such conditions is largely a non-issue, and it’s pretty damned fast anyway.
Developer purpose often leads to the state of the libs, and here’s another good example, for python this time:
http://wiki.secondlife.com/wiki/Eventlet
Now, with regard to benchmarking of these things, there’s never a substitute for proper design. You can’t expect the framework to deal with attempts to send 5 byte packets on it’s own. That’s something the developer needs to consider at design time, whether thats behavioral design at implementation time, or design time considerations for teams that know they’ll be stressing a system.
Sure, Antonio. But I think that this is a problem with people. “Blind” people tend to sell their favorite language/platform/framework as a silver bullet. Even in the Python community.
Or you could just say that Rails really is a solution for all the problems you had before using it. Now you got new ones. That’s software development after all. 😉
I agree with Kristleifur, that Python is “a joy to program in” only for people who are already used to it. Abstract, hypothetical reasons why Ruby can’t do X well don’t really matter, because Python syntax and semantics suck (why anyone thinks import something is more or less magical than require ‘something’ is beyond me). Ruby teaches you to use lambdas right out of the box while in Python they’re considered advanced play because of the awful (magical) syntax for creating them. Ruby doesn’t even have a name for list comprehension because there’s an actual method on lists called (mysteriously) ‘collect’. All the arguments made in favor of Python can be made for PHP (good community, it scales, it’s mature, “understandable” idioms), but that doesn’t sway pure Python developers, because they don’t like thinking in PHP.
Perhaps my point about list comprehension should have been that Ruby doesn’t need a special syntax, because collect/map is so intuitive.
Joseph,
Perhaps it is because list comprehension is so intuitive in Python that it doesn’t need some special built-in functions?
See http://www.artima.com/weblogs/viewpost.jsp?thread=98196