3 ms·
After reading all that, my only thought is: "Now let's see you debug that." IMHO the more abstract and complex a system is, the more chances that something wil
by userbinator 3y ago
After reading all that, my only thought is: "Now let's see you debug that."
IMHO the more abstract and complex a system is, the more chances that something will go wrong. When one has to figure out what's actually happening among a huge mess of overly-abstracted code, simple and straightforward always wins. Perhaps it's some kind of job security.
- mst 3y agoHaving been one of the earliest non-author adopters of https://p3rl.org/Future https://p3rl.org/Future the difference between having a simple (FSVO) callback and a 'thing' with a reasonably predictable API shape was huge once you were doing more than one thing at once (which, if you aren't, async may be overkill anyway). Plus with a known interface between the code completing the work and the code wanting the result of the work gives you a much clearer boundary rather than having to keep all of the specific async model underlying it in your head (you'll still need -some- of it while debugging, sure, but much less). So while your view about over-abstraction is often on point, I think in this case people will find that in practice it's no harder - and in some cases easier - to debug code written to the proposed standard. I have had to drag people kicking and screaming into the Future before now, but in the end they've all thanked me.