Discussing abstractions in today’s context is reflecting on the very nature of computer science and software engineering.
Scalable solutions, routine problems
- all pass through the choice of how they will be perceived by end-users at some point, and it is common for us to bury our solutions under layer after layer of abstraction.
We think about ease of understanding, maintenance, and even expansion; but how do we deal with the problems that exist in the parts we cover up with abstraction?
Up to what point do layers of abstraction positively influence our understanding and management of some technology?
According to Neal Ford, abstractions accumulate at levels, and these levels need to be meticulously analyzed while considering their impact on future decisions.
Not that he implies mediocrity for software engineers; what he suggests is a reflective journey, through 10 lessons, which would help us avoid being distracted by all those elaborate abstractions. “‘Don’t confuse abstraction with the object itself’”.
Using high-level abstractions was very important for our evolution, thinking about folders and files instead of zeros and ones.
Thinking about languages and platforms and how we can gain productivity with them may be easier with layers of abstraction because at some point, just like it was and still is for Emacs, easy extensibility in function definitions can turn against the perpetuation of code, which when not maintained can be lost forever or very costly to recover.
Lost threads and more lost code without interpretation?
Martin Fowler covers the topic at: http://martinfowler.com/bliki/InternalReprogrammability.html.
It’s worth seeing the talk: Note that I left the text exactly as written, as requested.