| > I take serious issue with the "lesson" that this article is trying to teach at the end, which is that you should not generalize your particular problem into something abstract... The problem, simply stated by Emil Persson is "Premature optimizations can be troublesome to revert, but premature generalizations are often near impossible." Or, less delicately phrased by Chris Eric -- "Premature optimization, that's like a fart. Premature abstraction is like taking a dump on another developer's desk." The root problem is -- you think you know all the possible use cases, you don't. You think you can see the future, you can't. Solve for what is in front of you -- abstract it when you need to for reuse. As for Alan Kay and his fight against complexity (which is fair and nobel fight, great video on it: https://vimeo.com/82301919) -- he is arguing for the RIGHT abstractions from the perspective of DSLs ... with all the good (and very, very bad) that entails. That said, it is 7 levels of bullshit when you get down to "deploy to metal". Sure, it is a few hundred lines of code for a DSL and OMeta to render geometry -- but skip to 1:40:00 for the real scoop. It was incredibly hard to get to run with any level of performance on ACTUAL hardware in the REAL world. Alan Kay even puts forth that you should always keep the option of "rolling your own hardware", which sadly speaks to a disconnect with ACTUAL software development (and hardware development for that matter). There is no doubt he is a legend of CS (and brilliant), but I simply think his perspective is too far away from reality. "Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs." -- Mike Acton (https://youtu.be/rX0ItVEVjHc) |