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

On Fri Aug 25, 2006 at 04:03:41PM -0400, Jake C. wrote:

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

On Aug 25, 2006, at 4:03 PM, Jake C. wrote:

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

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
YARV: Yet Another Ruby VM

On my hardware, the included benchmark suite says:
> 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

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

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

appealing to authority isn’t a valid argument.

Oh yeah, and

WTF WITH ALL THE 'self’s !!!

Sorry, had to get that off my chest.

Jason

On Aug 25, 2006, at 5:00 PM, Jason R. wrote:

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.

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

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).

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

On Aug 25, 2006, at 4:54 PM, Tamim A. wrote:

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

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

-faisal

Faisal N Jawdat wrote:

On Aug 25, 2006, at 4:54 PM, Tamim A. wrote:

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

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

-faisal

:slight_smile: It is not python or ruby or anything; it is what you selected for
the appropriate situation what matters. So, what NASA had been or has
been selected should not be so much important while defending the
features of a language above the others.

Regards

“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

Howdy,

For me Ruby is like a new girlfriend.

LOVE at first sight.

There is nothing that comes between us. :slight_smile:

This language just clicked for ME.