4 ms·

You could probably disagree more with it, if you really tried :D But it's a bit early in the evening for reductio ad absurdum. After all, we can take it furth

You could probably disagree more with it, if you really tried :D But it's a bit early in the evening for reductio ad absurdum. After all, we can take it further into absurdity, why aren't we all just programming in hex via a keypad in the front of the computer? Abstraction != magic. The one bit of SICP that really stuck in my brain was: "Programs must be written for people to read, and only incidentally for machines to execute" Magic makes the first part far harder. If I need to understand your deep magic to understand your code, well, that's making my life harder, and don't you want people to understand what you're doing and why? I apply this critique to every kind of magic in code. Annotations in Java frameworks (I've had so much fun with Spring proxy invocations over RPC via Camel), monkey patching and metaprogramming in dynamic languages (or as Zed Shaw referred to it in Ruby, chainsaw infanticide) ...looking at you Django... Oh, and of course weak type coercion hacks and Perl's (< 6) DWMI. I mean, once you decode the sigils, it's a good feeling because you "get it", but if I want to feel clever for "getting it", I'll do cryptic crosswords. I'd far rather workaday code be boring and obvious when I have to make a mental model of it in order to fix it. I like it when I can read your code after you've moved onto another company, and understand what the code is doing and why without having to inveigle you into an awkward Zoom call or having to rewrite the magic step by painful step after the magician left, just so it's accessible to others. I've used "memoizing intermediate steps" often in the past, but it doesn't need to be magic.

rowanG077 3y ago
The problem is that no one can define magic. The thing that you might find magic is someone else mundane code or vice versa. It's simply a catch all statement that a lazy reviewer can slap on code they don't like. Just explain why you don't like it and be done with it.
- EdwardDiego 3y ago
  That's a fair point, what's magic and what's a good abstraction is highly subjective. I guess I'm a fan of the principle of least surprise. I'd far rather explicitly define a configuration property in some file than "if you create an environment variable called FOO_CONFIG_X=5, the Foo framework will populate your settings for you!" Because when the Foo framework doesn't respond to your incantations the way the docs say it should, then you're going to spend the rest of the day reading code to figure out why. Shit, the Spring annotation magic made me miss XML context files for that reason, the XML made wiring explicit, as opposed to auto wiring annotations that failed deep in the bowels of the beast. It's a continual problem across languages and frameworks, the (admittedly very) convenient magic is great until it isn't. I've lost enough time on it in my career that these days the only dependency injection libraries I'll consider for a new project have to be compile time. Still as much magic, possibly even more (trying to understand Quarkus' compile time DI library ArC is... something), but at least it breaks before you can deploy it.

rowanG077 3y ago

The problem is that no one can define magic. The thing that you might find magic is someone else mundane code or vice versa. It's simply a catch all statement that a lazy reviewer can slap on code they don't like. Just explain why you don't like it and be done with it.

EdwardDiego 3y ago
That's a fair point, what's magic and what's a good abstraction is highly subjective. I guess I'm a fan of the principle of least surprise. I'd far rather explicitly define a configuration property in some file than "if you create an environment variable called FOO_CONFIG_X=5, the Foo framework will populate your settings for you!" Because when the Foo framework doesn't respond to your incantations the way the docs say it should, then you're going to spend the rest of the day reading code to figure out why. Shit, the Spring annotation magic made me miss XML context files for that reason, the XML made wiring explicit, as opposed to auto wiring annotations that failed deep in the bowels of the beast. It's a continual problem across languages and frameworks, the (admittedly very) convenient magic is great until it isn't. I've lost enough time on it in my career that these days the only dependency injection libraries I'll consider for a new project have to be compile time. Still as much magic, possibly even more (trying to understand Quarkus' compile time DI library ArC is... something), but at least it breaks before you can deploy it.