TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ruby's not ready

54 pointsby glyphobetabout 17 years ago

23 comments

tptacekabout 17 years ago
From an ex-Pythonista a year in to Ruby, point-by-point:<p>* Ruby's Unicode support is indeed inferior to Python's; unlike Python, you need to explicitly use library calls to work with UTF-16 strings. Python does indeed bake this in to the language.<p>* I don't use multiline regexps. On the other hand, I do use normal regexps, all the time, and the fact that I don't have to call out to a library to use them, or deal with special "match" objects with their own API, is a plus. Ruby has more natural support for regular expressions than Python, where regular expressions are an afterthought.<p>* Ruby's documentation sucks. Full stop.<p>* I have no idea why I'm meant to care about what this guy thinks of Ruby 1.9 or Ruby 2.0. There's a Ruby 2.0?<p>* Python is way faster than Ruby. Not by a little bit.<p>* Ruby's scoping rules are a dream compared to Python's; it support real closures, instance variables and methods with encapsulation, and coroutines that were designed for more than just iteration.<p>* Ruby and Python are equivalent when it comes to internal consistency. Python delegates virtually everything to a sprawling standard library for which there is, most certainly, "more than one way to do it". Calling out the difference between "print" and "puts" is particularly amusing if you know how Python handles the same distinction.<p>* Ruby has a cleaner object model than Python, where virtually every feature of the language appears to have been built by exposing the raw symbol table to the language. The simplest way to observe the difference is by taking an existing class and wrapping it with an object that catches all method invocations, a la "method_missing".<p>* Both Ruby and Python support keyword arguments by giving functions a dictionary type of keyword/value pairs; Ruby has the added benefit of a Symbol type, like Lisp and Smalltalk. No Ruby program fails to use them.<p>* I'm guessing about, oh, zero people on Hacker News give a shit about SAP support.<p>* I never noticed that Ruby didn't print the actual line of code that threw an exception. It's true! Python does! I never noticed that, either! That's pretty neat.<p>* Apparently, despite having been largely ported from Rails, Pylons is more mature than Rails. Awesome.
评论 #157434 未加载
评论 #157405 未加载
评论 #157770 未加载
评论 #158321 未加载
nickbabout 17 years ago
I couldn't disagree more. Having tried both platforms, I felt like I was coding with one hand tied behind my back when I was learning Python, Pylons and Django. Web tools and the stack is a lot less mature than RoR stack and the amount of various plugins/gems available for both platforms was not even close. RoR plugins were so much more mature and multitudinous that after we started planning our app, we realized that we'd have to spend about 6 months(!!!) just writing the functionality in Django/Pylons that we were getting for free with Rails. Now this was about one year ago so things might have changed.<p>Since I don't have the time to go over each point that the author makes, I'll concentrate on a couple.<p>Lack of Unicode in Ruby 1.8.x. OK, so this might have been an issue before RoR 1.2 came out but since 1.2, RoR has introduced Multibyte and has been a lifesaver. Now, I don't have a clue how many Rails Unicode apps the author has written in his career but I can tell you for a fact that Unicode is not an issue in Rails anymore. We have an app in beta that uses Unicode for every string that we handle and we handle so many strings for so many languages that your head will spin. We haven't had any huge issues with RoR's Unicode support at all. So that argument is really a moot point.<p>As for language performance, who really cares?! Programmer's time is so much more expensive than servers so the last thing I worry these days is how fast some specialized benchmark runs. As long as the latency is acceptable and you can solve the problem by parallelizing it, the performance of an interpreter is completely irrelevant.
评论 #157369 未加载
tptacekabout 17 years ago
Well, this was interesting. My team just finished a Rails project that used Racc extensively (with multiple different grammars), made extensive use of cryptography, and spent several weeks up on blocks being tuned with ruby-prof.<p>Obviously, it also used ranges, keyword arguments (like <i>every other Ruby program ever written</i>), strings and string conversions, blocks, private methods, and yes, even Unicode.<p>I did notice that the documentation for these features was lacking. What I didn't realize was how much Ruby sucked, compared to Python.<p>I am now steeling myself to begin typing "self" in front of every instance variable, write ten lines of code every time I need a "method_missing", fish the gettimeofday equivalent out of 19 different libraries that return and manage time, re-learn whether I want to call popen, popen2, popenN, or create a Popen class, wrap my data types up in a list when I need code to close over them, condense all my anonymous functions to single expressions to work around Python's accidental support for lambdas (which, according to GvR, are evil), write my oh-so-thread-safe-code for an interpreter that serializes around a global interpreter lock, pretend that my classes have private methods by naming them differently, just like I do in my object-oriented C code, marvel over the amazing things I can accomplish with "generators", continue to format strings using "printf" semantics the way Kernighan and Richie want me to, and track down bugs that are literally invisible due to semantic whitespace.<p>Can't. Wait. You know what I miss most? Twisted.
评论 #168044 未加载
评论 #157907 未加载
SwellJoeabout 17 years ago
I haven't found the argument about backwards compatibility to be true of Python, but it has been true of Perl. Code that I wrote 5-6 years ago in Python has needed at least three updates to run in newer versions of Python (1.5-&#62;2.0 and 2.0-&#62;2.2 and 2.2-&#62;2.4--I no longer work in Python, so I don't know if they'd need an update to run on newer versions). On the other hand, code that I wrote ten years ago in Perl still runs unmodified on Perl 5.10. The only major upgrade problem I've seen has been the introduction of native Unicode in Perl, which caused anything that assumed scalars to be made up of 8-bit bytes to break, but that's a pretty broken assumption, anyway.<p>So, in short, I don't think Python is exactly a paragon of backward compatibility. It may be better than Ruby, but it isn't a solved problem.<p>I also disagree with the assessment that TIMTOWTDI is a bug. But, me being a Perl coder may have warped my judgment. I find Ruby very intuitive--moreso than Python, even though I've written more Python code than Ruby.<p>That said, there are some serious deal-breakers in Ruby. Lack of Unicode is one of them. I wasn't among the folks criticizing Arc when it didn't have Unicode at first release...but if it had gone more than a year without Unicode, I would have joined the bandwagon of critics. And, once again, I think Perl has solved Unicode better than Python.
benreesmanabout 17 years ago
While I agree that Ruby (in the form of MRI) is pretty limited in the kinds of production applications it's ready to support, I feel just as strongly that Python is an evolutionary dead end.<p>Personally I predict that JRuby (which addresses most of the issues listed in TFA) will become the mainline production Ruby. It runs adequately fast, and has JVM threading, meaning that ceteris paribus it is 'fast enough' for the largely IO-bound tasks that make up web-programming. And when you program in JRuby you find yourself leaning on the Java libraries for most of the heavy-duty stuff (say what you like about Java, I certainly do, but the libraries are abundant and abundantly production-worthy). Ultimately, when you've got lambda and reasonably low-impedance hash tables then you can make everything else, so there's a future for Ruby.<p>Python on the other hand is a lost cause. Objects are a valid and important ingredient in a balanced diet of programming abstractions, but 'object-oriented programming' is for idiots or assholes or worse. Objects as a first-class language feature are nice-but-optional, I've worked on large C systems written in an object oriented style (one was a simulation, another was a widget toolkit, both had 'object' as a meaningful native domain concept). First-class functions OTOH are not optional, without them you've designed a language for infants. If you are designing a modern high-level programming language and you choose to cripple lambda (either because you've made regrettable decisions about your syntax that prevents their expression, or because you want to put training-wheels on the language itself, or LOL both) then you're an asshole, full stop. Python's scoping is tragic, at least Larry and Brendan had the humility to admit they fucked up and add reasonable scoping. GVR isn't wrong, 30 years of hard-won experience with correct lexical scoping is. If you think Scheme is wrong then I've got news for you: you are. Funny, now that I think about it it's not even about right and wrong anymore, it's about 'Pythonicity', which basically means that not only is GVR never wrong, if you don't agree then you're some kind of barbaric programming-language outsider. God I can't wait for a good example of Python (and more importantly the frigid, self-righteous, under-endowed Python community, I'm looking at you Paul Prescodd) to come into direct competition (- lisp epsilon) in a measurable, documented way.<p>At least Ruby and Javascript know that (- lisp epsilon) is the place to be, and they're both in the process of trying to add enough curly-braces to make themselves palatable to Java-refugees and no more.<p>Just remember: Python's not wrong, you are.<p><a href="http://www.python.org/doc/faq/general/#why-must-self-be-used-explicitly-in-method-definitions-and-calls" rel="nofollow">http://www.python.org/doc/faq/general/#why-must-self-be-used...</a>
txabout 17 years ago
I'm going the opposite direction: after having done two non-trivial RoR apps I have a Pylons project on my hands right now. What can I say? Pylons is a baby Rails and Python is a baby Ruby. Language issues aside, Pylons' architecture seem to be a little cleaner than Rails, but even that advantage largely goes away with all these cleanups done in Rails 2.0.<p>Pylons/Python are more ugly and less complete than Rails/Ruby:<p>a) Ugliness: passing "self" to each method, deriving from Object all the time and having __foo__() method names is ugly, ugly, ugly.<p>b) Incompleteness: URL generation/routing and SQLAlchemy are too primitive and require more coding comparing to Rails. Stuff like form_for(Model.new) isn't possible as far as I can tell. Moreover, Pylons application requires a lot of bootstrapping to get going, setting up DB access is especially tedious comparing to ActiveRecrod's magic. Ralis' soft inforcement and helpers' assistance with RESTful controllers can't be seen anywhere in Pylons as far as I can tell. The list goes on: Pylons is more like a very very old Rails version distorted by ugly Python's object system.<p>Pylons probably looks pretty sweet to someone who's starting on it with a fresh head, but after two years on Rails I am less than thrilled to work with it. I may not be Pylons expert by now, but man... it's been two months and it still doesn't show me any love :-)<p>I love Python though. I like CPython implementation and quality of the libraries. Right now it's my language of choice for any stand-alone piece of software, but I try as hard as I can to avoid Python's object system.
评论 #157398 未加载
评论 #157387 未加载
chaostheoryabout 17 years ago
He has some valid points, but I think a more accurate title is: "Why I don't like Ruby"<p>"Migration to Ruby 1.9/2.0"<p>Won't python dev's have the same problem with Python 3000?<p>"Performance (or lack of)"<p>JRuby and Ruby 1.9/2.0 already address this issue<p>"Scoping" "There’s more than one way to do it"<p>I don't see this as a weakness. This is more about style and preference, though I admit I like Python's philosophy better (Ruby code just looks more beautiful to me)<p>overall I still think it's well written criticism (at times I cringe looking at the horrible stuff people in the ruby community write)
评论 #157331 未加载
ambitionabout 17 years ago
I've noticed a bias in favour of "What I learned first is better." It applies whether the topic of discussion is programming languages and operating systems or politics and religious values.<p>(Pre-emption: "bias", not "law".)<p>Psychologists have lots of fancy words for describing why this is.
评论 #157753 未加载
kenabout 17 years ago
These, of course, are not problems with Ruby -- so fellow Rubyists, don't get bent out of shape over this. It's a list of his priorities, which don't happen to align with the current state of Ruby. It's not hard to come up with a different set of criteria that make Ruby look perfect and Python look unusable, and I'm sure other people here will do just that.<p>But interestingly, all three of his main arguments in favor of Python (more mature, more consistent, and more complete documentation) also sound like great reasons to use Common Lisp over Python.
scabout 17 years ago
Everything appears to be a matter of taste:<p>Ruby has two range operators, .. and .... Why? The only difference is that the shorter one, with two periods, returns a longer range, and the longer one returns a shorter range, not including the endpoint. Can this possibly get any more confusing? 2 The language should have one, not two. It is not hard to add or subtract one when you want a range with, or without, its endpoints.<p>I like the shortcut. Then again, I like the English language. I like the fact that you can express things in a myriad of (yes, you can say "myriad of") different ways depending on how you want to express them.<p>A Pythonista friend of mine once complained over the simple fact that Ruby had so many ways to express a conditional but none as elegant as what was used in Python.<p>Python:<p>- if foo: bar()<p>Ruby:<p>- if foo then bar end<p>- if foo; bar end<p>- if foo: bar end # deprecated<p>- foo if bar<p>- foo &#38;&#38; bar<p>- foo unless !bar<p>I love the diversity, however. Really, the first thing that sticks out to me with Python are those superfluous parentheses. Taste, taste, taste.
评论 #157370 未加载
justindzabout 17 years ago
Imagine how much good code in either language is currently <i>not</i> getting written ;-)
sahabout 17 years ago
As someone who spends most of his time working in Python, the section called <i>One nice thing about Ruby’s scoping</i> made me a little bit jealous. I hate the way Python handles default parameters.<p>Also, I think glyphobet is a little hard on Ruby's range objects. He says:<p><i>Python’s xrange() can also be passed around like a variable, but you test for membership with value in myrange instead of ===.</i><p>An important difference there is that "value in xrange(10000)" iterates to find the value, while "(1..10000) === value" does something O(1), like 1 &#60;= value &#60; 10000. Range objects are handy, and different from list constructors like range() and generators like xrange(). But I agree that the ".." and "..." syntax is weird.
评论 #157339 未加载
评论 #157881 未加载
sant0sk1about 17 years ago
He brings up a good point w/ documentation. Ruby's has left me wanting in more than a few situations.
评论 #157356 未加载
astineabout 17 years ago
I think that the real teller on Ruby is it's own website. not the main page, but most of the surrounding infrastructure linked community is really slow. That is, it is painful to browse. I don't use Ruby or Python very much, but when I do I usually go through the main site for language to find reference and documentation and Ruby is definitely more difficult on that count because of this. I can only assume that it is because they build their websites in Ruby.<p>On the other hand, Ruby is Japanese. I suppose that the websites may be hosted on on Japanese servers all that way across the and that may account for the lag. It's still annoying though.
anrabout 17 years ago
The author has ceirtainly touched a nerve.<p>I wonder if Perl 6 will be a better Ruby... I do hope we can start to use it by this year's end.
yawlabout 17 years ago
I like ruby as a language, but not the implementation. And as a matter of fact, matz knows and acknowledged he is not a good implementator.
theoutlanderabout 17 years ago
Ruby works for me. I like the language semantics. What I miss are the email libraries/parsers that are available in other languages. Don't you think Ruby will catch up with the missing features in a couple of years? The documentation isn't that bad either.
jrsimsabout 17 years ago
Serious question:<p>Doesn't the fact that Twitter has been running a highly trafficked Ruby website for a while now nullify all arguments that "Ruby's not ready"?<p>Sure, we all know that Ruby could be <i>better</i>. But isn't it ready now?
Kwazikoabout 17 years ago
Blah Bah Blah Bah Blah Blah.<p>Too much time is wasted on this planet due to people trying to convince themselves they are "doing the right thing".<p>I don't know (or care) what the results are for others. For me, Ruby on Rails saves me tremendous time when developing projects and makes me enjoy coding web apps again. So I use it.<p>If you get that same feeling, use it too. If you don't, try something else.<p>Anyone who sees anything more to this needs a vacation.
davidmathersabout 17 years ago
Shorter glyphobet: Ruby's not Python.
sabatabout 17 years ago
"The language is inconsistent and needlessly complex."<p>Huh? This is Ruby he's talking about? I don't find it to be inconsistent or complex.
评论 #157329 未加载
piusabout 17 years ago
Isn't it a little late for April Fools' jokes?
russabout 17 years ago
Ruby pwns Python. word.