Welcome to Bloggers and the Principle of FUD. Take this post with a pinch of salt.
It's trendy to pick holes at Ruby in various, inaccurate ways lately, but a quote from Matz about that POLS business:
Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, "I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise." Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprised me.
You can pick up almost any programming language, not learn it properly, and then pick holes in its various inconsistencies or flaws (my own is over Python's ambiguities over methods vs functions for various things - but I know I'm not a Python developer!) That doesn't make it interesting or insightful. Every language has dark corners and Matz has been more than forthcoming about Ruby's.
This article has numerous curious assumptions and sloppy practices. Local variables called the same as method names? And very few Rubyists, in my experience, would be confused by the key example in the memoization section. Who really thinks || checks for whether a variable is bound rather than doing a logical or? How is it a "what's worse" that instance_eval changes self to instance_eval's receiver? That's its entire reason for existing! The second example under "Local Variables Strike Yet Again" is flat out wrong, even by the author's own admission.. Ruby 1.9 has been the production release for almost three years!
A-bloody-men. I read the post and mostly went "What?". If you're calling local variables the same as methods in the same scope then you're just asked for trouble. Mostly because when you come back and read it 3 months later it's harder to pick through.
Think the only related thing I've ever hit and gone WTF at is `foo = foo` sets foo to nil. But afaik that's due to the implementation of MRI/YARV, not all ruby runtimes.
So yeah, as a professional rubyist, reading that post was mostly just me going "WTF, why would you ever think or do that". As Peter says, take it with a pinch of salt.
Ditto. I think it's problematic for a programmer to rely on a language to resolve ambiguities for you. If you see or suspect undesired ambiguities in your code, resolve them yourself. Best of all, make every effort to avoid introducing them in the first place.
I'm reminded of a programmer I read about who refused to learn any language's operator precedence. Instead, he always grouped expressions with parentheses to make sure they were evaluated in the order he desired. (I don't know that I'd do that myself, but he had a point...)
I mostly agree. Apart from: "not learn it properly, and then pick holes in its various inconsistencies or flaws". Flaws may be subjective, but inconsistencies aren't. If you find two similar things provided by default, with very different behaviour then it's not a case of not knowing the language. It's inconsistent and that's a problem in one way or another.
"Welcome to Bloggers and the Principle of FUD. Take this post with a pinch of salt."
Actually every time somebody uses the term "FUD" I have to take THEIR comment with a huge sack of salt.
Can't you just state your counter-claims without resorting to accusing the other guy of a conscious attempt at misguiding people?
Also, "FUD"? Really? Someone posting on some Ruby shortcomings (or anything) is spreading "fear", "uncertainty" and "doubt"? Because you just had to use a relic term of the 90's desktop wars against Microsoft, right?
I read the post, and haven't felt any particular fear.
Matter of fact, I was rather enlightened by some of the examples.
Also I take offense to the silly line of argument here:
> "You can pick up almost any programming language, not learn it properly, and then pick holes in its various inconsistencies or flaws".
Really? One picks holes "in its various inconsistencies or flaws" if he has not "learned [the language] properly"?
What sense does that make? A language either has "various inconsistencies or flaws" or it has not.
If it has --and you don't argue that Ruby hasn't--, one has EVERY F*N right to "pick holes" at them. And this has nothing to do with "not learning the language properly".
If the language has "inconsistencies or flaws" what does "learning it properly" mean? To learn to work around them?
Yep, as usual, prepare salt before you read _any_ programming languages blog post.
My case was against Ruby back when Rails was hot. Ditto with JavaScript nowadays.
Ruby 1.9 has been out for production for almost 3 years? Cool, how come it's slower than 1.8.7? (not trying to offend Ruby but I use Rails 3.1 with Ruby 1.9, running unit-tests are dog-gone slow).
Ruby 1.9 has been out for production for almost 3 years? Cool, how come it's slower than 1.8.7?
It's not. File loading in 1.9.2 is notoriously slow and you're probably encountering a common case where mid to large scale Rails 3 apps are loading so many files at runtime that you're hitting it. Everything else is bright and breezy. The story behind much of this: http://www.rubyinside.com/ruby-1-9-3-faster-loading-times-re... - Most people are experiencing significant speedups with 1.9.3 so far but it hasn't had its final release yet.
That aside, speed isn't everything. Python 3 was (is?) slower than Python 2 for quite some time, despite being in production.
It's trendy to pick holes at Ruby in various, inaccurate ways lately, but a quote from Matz about that POLS business:
Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, "I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise." Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprised me.
You can pick up almost any programming language, not learn it properly, and then pick holes in its various inconsistencies or flaws (my own is over Python's ambiguities over methods vs functions for various things - but I know I'm not a Python developer!) That doesn't make it interesting or insightful. Every language has dark corners and Matz has been more than forthcoming about Ruby's.
This article has numerous curious assumptions and sloppy practices. Local variables called the same as method names? And very few Rubyists, in my experience, would be confused by the key example in the memoization section. Who really thinks || checks for whether a variable is bound rather than doing a logical or? How is it a "what's worse" that instance_eval changes self to instance_eval's receiver? That's its entire reason for existing! The second example under "Local Variables Strike Yet Again" is flat out wrong, even by the author's own admission.. Ruby 1.9 has been the production release for almost three years!