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

> "magic" in a program doesn't mean we can't ever trace where the effects we see are coming from

This is my definition of magic: when it _does_ so

That's my pet peeve with Rails and Rails-minded gems, which do such magic as a core tenet. Someone ends up being too smart for their own (and others) good, it looks lovely and clever from the outside, methods are added to core objects, often dynamically so, global-like state is rampant, lazy behaviour is pervasive.

Then something breaks, and you're left with behaviours that make no sense. Of course with enough time and energy one can see through the veil by diving deep in the bowels of the framework, but I don't quite like the thinly veiled judgemental statement of TFA that magic is just metaprogramming and that as a dev you should get your shit together, which does not help in the real world when all hell breaks lose in nonsensical ways because a prime directive has been violated†.

Tricks and prestidigitation have no business being used in systems that aim to be reliable.

† Blindly copying references to thread locals into another thread[0], assuming every possible one ever used in all apps and dependencies is either scalar (which they're usually not), deep-frozen (which they're usually not), or thread-safe (which they don't need to be, because they're, you know, thread local), can only be delicately described as "a bold move".

[0]: https://github.com/rails/rails/blob/6ec669b65d5cd47c98466192...



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

Search: