Why one person chose python over ruby

Interesting article…I don’t agree with many points, but thought I’d throw it out there for discussion. Some points he makes hold some validity…

http://jesusphreak.infogami.com/blog/why_py

i think this is worth reading. his points about speed and language support deserve consideration.

for what it's worth, ruby 2.0 is supposed to improve the speed situation somewhat:

http://wiki.rubygarden.org/Ruby/page/show/Rite

"when it becomes available"

-faisal

"you have Python being used at places like NASA using tools such as
NumPy, and Google."

appealing to authority isn't a valid argument.

Interesting article....I don't agree with many points, but thought I'd throw
it out there for discussion. Some points he makes hold some validity...

yeah. i disagree as well. ive used python for a few months, after switching off of perl and before switching to ruby, and what annoyed me most was the annoying C++-ness of the whole thing. the weird __self__.__init__ looking crap, the mandatory indenting (and combined with not much use of inline blocks and yield like is so common with TCL or Ruby, meanas you quickly have ot deal with its confusing OO system (for me anyways) and continaully refactor into tiny defs to avoid ending up with lines that dont start halfway across the screen). plus stuff like i == a ? b : c didnt even work (although i was told in their IRC chan it was being added)..

theyre both slow. if you want fast, and dont like C, try OCaml..

disagree on the library support too. they both have wide support these days

plus pythons re suport is really _Weird_ compared to perl or ruby

whoever thought re.compile(r"" + junk + "",re.I) was better than
/junk/i was smokin somethin

Yeah, and NASA also lost a couple of Mars landers... hmmmmm.

jdonnell wrote:

That wasn't Python, it was Martian anti-aircraft fire.

-faisal

The bigger problem I see with this guy’s article is that he doesn’t take into account timelines. Python has a few years over Ruby when it comes to ‘going mainstream’, so obviously the library support isn’t going to be there. Also, libraries only show up when people need them, and choose to release them to the public. Give Ruby the same amount of time Python has, and the libraries will come.

Personally, I hate some of the core choices made in Python. For one: not starting out as OO, resulting in global-level functions like len(), file(), etc which are not obvious. Also the choice of the backtick operator to mean convert-to-string is quite the sore point to me right now. I’ve become addicted to blocks; Python lambda’s just don’t cut it, besides them being very difficult to understand for a newb.

I’m quite confident that speed issues will be taken care of with the release of 2.0 and YARV (or whatever it’s called then). This also goes back to the time issue, but we all know that here.

In my mind, Python is a very competent language, but it has quirks and ‘gotchas’; coming from Ruby that drives me nuts.

Jason

Oh yeah, and

WTF WITH ALL THE 'self’s !!!

Sorry, had to get that off my chest.

Jason

Well, given that he's expressing his preference for what to use now, this makes sense. Otherwise he has to make a comparison with what Python is now vs. what Ruby might be in 10 years. Also, Ruby in 10 years doesn't solve his problems for another ten years.

Language preferences are so often a matter of taste, I find it very hard to criticize them.

-faisal

for what it's worth, ruby 2.0 is supposed to improve the speed
situation somewhat:

http://wiki.rubygarden.org/Ruby/page/show/Rite

"when it becomes available"

You can try it now:
    http://new.ruby-lang.org/en/community/ruby-core/#following-yarv
    http://atdot.net/yarv/

        > ruby -v
        ruby 1.8.4 (2005-12-24) [i586-linux]

        > ruby-yarv -v
        ruby 2.0.0 (Base: Ruby 1.9.0 2006-04-08) [i686-linux]
        YARVCore 0.4.1 Rev: 540 (2006-08-20) [opts: [direct threaded
code] [inline method cache] ]

                          ruby yarv
        app_answer 1.443 0.218
        app_factorial 0.035 1.004
        app_fib 15.594 2.770
        app_mandelbrot 4.241 2.310
        app_pentomino 214.488 96.757
        app_raise 4.795 3.954
        app_strconcat 2.760 2.784
        app_tak 18.790 4.152
        app_tarai 15.714 3.354
        loop_times 13.789 6.018
        loop_whileloop 26.727 2.470
        loop_whileloop2 4.347 0.842
        so_ackermann 37.346 4.198
        so_array 21.434 7.833
        so_concatenate 5.305 1.626
        so_count_words 1.987 0.565
        so_exception 6.639 5.903
        so_lists 2.457 1.499
        so_matrix 4.085 1.651
        so_nested_loop 13.095 5.104
        so_object 9.514 9.545
        so_random 6.802 1.926
        so_sieve 1.981 0.460
        vm1_block 66.413 8.651
        vm1_const 37.271 9.555
        vm1_ensure 54.518 3.566
        vm1_length 43.729 5.702
        vm1_rescue 24.385 3.090
        vm1_simplereturn 42.471 11.897
        vm1_swap 54.959 5.226
        vm2_array 9.407 5.570
        vm2_method 29.017 6.351
        vm2_poly_method 34.255 8.411
        vm2_poly_method_ov 9.708 1.469
        vm2_proc 14.769 3.472
        vm2_regexp 8.536 4.104
        vm2_send 13.186 4.608
        vm2_super 10.237 3.014
        vm2_unif1 10.129 1.627
        vm2_zsuper 12.350 2.837
        vm3_thread_create_join 0.025 0.214

Though my first attempt at YARV on Rails:
        > ruby-yarv ./script/server
        => Booting WEBrick...
        [...]/active_support/dependencies.rb:98: [BUG] Segmentation fault
        ruby 2.0.0 (2006-04-08) [i686-linux]

        Abort

Python might be a more verbose language than ruby, buts syntactic sugar
really that important? When I'm programming it is not the actual
typing that takes time, it's the formulating of the problem, writing
the code to solve the problem is only a small fraction of the actual
development.
One thing that can indeed be annoying in python is its indentation
based blocks, however using a decent ide, and the indentation will be
highlighted for you, never again you'll have to search for "where
exactly did my block end"

I've made one website with rails and ½ with django, however I
already used python for miscellaneous scripts. (Mostly I use(d?) php
and sometimes java). I fully agree that ruby is a beautifully language,
much nicer than python. Yet, after working with Rails, for more serious
projects I will use a python framework. Rails definitely redefined the
meaning MVC, but it is not that other frameworks, in other languages,
cannot create a similar experience. Webwork, my favorite java
framework, already ha\s the same philosophy as rails. True it requires
a bit more configuration, but that isn't its biggest problem. Its
biggest problem is that it is a java servlet, meaning that after
changing something dead simple, the compile and reload cycle starts.
Which means it'll take too much time to see your changes in actions.
However, python (and php), being scripting languages don't suffer
this, imho, show stopper.

As the original article points out python is more mature (more
libraries, better language support). For a project for which the
boundaries are not yet well defined (thus larger projects that will be
extended / under continues development) I'm under the strong
impression that choosing a python framework (django or maybe pylons in
my case) will save me from a lot of hair pulling in the future. (python
will still be there, in the same form; the framework will still work,
if I needed an advanced library it might very well be available:. All
these reassuring feeling rails lacks) Neither ruby nor rails feel
future proof. I admit it's also largely a matter of trust, and I have
some issues trusting Rails' developers (rails feels immature).

"Python might be a more verbose language than ruby, but is syntactic
sugar
really that important?"

syntactic sugar can go a long way. Why add a "break" keyword to a
language? Isn't it just syntactic sugar? I mean "it is not the actual
typing that takes time, it's the formulating of the problem". Instead
of "break" you could create a flag variable like this (in weird pseudo
code)

breakFlag = false
i = 0
while( i < someArray.length){
  unless breakFlag
    if somecondition
        breakFlag = true
    else
        #do some work
    end
  end
  i +=1
}

or you could just write this in ruby.

someArray.each do |e|
  break if someCondition
  #do some work
end

I think you gain a lot from "syntactic sugar" in this case.

My thoughts summed up as a terrible Haiku:

Python is pleasant
  but __self__.prefers Ruby. There's
  not so much whitespace

Cheers,
Max