from Hacker News

Increasing abstraction is directly proportional to decreasing software quality

by aligajani on 2/16/17, 4:05 AM with 7 comments

It is my observation that if you use a shit ton of abstractions, wrapper libraries, frameworks, so on, your software gets crappier. This is from experience, too. Whereas, if you build something from scratch, that is, reduce reliance on abstractions, the software quality in the long run is more stable. Thoughts?

  • by pattrn on 2/17/17, 11:13 PM

    The best code I've seen uses abstractions to decouple itself from the libraries and frameworks it uses. I don't see any references to libraries or frameworks within the codebase, except in thin layers at the outskirts.

    The worst code I've seen uses 1,000 frameworks and libraries without abstracting its communication with them. It calls their API's directly, inherits from their classes, and passes their domain objects to its own API's.

    Abstractions should reduce complexity, making code more robust and simpler to understand. It doesn't always work out that way, especially when abstractions have poor names, but it can. If abstractions truly decreased productivity, then machine-code programmers would blow everyone else away with their speed and efficiency.

    P.S. I have a deep respect for machine-code programmers.

  • by bjourne on 2/18/17, 12:01 AM

    True, but within reason. For example, if you program in Javascript, you either build your own shitty DOM-library or you rely on a solid one like jQuery.

    In general I would say your claim is much more true than it is false because a piece of software with too many abstraction layers and wrappers is orders of magnitudes harder to fix than one which doesn't have enough of them.

  • by mailslot on 2/16/17, 4:09 AM

    You might have seen some very bad abstractions. In my experience, they almost always make code more flexible, if designed & implemented sanely. My $0.02.

  • by ekvintroj on 2/16/17, 6:14 AM

    <sarcasm> Sure, that's why OOP failed. </sarcasm>