Ruby mistakes
gist.github.com
gist.github.com
Yes, different languages do things differently. I like discussions about the tradeoffs. I get a lot out of discussions like that.
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.
When it's called "Ruby mistakes" on the other hand, it just gets silly.
Professionals should be able to articulate and compare the merits of the decisions made by different languages. Even when the talking about more subjective topics, like syntax aesthetics, we can do better than simply calling them "bizarre." These are learning opportunities, not reasons to ridicule "the other team".
But yes those are WTF things, and you have to know what they are. I remember that upon encountering it I couldn't wrap my head around throw/catch and raise/rescue. "Surely it can't that bad" I told myself. It was.
The same goes for the so-called "module system". Spitting on java is very hip, but its module system is way better than Ruby is.
And to the other commenter, yes those are mistakes. Calling them mistakes does not imply that the langage is beyond hope or unusable.
Ruby also doesn't have a so-called "module system", so I have no clue what you or the OP are talking about.
Both classes and modules in Ruby can be used for namespacing purposes. Modules tend to fill the default "pure namespace" role, but that isn't their purpose—it just happens to be convention. The purpose of a module is an interface (per Java) with implementation—a mixin.
If, however, you're referring to the way that ruby programs are structured and how Kernel#require works…you're still barking up the wrong tree.
Yes, Ruby has mistakes—these two items that you've mentioned are not. Neither are most of the things that the OP's gist mentions. Some things on the list are confusing (break/next/return semantics; Yehuda Katz has a good article highlighting it that I found after a discussion with Reg Braithwaite [raganwald] and others on Twitter that had started the night before at a bar); most of them are simply the author's ignorance—and I don't mean that disparagingly. I am ignorant of many things about Python and JavaScript, because they are not my primary programming languages.
Ignorance can be easily cured. Arrogance is much harder to cure.
About throw/catch and raise/rescue. First, why have throw/catch and not have it do what it does in every single other langage? I guess this is debatable.
Secondly, a problem with throw/catch is that there is no "clean" way to know if you exited via a throw or normally (the hackish way involves a boolean variable). I guess you could argue that it isn't the intended use. I'm missing this because of the following point.
My real grief with raise/rescue is that it acts exactly like Java's throw/catch, while it could be so much more. Why couldn't we throw arbitrary objects? And pass arbitrary objects to rescue, which would have a special method (lets call it "catches?(e)") that would check if the objects "matches" a thing that was thrown. Exception classes would have this as a class method, and it would match its own instances.
This, incidentally, is exactly how the ruby case statement works. In that case, the special method is "===". So that's an inconsistency in the langage right there I'd say. Or at the very least, a missed opportunity.
So ok, maybe not "mistakes" if that's too strong of a word for you. But "things that should change"? Definitely.
Also, ad hominems are lame.
2. throw/catch isn't an exception handling system. You do have a clean way to know whether you exited via throw or normally; see http://rubylearning.com/blog/2011/07/12/throw-catch-raise-re... for details (it's a nice little summary). The problem is that you seem to think that throw/catch is for exception handling because everyone else uses those terms for exceptions.
My understanding is that throw/catch (while used less often) is cheaper to set up than begin/raise/rescue/ensure/end.
3. raise/rescue does behave like Java's throw/catch in that it's explicitly for exception handling. As far as throwing arbitrary objects, let me share a beauty from C++:
try
{
throw 0;
}
catch (...) // The only thing that catches 0.
{
}
You want raise/rescue to work like throw/catch. If you want that, use throw/catch and save raise/rescue for real exception handling. Or even ignore both of them.
I think that what you've described are neither mistakes, inconsistencies, missed opportunities, or things that should change.
4. I didn't use an argument from ad hominem. I carefully deconstructed the argument on technical merits and noted that these sorts of arguments come from ignorance—of which I have in spades on many topics. I also noted that it is harder to swallow the arrogance that deems arguments from ignorance as "mistakes". Both of these statements are factual.
True story: like many people who discovered Ruby after having used a number of different languages, I had substantive amounts of ignorance about why the language was what it was. In 2002—having just picked up the language, I suggested that nil should act like NULL in SQL (e.g., only tested through special case handling). This was ignorance. It was also arrogance to suggest this for a language that at the time I had been using for less than a month.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...
I thought I argued the point very well and looking at the follow-ups, it wasn't as bad as I remembered, but the proposal wasn't very…Rubyish. (Going back through to find a few other examples, I found this gem <http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...; and I can think of several cases, including the original PDF::Writer, where I had to do just that.)
It is harder to correct a problem of arrogance than a problem of ignorance. The person who wrote the original list was both ignorant (new to Ruby, to be expected, and explicitly Not A Problem) and arrogant (labelling them as mistakes with Ruby as opposed to decisions/behaviours that weren't understood). There's a lot that I don't understand about Python, but I am (at this point, past 40) no longer so arrogant that I declare the explicit self or the way that len(x) is implemented to be mistakes in the design of the language (even though I think they are warts that make Python much less pleasant for me to use).
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.
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.
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.
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.
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.
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 not what you want, even though it might look as if it was. It has a huge shooting-your-own-foot potential.
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.
force_encoding! is sometimes needed if you get data from inputs that pretend to be a different encoding than they actually are. It does offer a lot of rope to hang yourself with though.
erm, wat?
Edit:
To refute some of the points:
> Why on earth does defined? return a string?
Why not? Strings are perfectly valid in boolean context.
> Using blocks for looping and callbacks
again, wat?
> break/next/return semantics in blocks extremely bizzare
This is a somewhat valid point. Well, don't do it then, if you don't know what you're doing!
> And they have different behavior in procs vs. lambdas
> Mutable objects have a hash method and can go in Hashes. Why!!!
Why not? It is possible to shoot yourself in the leg, but otherwise a very useful feature.
> Special case of flip-flop and regexp in an if statement (only if it appears
> syntactically though!)
> Setting `$=` to something truthy causes all string operations to become
> case-insensitive. This and other magic globals from perl are mind blowing.
Perlisms.
> `f {}`. Tell me what the parsing of that is.
Calling f with empty block.
> Ruby's module system makes namespacing optional (and off by default).
So?
> Regexp with named matches decompose into local variables. Dear lord why.
No they don't necessarily, no.
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
wat?
> Scopes: constants, class vars, instance vars, methods, locals. wtf.
Valid point.
> Constants aren't constant. Truth in naming.
So?
> Thread locals are really fiber locals.
Valid point.
Overall, a very weak rant.
Block-based loops in Ruby are pretty nice, but the semantics could be simpler. Rust gets this right.
Hashable mutable objects are a giant liability. Ruby even has freezing of objects, so it should only allow hashing frozen objects at least.
Ignoring scope by default is extremely stupid and dangerous. Namespacing is pointless if it's off by default.
Well, of all dangerous things you can do with ruby, this is one of the least dangerous ones. How about "any gem can monkey patch any other gem or even core classes"? Isn't this a giant liability?
Besides, it's not that difficult to make your custom hash that only allows immutable objects for keys.
You are assuming the string had the right pair of <encoding type, byte value> which is not guaranteed.
For example, an old mysql binding wouldn't handle some of the encoding settings correctly, so you'd get a UTF-8 string with attached data in latin-something.
This could be trivially fixed in client code by simply calling #force_encoding.
I've been a Ruby developer for… seven years now, and have literally never encountered actual problems in the real world by this, by mutable hash keys, or well over half the other issues on this list. And I'm willing to bet the vast majority of other developers haven't either.
Ruby has mostly sensible defaults that work as expected in most practical cases.
Says you. For my part, I've more than once had to deal with data that the source tells me is in one encoding, but where I can't trust the encoding and have to use heuristics to determine whether or not to switch encoding after I've read the string in.
Yes, there are other ways of handling that than changing the encoding, but that doesn't mean it isn't convenient to be able to correct the encoding value already attached to the string.
As for the "potentially very dangerous" I don't really buy that. Yes, you can turn the string into complete gibberish if you call it without knowing what you're doing, but it's not exactly something that you're likely to call by accident.
Bytes != strings.
That's not a good reason for anything, by that yardstick Array#length could return a float and nil#nil? could return an array. And worse, the `?` postfix in Ruby normally means the method returns an actual boolean, not a "boolean context" (convention over configuration only works if the convention is respected). You can't XOR a string and a boolean (no `^` defined on string, although XOR-ing a boolean and a string will work), you can XOR two booleans.
> Why not? It is possible to shoot yourself in the leg, but otherwise a very useful feature.
I'm not sure, but I think he phrased it badly and asks why "interpreter-provided" mutables (e.g. Array) can be set as hash key: while "user objects" are also hashable by default in Python, built-in collections and the like are specified as unhashable as the semantics are not really sensible:
>>> {{}: 1}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'dict'
>>> {set(): 1}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'set'
irb(main):002:0> {[] => 1}
=> {[]=>1}
irb(main):003:0> {{} => 1}
=> {{}=>1} data[[v1, v2]] = something
If you couldn't use mutable objects as hash keys a bunch of things would become _way_ harder.
data[[v1, v2].freeze] = something
Meanwhile if anybody gets a hold of the key and happens to mutate it (not necessarily for nefarious purposes, just because it solves they problem) you can quite literally lose your pair:
irb(main):001:0> h = {}
=> {}
irb(main):002:0> l = [1, 2]
=> [1, 2]
irb(main):003:0> h[l] = 1
=> 1
irb(main):004:0> h[l]
=> 1
irb(main):005:0> l[1] = 3
=> 3
irb(main):006:0> h[l]
=> nil
irb(main):007:0> h[[1, 2]]
=> nil
irb(main):009:0> h[[1, 3]]
=> nil
irb(main):010:0> h
=> {[1, 3]=>1}
irb(main):011:0> h[[1, 3]] = 3
=> 3
irb(main):012:0> h
=> {[1, 3]=>1, [1, 3]=>3} jruby-1.6.8 :068 > h = {}
=> {}
jruby-1.6.8 :069 > l = [1, 2]
=> [1, 2]
jruby-1.6.8 :071 > h[l] = 1
=> 1
jruby-1.6.8 :072 > h[l]
=> 1
jruby-1.6.8 :073 > h[l] = 3
=> 3
jruby-1.6.8 :074 > h[l]
=> 3
jruby-1.6.8 :075 > l[1] = 3
=> 3
jruby-1.6.8 :076 > h[l]
=> nil
jruby-1.6.8 :077 > h.rehash
=> {[1, 3]=>3}
jruby-1.6.8 :078 > h[l]
=> 3
Rebuilds the hash based on the current hash values for each key. If values
of key objects have changed since they were inserted, this method will
reindex hsh.
While the actual return value can be useful, it would be just as useful if the method had a more sensible name than hinting it's a predicate, which it is not.
(i agree that within ruby's conventions (weak typing) defined? is not that bad)
No. "Weak Typing" doesn't mean jack shit, and there are very few under its thousands of different and incompatible identities which Ruby would match, save for the very least useful of them.
> if a.defined?
works, because the returned string type is implicitly converted to a boolean. that's weak typing. at least one (i guess the most common) interpretation of weak typing.
jruby-1.6.8 :089 > defined? Foo::Bar
=> nil
jruby-1.6.8 :090 > Foo::Bar
NameError: uninitialized constant Foo::Bar
z = x.y
z == x.y # => true
defined?(z) == defined?(x.y) # => false
That's not true. Predicates methods returns Truthy or Falsey values. Not necessarily booleans. See http://blog.leshill.org/blog/2012/03/25/a-question-of-truth....
Original intent aside, if your language is prided on convention, then it has to be open to the convention changing.
Btw: The mantra "convention over configuration" is a rails mantra and not a ruby mantra.
Also, I never said "convention over configuration," since there's nothing to configure here. I was talking specifically about the convention of what a "?" should return. In that same quote Matz also says that predicates typically return a boolean value, but it's not required. That seems to both imply and endorse a convention.
Sure. The convention endorsed is "should, but not required". That's exactly what happens. A pattern I see often is something along the lines of
def ssl?(url)
url.match /^https/
end
jruby-1.6.8 :092 > def ssl?(url)
jruby-1.6.8 :093?> url.match /^https/
jruby-1.6.8 :094?> end
=> nil
jruby-1.6.8 :095 > ssl? "https://google.com"
=> #<MatchData "https">
jruby-1.6.8 :096 > ssl? "http://google.com"
=> nilNow in that whole Rails hoopla, it turned into "it's not required and neither defined? nor nonzero? do it," ignoring the whole "should" part. And now people are pointing at Rails as another example, reinforcing their own bias.
However, it's not only nonzero? or defined? that don't return boolean values. see http://news.ycombinator.com/item?id=5074676 for more examples. If you read through the core libs documentation you'll find more examples. You just cannot rely on predicates returning true/false in all cases, so you either have to learn not to rely on it at all or learn every example where it doesn't. So just don't rely on it.
Otherwise things are not consistent and confusing. Yes, with enough time you just learn all the tricks and start fighting for the status quo, bacuase that's how things always worked and it's ok. But is it?...
A rubyism is that any function suffixed with a ? should return a true/false, but then again, another rubyism is that everything that isn't explicitly False or nil evaluates to True, so it kind of works out. I can see how this would make anyone coming from another language kind of scratch their heads, though.
You'd expect defined? to return simple boolean, not evaluate the type of object being referenced (kind of like .class)
Another notable example is nonzero? which returns the value of the number if nonzero and nil otherwise:
jruby-1.6.8 :097 > 1.nonzero?
=> 1
jruby-1.6.8 :098 > 0.nonzero?
=> nil
If you rely on predicates always returning true/false you're in for a nasty surprise.
[1] http://ruby-doc.org/core-1.9.3/File.html#method-c-world_writable-3F
[2] http://ruby-doc.org/core-1.9.3/FileTest.html#method-i-world_readable-3F
[3] http://ruby-doc.org/core-1.9.3/File.html#method-c-size-3F
[4] http://ruby-doc.org/core-1.9.3/Kernel.html#method-i-autoload-3F
[5] http://ruby-doc.org/core-1.9.3/Encoding.html#method-c-compatible-3FThat may make things actually more confusing on first glance, but it does give a technical reason why it doesn't follow method naming conventions.
jruby-1.6.8 :089 > defined? Foo::Bar
=> nil
jruby-1.6.8 :090 > Foo::Bar
NameError: uninitialized constant Foo::Bar>Perlisms.
They're incomplete Perlisms that's the real flaw because in perl these special variables are dynamically scoped.
NB. $= does something completely different in perl. I don't know of any perl special variable that replicates what Ruby's $= does.
There's one that I'll agree with, however, and that's "Inline rescue, no ability to specify what exception."
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.
Using blocks for looping and callbacks
* break/next/return semantics in blocks extremely bizzare
Blocks, in and of themselves, are a very good base for implementing flow control.
Having said that, once you learn the difference it's not that big a deal.
They are. Especially return.
> Anybody that comes to ruby with knowledge of other languages with first-class functions will be confused by it, in particular return.
Not necessarily, and especially not if they happen to understand what "block" means, and why Ruby uses "block" not "lambdas" for its core.
Or if they have the slightest inkling of knowledge of Smalltalk and/or Self.
And either way, unless they've already fossilized the difference is easy to learn (and solves important issues in imperative languages)
So?
> Most programmers don't know what an escape continuation is
Not that they have any reason to care.
> There's no reason to believe that people are just going to divine their meaning.
I don't think I ever said that.
> And if they're new to Ruby, they're not going to understand what a block is, pretty much by definition. It's a feature that's pretty unique to Ruby.
It's not for any known value of "unique". Blocks are present in most C-like languages, and first-class blocks were introduced by Smalltalk.
So, my point is, why are they called CONSTANTS?
That's not a valid argument.
"Q: Why does your OS allow any program to write anywhere in memory?"
"A: Because we believe in freedom. Our profound belief is that the OS should not allow to handcuff programmers. They must be free to do anything. They should be able to write anywhere in memory and anywhere to disk"
How do you want people to be able to be able to reproduce state and to reason about a program if f*cking CONSTANTS can be modified!?
Your OS analogy is also poor. There's about two decades worth of discussions about memory protection in AmigaOS and it's spiritual successors (AROS, MorphOS etc.) for example, and while some people involved with those are strongly in favour of adding things like memory protection (though it is hard to do without severely breaking compatibility), there are also a lot of people for whom part of the appeal with these OS's still is that a user can hook into anything and everything:
For AmigaOS there are user-level applications that can replace the task (process) scheduler, for example. There are user-level applications adding virtual memory. There's a library that gives any user-level application free reign to more easily manipulate the MMU. There OS itself provides API calls to allow user applications to replace the code used for ever library call (system wide - the equivalent of being able to override syscalls in Linux...). There are assemblers with explicit support to muck around with hardware registeres and OS structures. There are applications designed to trace everything that happens at the OS level. And a lot of these capabilities are in fairly common use by the (admittedly few) users of these systems.
You might argue (and I'd agree with you) that this isn't a great basis for a modern OS. But that does not make it an invalid stance - most of these people don't want what we consider a modern OS. Many of them instead want something where they can do exactly those kind of things with nothing like a userland-kernel barrier to deal with etc.
It's not an argument, it's a description. That is, in fact, the way Ruby generally works.
>> Q: Why does your OS allow any program to write anywhere in memory?"
That's not an accurate comparison. A user installing two programs cannot be expected to ensure that they play nicely together. A programmer can be expected to ensure that an application's code and libraries play nicely together - especially in a non-compiled language, where you always have the source code.
Even more especially where you have a community that generally promotes the best libraries and the developers who make them.
>> How do you want people to be able to be able to reproduce state and to reason about a program if f*cking CONSTANTS can be modified!?
I'm not proposing a crazy new system; I'm describing a language that has been quite successful. In actual practice, I have never, ever had a bug that was caused by a constant being redefined. I've never accidentally redefined one, and if, hypothetically, I did, I would see a warning.
It might seem like a problem, but it isn't.
The type of flexibility that Ruby allows make it a really interesting language. In 99.999% of cases people never use all these features and it's considered bad form to do so.
Ruby is one of those languages that depends a lot on cultural queues to work so well but unlike other languages it doesn't enforce everything on you. It's a tradeoff and it is by no means better than other languages, just different and pleases certain developers more than other languages.
That and relying on hashes made from mutable thing...
Taking a note to never ever try Ruby
More to the point, he comes from Python.
He's also — I believe — working on a ruby (ish?) implementation (or something along those lines), which probably colors his view of what is or isn't annoying. Most of what he lists makes the life of an implementor a living hell.
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.
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.
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.
http://en.wikipedia.org/wiki/The_Unix-Haters_Handbook
(I love Unix, and C, and Ruby, and yes, they're all awful, festering examples of "worse is better".)
"Look this Car is better then your Pineapple"
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".
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.
It is probably one of the biggest source of hard-to-find / hard-to-reproduce / hard-to-debug bugs.
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 are using immutable objects in Java, you are still deeply fcked if your classes are non-final. Even if you classes are* only allowing to create immutable objects and are final, you are still deeply fcked if you use composition.
Because it is impossible* to extend a class (or use composition) and satisfy the hashcode/equals contract.
This was explained in "Effective Java" back in the days.
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.
The fact that it is so broken (and provably broken: the contracts CANNOT, as in RFC2119, be respected) may be the reason while functional programming is making a comeback.
It certainly is for me and I'm not looking back.
Compared to... what?
Ruby grammar is hard to find but there it is http://www.ipa.go.jp/osc/english/ruby/Ruby_final_draft_enu_2...
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/parse.y?vi...
It is not so clear for documentation purposes, but grammar rules are in between 850-4988 lines.
File/Line size does not tell much about Grammar complexity, but anyway, the whole parse.y file is bigger than cpython/Parser directory. BTW, Ruby's parse.y file is just the input to Bison.
It's only three lines, but still.