Skip to content

Instantly share code, notes, and snippets.

@alex
Created January 17, 2013 01:57
Show Gist options
  • Save alex/c8188956cd66c38feb1f to your computer and use it in GitHub Desktop.
Save alex/c8188956cd66c38feb1f to your computer and use it in GitHub Desktop.
Ruby Mistakes
=============
* Using blocks for looping and callbacks
* break/next/return semantics in blocks extremely bizzare
* And they have different behavior in procs vs. lambdas
* Why on earth does defined? return a string?
* throw/catch. Why!
* Inline rescue, no ability to specify what exception (and by extension, "catch
anything" behavior common in community)
* Mutable objects have a hash method and can go in Hashes. Why!!!
* Extremely complex grammar, makes barrier to entry for implementation much
higher
* 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.
* Keywords that silently override methods by the same name (defined?, on
Rubinius block_given?)
* `f {}`. Tell me what the parsing of that is.
* proc, lambda, block, method, unbound method, functions. None of which have a
clear relationship. set_trace_func exists, even though you can't pass
functions around.
* Bizzare magic::
def f
Proc.new
end
f { |x| 3 }
How does ``Proc.new`` know where the block came from?
* Ruby's module system makes namespacing optional (and off by default).
* Regexp with named matches decompose into local variables. Dear lord why.
* Encoding system is beyond broken
* Scopes: constants, class vars, instance vars, methods, locals. wtf.
* Constants aren't constant. Truth in naming.
* Thread locals are really fiber locals.
* You can change the encoding of a string. Just jesus christ wow.
@hovsater
Copy link

I see a fair about of people already argued by the majority of things in the list, so I'll just leave it there. I will make an addition to the statement about inline rescue though.

Inline rescue, no ability to specify what exception (and by extension, "catch
anything" behavior common in community)

@avdi talks about inline rescue in episode 22 of Ruby Tapas. Inline rescue might come handy if you want to evaluate the exception and act upon it. This can be done by making use of the $! variable.

@mdesantis
Copy link

Inline rescue, no ability to specify what exception (and by extension, "catch anything" behavior common in community)

This is the worst IMHO; the others are not so bad (the one of the Regexp with named matches is bad, but is not so common), and some are just "not bugs but features" (f.e. the fact that you can change the encoding of a string).

@cogweh
Copy link

cogweh commented Jan 17, 2013

Python guy complaining that Ruby isn't Python. It shouldn't be "Ruby Mistakes". It should be "Things about Ruby I don't understand because it doesn't work the same way as in a language I'm used to".

@Nek
Copy link

Nek commented Jan 17, 2013

@cogweh If it should be "Things about Ruby I don't understand..." than could you be so kind to share a part of your genuine experience with ruby and explain those things to us, python/javascript/lisp/whatever guys.

@cacciatc
Copy link

A corresponding Python Mistakes gist :)
https://gist.github.com/4558963

@drbig
Copy link

drbig commented Jan 17, 2013

This reminds me of the blub paradox...

@cogweh
Copy link

cogweh commented Jan 18, 2013

@Nek selective context "...because it doesn't work the same way as in a language I'm used to" This is basically frivolous bickering about the language which we shouldn't be having. The OP is clearly trying to point out what he perceives as flaws in a language without much basis. It's the same thing as saying "that car is red so it must be horrible."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment