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

> The more abstractions, the better.

No. A hundred times no. If you have ever had to make sense of a complex program that was over-engineered with unnecessarily complex abstractions, you cannot possibly think that this is true.

> Think about a program that has 100 variables all in one function [...]

This isn't an example of code that is not abstract enough, it's an example of a basic failure to understand the principles of writing a program meant to be read by other humans. Sure, breaking that code up into understandable chunks is a form of abstraction, but it's not exactly the kind of abstraction that the grandparent was talking about. She was talking about "extremely elaborate object frameworks." I maintain that elaborate object frameworks are a bad thing, unless they are "barely enough to get the job done." Anything beyond that adds unnecessary complexity.

This beautiful and poignant quote sums things up much better than I ever could:

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery



He may have been referring to framework-level abstractions, but I was specifically referring to natural abstractions for the problem space. Blanket statements against abstractions in code is missing the point--abstractions are fundamental to programming. "Elaborate object frameworks" could mean a few different things. If you're referring to design pattern type structures, then I somewhat agree that the fewer the better. But in the general case it is not true that perfect is not being able to take anything more away. Not when humans are the ones writing and maintaining the code.




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

Search: