Ruby's first-class functions make printf-debugging obsolete

jballanc · on March 21, 2010

Please don't do this. There are proper debuggers for Ruby that you can use to accomplish everything described here and more, and all without opening gaping security holes or beating the metaprogramming facilities in Ruby to a bloody pulp.

Also, I vote for Ruby's new motto to be: "Just because you can, doesn't mean you should."

jrockway · on March 21, 2010

I like to say, "There's more than one way to do it, but your way is wrong."

Fixnum · on March 21, 2010

"Just because you can, doesn't mean you should."

In particular, this Applies to Eval.

windsurfer · on March 21, 2010

For some small applications, it can be handy to eval a configuration file that is simply a language data structure. It's like having a built-in config file parser. It also gives to lots of flexibility with your hacks :)

jballanc · on March 22, 2010

That's why I said "Just because you can, doesn't mean you should" and not "Don't even think about it". 'eval' exists for a reason, and there are certainly good reasons to use it. This is not one of them.

viraptor · on March 21, 2010

Some languages are nice enough to provide functions that parse the text into native data without the need for evaluation (like erlang's erl_parse/erl_scan; I guess lisps can do the same)

jrockway · on March 21, 2010

Quite a hack. Over in the Perl world, we just say "perl -MCarp::REPL your_app.pl" and we can have a REPL in the correct lexical context when an exception is thrown. Without adding methods to random classes. (And it all goes away when you run without -MCarp::REPL, of course.)

lsb · on March 21, 2010

That's pretty cool, I'll have to check that out.

viraptor · on March 21, 2010

This is really evil... But the title is right - if you were debugging with printf in the first place, then this is better. It doesn't mean it's good in any way. The better way to make printf-debugging obsolete is:

- catch exceptions where they might occur and log as much information as possible

- use tests before publishing the code

- use something like log4X so you can actually log what's happening at the level you need

- do not ever think "Assuming that /usr/share/dict/words is sufficient" - you were wrong at "Assuming"

moe · on March 21, 2010

Good example for two of the biggest wrongs with ruby.

First wrong would be that it doesn't emit a useful error message in first place. Not sure why that is the case, but e.g. python would always include the value it failed on in a DivByZero Exception.

Second wrong would be that these kind of hacks seem to be widely accepted in the ruby community. Only because you can doesn't mean you should. DRY and conciseness are worthy goals, but not at the expense of sanity please.

viraptor · on March 21, 2010

Are you sure? (python)

    >>> a,b=1,0
    >>> a/b
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ZeroDivisionError: integer division or modulo by zero

jrockway · on March 21, 2010

Not sure why that is the case, but e.g. python would always include the value it failed on in a DivByZero Exception.

I bet it is usually 0.

The big innovation is including the variable name that is problematic.

moe · on March 21, 2010

Ha, good call. Looks like I missed the point by a good margin.

Yet I still have to wonder where the desire for this functionality is even coming from. The "cure" looks by far more problematic than the disease in any case.