When is abstraction and modularization a bad practice in programming?

Question

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

Answer 1

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:

• The target machine was abstract
• The assembly language was abstract
• The calling conventions were abstract
• The stack-frame layout used an unusual "block" abstraction

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

When every function (and helper functions) is in its own module?

Answer 7

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

Answer 8

Good abstractions are used often

Good abstractions are referenced at 2 or more places in your software.

Examples:

• Functions with 2+ call sites.
• Abstract class with 2+ concrete classes.
• Interfaces with 2+ implementations.
• Generics with 2+ instantiations
• Libraries with 2+ users.
• etc.

An abstraction that's referenced at 2 or more places helps reducing the code size, by factoring out the common things, and this is a good thing.

But if you have a lot of abstractions that are referenced only a single time, then there is a good chance that the abstraction is not necessary.

Some examples when unnecessary abstractions come up:

• Writing object happy code (interfaces and abstract classes everywhere having only 1 implementation or concretion). These interfaces and abstract classes are not necessary (at that point of development). YAGNI principle.
• Someone builds a "shiny new" interface upon the old one, where the new functions after some conversion only call the old interface. You can imagine what a big mess is the result, if you repeat this several times. In this case the old functions will have a single call site, so they are not necessary. You need to move the code from the old functions into the new one or don't write a new one and modify the old one.

Some examples of really good abstractions:

• Hardware abstraction layer: provides a single interface to applications so they don't need to develop code for each type of hardware.
• File system: It doesn't matter you use FAT, NTFS, EXT3 whatever. It allows you to use files and directories, the file system driver does the rest.
• C language: You don't need to port your program for each CPU architecture. Just compile it.

So to answer your question pragmatically: Abstractions are bad, when they are referenced from less than 2 places.

With regard to the modularization, its subjective: you can organize your code whatever you want. If your library's source code is in a single source file it doesn't make it worse than if you put explode it several hundreds of files.

When rating your abstractions as good or bad, always consider the big picture: the whole project, the whole product line, etc.