3 ms·

I particularly liked your last paragraph about beginner programmers, and I want to strengthen it. Abstraction is not just a drag on learning programming, it's a

I particularly liked your last paragraph about beginner programmers, and I want to strengthen it. Abstraction is not just a drag on learning programming, it's also a drag on learning new codebases, even if you're already fairly experienced. Abstraction is good for people experienced with a codebase, but as codebases grow larger and more complex that usually means the first few people, because newcomers are rarely able to attain the same grasp of the big picture. This suggests that authors of say open source projects who want to gain more collaborators might want to go against their instincts for abstraction. (This thought crystallized for me after conversations on HN in the past couple of weeks: https://news.ycombinator.com/item?id=8308881 https://news.ycombinator.com/item?id=8308881 and https://news.ycombinator.com/item?id=8327008 https://news.ycombinator.com/item?id=8327008)

Rapzid 12y ago
I would like to second a lot of you're thinking here. I know it's a bit cliched to bring up rails, but I believe this is why a lot of the magic trips people up. It seems to me that the higher level the abstraction the more you end up NEEDING to know about it as you start straying from the tutorials. Nobody cares how puts gets text to the screen, but it doesn't take long before all the magic relationship and routing stuff becomes nagging issue, particularly for new comers and non full-timers. And thus, micro frameworks are becoming super popular for many and especially those jumping between languages/ecosystems regularly. Also, open source projects could seriously do with some dev docs. A UML diagram or two wouldn't hurt either.
userbinator 12y ago
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.

Rapzid 12y ago

I would like to second a lot of you're thinking here. I know it's a bit cliched to bring up rails, but I believe this is why a lot of the magic trips people up. It seems to me that the higher level the abstraction the more you end up NEEDING to know about it as you start straying from the tutorials. Nobody cares how puts gets text to the screen, but it doesn't take long before all the magic relationship and routing stuff becomes nagging issue, particularly for new comers and non full-timers. And thus, micro frameworks are becoming super popular for many and especially those jumping between languages/ecosystems regularly. Also, open source projects could seriously do with some dev docs. A UML diagram or two wouldn't hurt either.

userbinator 12y ago

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.