Condensed version: All non-trivial abstractions are a bit leaky. Thus they save us time working, but not time learning, since at some point the abstraction slips and you have to look below it to figure out what's going on.
There's also an interesting example at the end. I quote:
And when you need to hire a programmer to do mostly VB programming, it's not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks.No wonder I dislike VB. Programming is heavily dependent on creating, understanding and using abstractions. After a few years of this, it's hardly surprising that VB sets off alarms in my head. On some subconscious level, my mind can see the leakiness of the VB abstraction, and it is an ugly leakiness. Far uglier than the C++ string class or the inconsistent query execution times of SQL.
Reading this essay has actually made me able to articulate something that I've been trying to say for a long time. It probably doesn't sound as clear as it is in my head, but that's the essential dilemma of communication, eh? Here goes...
Never completely trust abstractions. Not until you understand the stuff they abstract, and just how and where they leak. And even then, stay on your guard.
1 comment:
Ran into a slight snag on the apping, but it should be done by Monday. Came home and proceeded to read stuff, and finally, I went overboard with the blog posts.
Post a Comment