3 ms·

> Magically, fib is now fast Any code you describe with "Magically" is going to bite you in the arse in about two months. Maybe three. Leave magic to the guy

> Magically, fib is now fast Any code you describe with "Magically" is going to bite you in the arse in about two months. Maybe three. Leave magic to the guy who also does balloon animals at kids parties.

rowanG077 3y ago
I can't disagree more with this. Running any modern language is magic. If you don't want to use magic. You only get to write assembly or maybe C. Not that I agree with this solution.
- EdwardDiego 3y ago
  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.
fho 3y ago
I would also disagree with that, but maybe not as much as the other guy. I had the pleasure of being able to use Haskell "in anger" for about a year. Still my favorite language to toy around with, but would not want to use it for work again. One take away is that half of the time Haskell code "just works". You write algorithms as you think they should be and often the resulting binary is "good enough™". The other half you spend in the trenches hunting down memory leaks because some thunk was not evaluated and your program is amassing unevaluater expressions until it dies :-)
- EdwardDiego 3y ago
  The other half is the magic that worries me ;) And I'm not picking on Haskell here, I've lost countless hours to weird Spring failures when multiple annotations on one class or method interact poorly and produce a stack-trace deep in the bowels of Spring's annotation processors. Or, well, gestures at Hibernate in general Likewise, Django classes that defy type annotations because they override __new__ and inject nested classes into types, or queries over joins where the join logic between attribute A and type B is magically parsed from an undeclared keyword argument like "A__B__filter" that includes attributes, types and actions in one convenient keyword that no IDE can predict. Like your unevaluated thunks, trying to figure out why "Foo__Bar__bomb_baghdad" didn't actually bomb Baghdad takes a large amount of time. The magic is convenient until it breaks :)

rowanG077 3y ago

I can't disagree more with this. Running any modern language is magic. If you don't want to use magic. You only get to write assembly or maybe C. Not that I agree with this solution.

EdwardDiego 3y ago
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.

fho 3y ago

I would also disagree with that, but maybe not as much as the other guy. I had the pleasure of being able to use Haskell "in anger" for about a year. Still my favorite language to toy around with, but would not want to use it for work again. One take away is that half of the time Haskell code "just works". You write algorithms as you think they should be and often the resulting binary is "good enough™". The other half you spend in the trenches hunting down memory leaks because some thunk was not evaluated and your program is amassing unevaluater expressions until it dies :-)

EdwardDiego 3y ago
The other half is the magic that worries me ;) And I'm not picking on Haskell here, I've lost countless hours to weird Spring failures when multiple annotations on one class or method interact poorly and produce a stack-trace deep in the bowels of Spring's annotation processors. Or, well, gestures at Hibernate in general Likewise, Django classes that defy type annotations because they override __new__ and inject nested classes into types, or queries over joins where the join logic between attribute A and type B is magically parsed from an undeclared keyword argument like "A__B__filter" that includes attributes, types and actions in one convenient keyword that no IDE can predict. Like your unevaluated thunks, trying to figure out why "Foo__Bar__bomb_baghdad" didn't actually bomb Baghdad takes a large amount of time. The magic is convenient until it breaks :)