just saw this comment in a "what JS lib do you use" poll
"@Xanti - yes, yes, modularization and abstraction in programming is a terrible practice. Functions that call other functions? Wasteful."
And that left me curious because I am using Kohana framework for PHP and Jquery library for javascript.
Why do some people consider abstraction and modularization bad practices? Are not frameworks and libraries made to ease and speed up development?
here's a link to the poll
We can probably assume the commenter was not being serious.
I can't imagine anyone claiming modularization and abstraction are bad practice and actually meaning it.
Abstraction and modularization in general are good and essential. There might be bad abstractions out there, e.g: frameworks which are not supported anymore or expensive or just not usable, or big, or outdated, or 2nd choice, et cetera. The library "market" in general is huge. Which kind of libraries you find yourself using depends on circumstance and personal preference.
Why do some people consider abstraction and modularization bad practices? Are not frameworks and libraries made to ease and speed up development?
Change and learning is sometimes hard - so people fight it. If you like to study this kind, you could start your research at: http://thedailywtf.com/ :-) I would just ignore them and use libraries and frameworks as they serve you and make your programmer life better.
It was quiet some time ago but a manual for a fortran compiler recommended choosing identifiers as strings of the same length and randomly selected letters.
Explanation? well it allows for even distribution of the names in the internal compiler hashtable and because of this provides for faster compilation.
I think that the text you are quoting belongs right next to this recommendation
I have found that too much abstraction can be hazardous to your productivity:
A poorly chosen abstraction can be worse then no abstraction at all.
If you need to read four or five different modules in order to understand how a simple algorithm works, then the abstraction barriers are probably not in the right places. Maybe there's a good way to refactor the code, or maybe it would be easier just to remove the barriers.
If the abstraction does not correspond to a relatively familiar idea, it may be difficult for new team members to learn.
Abstraction is not a "mindless good"; it exists to serve specific purposes. Among the most common purposes are
To protect the invariants of a data structure
To encapsulate design decisions that are likely to change
My biggest experience with abstraction getting in the way was with our research compiler for C--. There was a great deal more abstraction than students were used to seeing in compiler class:
Each of these abstractions served an important purpose for our research, but the total effect was that it was very difficult for new students to learn the compiler. So, even if the original comment was in jest, there are places where abstraction can cause problems.
A developer will claim that an abstraction or modularization is a bad practice when they are able or required to interact with said abstraction or modularization and are unable to understand its purpose or design.
When working on limited resources, it can easily add overhead.
Sure there are things compiler will optimize away, but if you create four neat objects in four neat .c files, compile them to four neat .so files and then link them with a dumb linker, cross-module function calls that could be easily inlined are still made with full state dump, pieces that could be optimized away entirely are still executed, and so on.
I assure you if you start programming an 8-bit PIC microcontroller with 4K RAM and 16K Flash using best practices of object oriented languages, using advanced design patterns and creating more than one abstraction layer, your program will never run. "Premature optimization is a root of all evil" was said by a guy who never programmed for a platform that has 128 bytes of RAM.