Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's hard to disagree with you when you use that definition of 'magic'. This is an example of my definition...

Yesterday I was looking at a Chartbeat gem that accesses the Chartbeat REST API [1]. The entire class is 40 lines of code, however it's coded so weirdly that you'd have to read the source in order to use it. Every API call was a method_missing call, so instead of doing (in irb)

    puts Chartbeat.new(:apikey => 'a', :host => 'b').public_methods
you'd have to do

    puts Chartbeat::METHODS
    puts Chartbeat::DASHAPI_METHODS
But I only know that because I had to look at the source code. In addition, there's no way to specify custom exceptions to the user, you have to rely on the rest_client gem's exceptions.

The code does look magical, and kudos to the developer that wrote it for the ingenius use of method_missing, but IMHO it's a bit to magical for my tastes. I like to look at a library's documentation and instantly know what methods I'm allowed to call and what exceptions/results I'm going to get back.

[1] https://github.com/ashaw/chartbeat/blob/master/lib/chartbeat...




Honestly, this is why I cringe whenever I hear code described as "clever." I bring up "clever" here because "magic" seems to be used in this discussion in a manner synonymous with "clever." [1] Developers tend to be intelligent people who like to stretch their intelligence, but in terms of code robustness, the boring, normal solution is almost always a better choice than the clever approach. Clever, to me, has almost become synonymous with unusable, fragile, and over-complicated.

[1] Edit: Added explanation since, on a second read, it seems like I'm digressing from the topic.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: