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…
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:
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
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.
This language just clicked for ME.