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