Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The key difference is that those who built the abstraction understand exactly what it abstracts, and thus what its capabilities and limitations are. Those who didn't, don't get quite the same picture.

I'm not a fan of excessive abstraction either - the main thing I use it for is to reduce code duplication, which IMHO is one of the real benefits. Code that contains lots of functions-called-once or classes-used-once feels like a terribly inefficient and obfuscated way to do something, and far less straightforward than it could be.

The whole "abstraction is good because it allows us to build large complex systems" notion is all too common in beginning courses in programming/software engineering architecture, and it tends to make people think that large complex systems are also good. Thus the feeling that somehow all software should be large and complex, and the resulting architecture-astronautism and disturbingly inefficient software. I completely disagree - abstraction should be taught as being a necessary evil for managing complexity, for use only when that complexity is actually justified and cannot be simplified further. Abstraction hides complexity but does not eliminate it; in fact it could be said that it probably adds to it. Code hidden by abstraction is still code that gets executed, consumes resources, and could contain bugs.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: