Python vs Ruby, slightly more in-depth

http://rapd.wordpress.com/2009/07/13/python-vs-ruby-slightly-more-in-depth/

by edw519 • 17 years ago

52 56 17 years ago

rapd.wordpress.com

utku_karatas2• 17 years ago

> Decorator is Python’s implementation to visitor pattern...

huh?

didip11• 17 years ago

Visitor patterns add new functionality to existing object structure [http://en.wikipedia.org/wiki/Visitor_pattern].

Python decorator does not do that?

tetha3• 17 years ago

The decorator syntax

  @decorator2
  @decorator1
  def foo(*args):
      pass

is just a shorthand for

  def foo(*args):
      pass
  foo = decorator2(decorator1(foo))

I completely fail to see the visitor pattern here, even with stretching until breaking.

xtho• 17 years ago

The comparison is slightly tendentious in that the info on ruby isn't always up to date (eg "Modules" and "HTTP and other Internet stuff").

nudded• 17 years ago

I quite hoped to be reading an in-depth comparison, but this article merely scratches the surface. What I would like to see from an in-depth article is actual code implementing stuff, showing the features a language has (and comparing them with each other).

I don't think this is a good article nor a useful one.

Torn2• 17 years ago

+1, the article is a 10-minute gloss at best and has virtually no content or analysis.

I mean come on, just look at the 'conclusion': These languages are interchangeable, especially for building web application. Neither are more awesome. They get the job done and they make programmers happy.

davidw• 17 years ago

Having used both professionally, I think that's a pretty good conclusion, actually.

roder• 17 years ago

The conclusion isn't wrong, but the content is weak for the evaluation.

At this point in the Ruby VS Python conversation, my expectations for an evaluation are benchmarks of code that is algorithmically identical. If one language provides for a better algorithm than the other, I'd like to see those differences as well.

didip11• 17 years ago

It is intended to be a gloss over of functionality that I use frequently. If I want to write much more in-depth comparison then I would have written these (which I may in the future, these kind of blog post takes time to write):

* Beautiful Soup vs Nokogiri/HPricot * Fabric vs Vlad * Paste vs Mongrel performance using proxy pass behind Nginx * (I am not going to write Rails vs Django)

gaius• 17 years ago

Also he's rather overlooked that the web is a tiny corner of the Python world. Ruby has nothing that's even close to NumPy/SciPy.

didip11• 17 years ago

Poster here,

I intentionally downplay what Python has to offer. It is true that Python has greater breath than Ruby in terms of communities, especially outside web world.

If I started to mention those, it will make Ruby looks less capable (or I would naturally skew the article biased towards Python).

DocSavage• 17 years ago

The PLEAC codebase was new to me. It reminds me of the idiomatic python reference (http://python.net/~goodger/projects/pycon/2007/idiomatic/han...) I've found very useful, but haven't delved into PLEAC to see if the coding examples are truly idiomatic.

Python > http://pleac.sourceforge.net/pleac_python/index.html

Ruby > http://pleac.sourceforge.net/pleac_ruby/index.html

Coverage varies depending on the language.

ivanyv2• 17 years ago

There's this site where you can compare implementations of several patterns in different languages... If only I could remember where... anyone?

projecktzero• 17 years ago

Are you talking about Pleac http://pleac.sourceforge.net/

ivanyv2• 17 years ago

That's it! Thanks!

redmage• 17 years ago

Was this it? http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

FooBarWidget• 17 years ago

"Testing Ruby wins a lot of TDD practitioners. There are plethora of Ruby modules created for making testing experience truly wonderful. See: RSpec, Shoulda, Factory Girl, Selenium."

Yes, testing in Ruby is absolutely wonderful. It makes writing tests an enjoyable experience compared to pretty much any other language I've used. Nowadays I strive for 100% C0 testing coverage and near-100% C1 testing coverage whenever I write software. This can be done very easily in Ruby but is hard to very hard in most other languages.

jrockway3• 17 years ago

It's very easy in Perl.

But anyway, "100% code coverage" is very misleading. Sure, every branch might have been executed once, but you don't ensure that every combination of branches executed once. If you have state that can be shared between code paths, then you are not doing an adequate job testing.

(This is why people like functional programming. One input always produces the same output, cutting the number of cases you have to test dramatically.)

tilly• 17 years ago

Writing tests is only good if people actually run them.

The default configuration for RubyGems doesn't run unit tests. Therefore unit tests provide a sophisticated check for, "Works on my machine" but isn't so helpful for getting good bug reports about what doesn't work on other people's machines. By contrast the default configuration for Perl's CPAN runs unit tests before you install anything, and this has been the default for Perl modules since the last millennium. (Actually unit testing has been part of Perl culture since 1987! Yes, the "make, make test, make install" idiom was in the first release of the Perl core. This was over a decade before Kent Beck began popularizing the idea for a broader audience.)

And it doesn't end there. For instance the Ruby world has no real equivalent to CPAN Testers. That's a distributed group of people who run all of the unit tests on all of the CPAN modules on different platforms and make publicly available reports of success/fail. That project runs nearly a half-million test suites per month. Which makes it possible to do things like dependency analysis on CPAN modules to track down who is causing what other modules problems. See http://ali.as/top100/.

In short I'm glad that you're doing unit testing and like the tools that Ruby offers for it. However if you're open to cross-pollination, there ARE things you can learn about unit testing from other language communities. Some of them might be great additions to Ruby.

ovi2562• 17 years ago

He mentions Python's GIL (which makes multi-threading completely useless), but Ruby (even 1.9) has a GIL too [1] that works exactly the same (awful) way. Ruby 2.0 will have it too [2]. A new Python implementation, unladen swallow is developped by Google to adress exactly this issue. Python-stackless avoids this problem, but the paraigm change is huge, 'normal' code has to be largely rewritten for stackless.

Note that, if I correctly understood, python event engine Twisted uses a custom C-implemented event loop to avoid this.

[1] http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ru...

[2] http://groups.google.com/group/comp.lang.ruby/msg/e809a7a720...

Wow, seems like MacRuby uses OS threads and completely abolished the GIL [3].

[3] http://www.infoq.com/news/2009/06/macruby-drops-gil-threadin...

dkersten3• 17 years ago

The GIL (in Python, can't speak about Ruby) is a controversial issue because people assume its bad and Python is therefore bad at concurrent programming etc. Without the GIL, the implementation would be drastically more complex and slower because all built in datatypes, dictionary lookups (for method lookups) etc would need to be made atomic, through locking. I think I can live with the GIL in this case - use threads for asynchronous (rather than parallel) code and use processes (and Python 2.6's multiprocessing library makes this easy) for parallel code execution.

Having said that, I welcome Google's unladen swallow and hope they succeed in removing the GIL.

ajross• 17 years ago

That's not strictly true. Take a look at http://plausible.org/nasal for an example of an interpreter (mine) in the same broad space as Python and Ruby, yet without a global lock for anything but garbage collection (fixable -- there's no reason in principle preventing a concurrent GC from being dropped in). In tests of CPU-bound code without excessive allocation, it scales to 4-way SMP without trouble.

codahale• 17 years ago

FWIW, JRuby does not have a GIL, plus you get to use java.util.concurrent.* classes in your Ruby code.

ubernostrum2• 17 years ago

Jython doesn't have a GIL either. Nor does IronPython.

bendotc• 17 years ago

"Python-stackless avoids this problem"

Not really. Stackless Python still has a GIL, and if you want to make use of multiple threads, the GIL will still bite you.

Stackless allows you to write coroutines and has lots of cool abilities, but avoiding the GIL is simply not one of them as far as making use of multiple cores.

jrockway3• 17 years ago

Why is everyone so concerned with multi-core concurrency withi languages like Python and Ruby? Adding another processor will get you, best case, a 2x speedup. Rewriting in, say, OCaml or Haskell will get you a 25x speedup.

25 processors buys you a lot of programming time.

lacker• 17 years ago

Adding another processor to my computer is quick and easy. Rewriting an application in another language is slow and hard.

ovi2562• 17 years ago

  Both still needs javascript to make awesome looking web applications.

Not so much "looking", as js would not help with that, but working, yeah.

chriseppstein• 17 years ago

> eval()/exec() are simply evil in both languages. They make debugging more difficult.

I stopped reading at this point. More complicated debugging is a reasonable tradeoff for intuitive APIs. To call them evil indicates the OP is quite inexperienced.

jamesbritt3• 17 years ago

This suggests an important difference in the cultures around the language.

didip11• 17 years ago

That statement comes from personal experience where some functions did not exists in the eye of text editor because they were defined inside a string.

Not that big of a deal, but enough to annoy me.

bmelton• 17 years ago

Not that big a deal != evil.

jamesbritt3• 17 years ago

"Reflection a.k.a Meta Programming a.k.a Monkey Patching"

Really? These are all the same thing? I think not.

"Python comes with webbrowser, urllib2, smtp, http, SocketServer, HttpServer, and more, while Ruby only has net/HTTP"

Untrue. Seems the author knows Python, and spent a little time with Ruby.

More useful points to make would have been how objects are implemented, how inheritance and mixins are handled, and the key paradigms in the language (e.g., in Python, foo.bar() means invoking the method bar; in Ruby, it means sending foo a bar message.)

dkersten3• 17 years ago

Agreed. Reflection != metaprogramming != monkey patching. They are loosely related, but FAR from being the same thing.

didip11• 17 years ago

That is correct, they are not the same thing. That statement is coming from my use case, where I, have so far, only use them for manipulating objects during run time.

Be it calling function, setting attributes, or adding extra functionality by including modules.

jamesbritt3• 17 years ago

"That is correct, they are not the same thing. That statement is coming from my use case, where I, have so far, only use them for manipulating objects during run time."

So here's my main complaint: If you know that these things are not really the same, why do you present them as if they were? You would have had a much more favorable reaction had you been more upfront on your biases, limited Ruby experience, and narrow focus for comparison.

davepeck• 17 years ago

I'm currently working on a python web project; the lack of a mature, battle-hardened payment library kills me.

Ruby's ActiveMerchant is a well-crafted bit of code. The handful of python contenders I've discovered are (1) immature and often poorly coded, and (2) unable to touch ActiveMerchant in terms of number of supported gateways and features supported per gateway.

trop• 17 years ago

RE daemonizing, Ruby 1.9 does have a nice Process.daemon function (this is what the author is hoping for?). I'm also a big fan of the 1.9-introduced spawn() function. Not only does this make it easy to create background processes, but via its :in, :out, and :err options (also now found in system() and exec()) it's pretty easy to pipe one spawned process's output to another.

OTOH, I'm a big fan of the What's New in Python X.X articles. Nice features like spawn() seem to sneak into the Ruby codebase unheralded and practically unnoticed.

richcollins• 17 years ago

He neglected to mention Python's lack of anonymous functions. (and no, lambda doesn't count given its restrictions).

didip11• 17 years ago

Functionality that I do not mention means that I don't have to use them often, both for work or personal projects.

I don't miss anonymous functions that much, yet, because I have inner function and list comprehension in Python.

wooby• 17 years ago

  Python                 Ruby
  map                    collect,map
  lambda                 block
  filter                 select
  ?                      reject
  reduce (functools)     inject (native)

Guido van Rossum on inclusion of 'reduce' in Python 3.0, in 2005:

"This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly" (http://www.artima.com/weblogs/viewpost.jsp?thread=98196)

Ruby lets you do it however you want to. I don't see myself learning Python any time soon.

jerf• 17 years ago

I think it's pretty clear that one person isn't going to be able to write the article we're all actually looking for. We need to get two experts together, one in each language, and in the spirit of respect and discovery, have both people put their language's best foot forward, to try to "get" the other language but to not descend into endless wankery about the details.

But, honestly, I know how it would turn out: The technical considerations are not all that different. Most people who bitch about one of the two and praise the other seem to not understand the one they are bitching about, and the pattern is strong enough at this point that it should be considered the norm. I'm tired of Ruby advocates who seem unaware that yes, Python can pass functions as first class arguments and yes, that pretty much is a block, and tired of Python advocates who get shredded in the comments for obviously having only gone through a Rails tutorial.

In the end the big difference is community. I think there is a big difference there. I'll skip igniting a flamewar by trying to characterize the communities, since it is impossible to do that neutrally, but there's definitely a difference I can see.

Python vs Ruby, slightly more in-depth

Related Stories