While there are a couple of things in there that annoy me about Ruby, the list basically feels like a stereotypical American pointing at a stereotypical Frenchman and saying, "Look at that French guy. He looks funny."<p>Yes, different languages do things differently. I like discussions about the tradeoffs. I get a lot out of discussions like that.<p>But these WTF sort of lists are pretty worthless. The implicit argument is that OMG this language is broken. Yet for any major language, people have been able to build some pretty complicated stuff with it. Clearly all these WTF things are at the very least surmountable. And a lot of them stop seeming so WTF if you actually make some effort to think about or learn why they're there.
<i>> Encoding system is beyond broken</i><p>I disagree. Due to some political issues[1], in Ruby's country of origin, Unicode is still not as widely used as it could be. Instead, local multibyte character sets are the norm.<p>Normalizing to Unicode internally (like what Python 3 does) is impractical or not feasible as turning that Unicode data back into the original string is not reliably possible but might be required.<p>Ignoring encodings all together and treating everything as byte strings (like 1.8.7 did) might be ok if you live in an english speaking country and you're not dealing with EBDIC. In all other cases, this means that you can't safely use any of the string manipulation built into the language.<p>As such the second best way to deal with encodings is to have a distinct type for every possible encoding you support and have them incompatible with each other.<p>Then the applications can decide what they want to do: Not deal with encodings at all (if you live in pure-ASCII land), unify everything to UTF-8 (or 16), or use whatever local character set the input data is in.<p>The only thing I would be willing to argue might have been a wrong decision is adding the force_encoding method as more often than not calling that is <i>not</i> what you want, even though it might look as if it was. It has a huge shooting-your-own-foot potential.<p>OTOH, sometimes libraries have mistakes or lie willingly at which point it might be a handy, albeit really dangerous, tool to have. Just like the -f flag for rm. Use it responsibly.<p>1) <a href="http://en.wikipedia.org/wiki/Han_unification" rel="nofollow">http://en.wikipedia.org/wiki/Han_unification</a>
> You can change the encoding of a string. Just jesus christ wow.<p>erm, wat?<p>Edit:<p>To refute some of the points:<p>> <i>Why on earth does defined? return a string?</i><p>Why not? Strings are perfectly valid in boolean context.<p>> <i>Using blocks for looping and callbacks</i><p>again, wat?<p>> <i>break/next/return semantics in blocks extremely bizzare</i><p>This is a somewhat valid point. Well, don't do it then, if you don't know what you're doing!<p>> <i>And they have different behavior in procs vs. lambdas</i><p>> <i>Mutable objects have a hash method and can go in Hashes. Why!!!</i><p>Why not? It is possible to shoot yourself in the leg, but otherwise a very useful feature.<p>> <i>Special case of flip-flop and regexp in an if statement (only if it appears</i><p>> <i>syntactically though!)</i><p>> <i>Setting `$=` to something truthy causes all string operations to become</i><p>> <i>case-insensitive. This and other magic globals from perl are mind blowing.</i><p>Perlisms.<p>> <i>`f {}`. Tell me what the parsing of that is.</i><p>Calling f with empty block.<p>> <i>Ruby's module system makes namespacing optional (and off by default).</i><p>So?<p>> <i>Regexp with named matches decompose into local variables. Dear lord why.</i><p>No they don't necessarily, no.<p><pre><code> 1.9.3-p327 :006 > "abcdefg".match(/(?<x>abc)/)
#<MatchData "abc" x:"abc">
1.9.3-p327 :007 > x
NameError: undefined local variable or method `x' for main:Object
</code></pre>
> <i>Encoding system is beyond broken</i><p>wat?<p>> <i>Scopes: constants, class vars, instance vars, methods, locals. wtf.</i><p>Valid point.<p>> <i>Constants aren't constant. Truth in naming.</i><p>So?<p>> <i>Thread locals are really fiber locals.</i><p>Valid point.<p>Overall, a very weak rant.
I don't have an issue with most of these. In fact, to me, "ruby allows you to do X, and it shouldn't" is an annoying line of thought. If I want to make my language dance, I don't want it to cry-- I want it to sing along.<p>There's one that I'll agree with, however, and that's "Inline rescue, no ability to specify what exception."
Using blocks for looping (i.e. using callbacks) is actually a great feature. See Oleg Kiselyov's spirited defense of callbacks (as opposed to iterator objects) here: <a href="http://okmij.org/ftp/papers/LL3-collections-enumerators.txt" rel="nofollow">http://okmij.org/ftp/papers/LL3-collections-enumerators.txt</a><p>The fact that `break`, `next`, and `return` work the way they do in blocks is a remarkable simplification; it turns a set of constructs that work only on loops into functional constructs that work on functions, broadening their usefulness.
<p><pre><code> Using blocks for looping and callbacks
* break/next/return semantics in blocks extremely bizzare
</code></pre>
Actually they're pretty sensible (return is anyway, break/next are a bit weird but no more so than the rest), the main issues with blocks is the — mentioned — Proc-v-lambda dichotomy and the — not mentioned — block-not-being-first-class issues. Although it's hinted at with further mentions of magical behaviors surrounding blocks.<p>Blocks, in and of themselves, are a very good base for implementing flow control.
My favourite weird Ruby thing (is on the list, anyway) is that CONSTANTS can be changed, but it raises a warning...
Of course, you can also set up a mutable CONSTANT (a hash, for example) and change it without a warning.<p>So, my point is, why are they called CONSTANTS?
My ideal language would include: the intuitive-expressive power of ruby, the "explicit is better than implicit" mantra of python, the functional structure of clojure, the malleability and interactivity of lisp, and the unobtrusive static typing of go.
Ruby makes a number of tradeoffs in favor of "expressibility" at the expense of readability (without a _high_ degree of ruby proficiency) and ability to reason about programs. You can disagree with these tradeoffs, but they're not mistakes. It also has some things which might be designed differently if the language started from scratch (e.g. string encoding), but I would still say its a stretch to call these mistakes.<p>Ruby also has a number of things which make it "hard" (some would say impossible) to create fully equivalent alternative implementations. This is suboptimal, but it is what it is; at this point the level of change required to make it amiable to alternative implementation would be...prohibitive.<p>I do agree, however, that the inline rescue with no ability to limit to anything other than StandardError was a mistake...I've just seen way too many cases where _far_ more than reasonable got caught. That said, I'm not sure there would be any great way to add matching on the inline rescue to the grammar -- I think it would have to be removed.
I was in the hopes to find a deeper analysis on the problems encountered by ruby and rails recently.<p>We get very interesting and obligatory postmortem analysis for every minute a popular site is down, but when a major framework is found to have holes, nobody tells us what could have been done to avoid them, what flaws in the tools our the team's allowed them, and here comes again the elephant in the room.
If you enjoyed this, I recommend the Unix-Haters Handbook:<p><a href="http://en.wikipedia.org/wiki/The_Unix-Haters_Handbook" rel="nofollow">http://en.wikipedia.org/wiki/The_Unix-Haters_Handbook</a><p>(I love Unix, and C, and Ruby, and yes, they're all awful, festering examples of "worse is better".)
a rant without a solution to the rants...
sry but why this post is voted up so high?
do we wane start a ruby vs python war?
both languages are good in there own ways.
I don't even understand how someone can compare theme...<p>"Look this Car is better then your Pineapple"
<i>"Mutable objects have a hash method and can go in Hashes. Why!"</i><p>This is indeed terrible. It is broken beyond repair and it's probably because they thought Java doing something similar with their hashcode() method was "smart".<p>It is not that mutability is "evil". It is that contracts provided by the language / APIs on top of mutability definitely is evil, because it's impossible to obey / respect the contracts.<p>It is probably one of the biggest source of hard-to-find / hard-to-reproduce / hard-to-debug bugs.<p>The problem goes way further than that in Java that said: the very presence of "hashcode()" and "equals()" at the very top of the hierarchy (in the Object class) is fundamentally broken. Even if you <i>are</i> using immutable objects in Java, you are still deeply f<i>cked if your classes are non-final. Even if you classes </i>are* only allowing to create immutable objects and <i>are</i> final, you are still deeply f<i>cked if you use composition.<p>Because it is </i>impossible* to extend a class (or use composition) and satisfy the hashcode/equals contract.<p>This was explained in "Effective Java" back in the days.<p>Now it may even be possible that this very equals/hashcode/mutability SNAFU is, unconsciously for a lot people, at the heart of the current backlash and hatred towards mutability.<p>The fact that it is so broken (and provably broken: the contracts <i>CANNOT</i>, as in RFC2119, be respected) may be the reason while functional programming is making a comeback.<p>It certainly is for me and I'm not looking back.