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

Desultory

those people referred to as 'idiots'. You don't want to be using layers upon layer upon layers upon layers of abstraction but a couple of levels is no big deal speed wise and it does speed up development. Everything we do as programmers is based on abstraction so it can't bad a terrible thing. – Farber

what it comes to web-centric stuff abstraction and modularization mean a larger download and a performance penalty. However, most of the time this is negligible and is more than made up for in terms of developer productivity and less bugs. I believe that most people who avoid using js frameworks for this reason are guilty of premature optimization. – Mercymerdith

That comment was clearly in jest. Jesse was responding to Xandi's comment, which smacked of a premature-optimization, "real programmers don't use Pascal" sort of mindset. Jesse was being sarcastic by listing several things that are widely known to be helpful in programming and bashing them for their "wastefulness." – Claudeclaudel

Egor: Can you give an example of how or when that would be the case? I think that abstraction typically means a smaller download. Make it generic, send it to the client once, and they cache it. – Burkhalter

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-- (archival snapshot from 2008 at https://www.cs.tufts.edu/~nr/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.

Preferable

I would say the most common use of abstraction — more common than either of those — is to hide complexity. For example, every human programming language is an abstraction for some target machine language. We don't do this to protect invariants or encapsulate design decisions (at least that's not the only reason), but because it's much easier to think about a problem and express our solution in Python than in x86 assembly. – Claudeclaudel

@Chuck, I think we're using the word 'abstraction' in a different sense. Or maybe we're in agreement: the invariants of efficient data structures are a great source of complexity... – Preferable

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.

Ramonaramonda

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.

Crumb

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.

Celestina

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.

Antwanantwerp

Answer 6

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

Leopard

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

Jaquelinejaquelyn

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.

Ulphia