When is abstraction and modulation of bad programming practice?

Question

just saw this comment in "that you are using JS lib".

"@Xanti - yes, yes, modulation and abstraction in programming is a terrible practice. Functions that call other functions? Wasteful."

And that left me curious because I use the Kohana framework for PHP and the jQuery library for javascript.

Why do some people consider the wrong practice of abstraction and modulation? Are frameworks and libraries created to facilitate and speed up development?

here is a link to the survey

Answer 1

I found that too much abstraction can be dangerous for your performance:

• A poorly selected abstraction can be worse than an abstraction in general.

• If you need to read four or five different modules to understand how a simple algorithm works, then the barriers of abstraction are probably not in the right places. Maybe there is a good way to reorganize the code, or maybe it would be easier to simply remove the barriers.

• If the abstraction does not correspond to a relatively familiar idea, it may be difficult for new team members to find out.

Abstraction is not a "meaningless home"; it exists to meet specific goals. Among the most common goals are

• To protect data structure invariants

• To encapsulate design decisions that may change

My biggest experience with abstraction that was bothering us was with our research compiler for C-- . There was much more abstraction than students were used to seeing in the compiler class:

• The target machine was abstract.
• Assembly language was abstract.
• The calling conventions were abstract
• Stack layout uses unusual "block" abstraction

Each of these abstractions served an important purpose for our research, but the overall effect was that it was very difficult for new students to learn the compiler. Thus, even if the original comment was a joke, there are places where abstraction can cause problems.

Answer 2

When working with limited resources, it can easily add overhead.

We are sure that the compiler compiler will be optimized, but if you create four neat objects in four neat .c files, compile them into four neat .so files, and then link them to a silent linker, calling cross-module functions that could be easily nested, are still being executed with a full dump of state, details that can be fully optimized are still being executed, etc.

I assure you that if you start programming an 8-bit PIC microcontroller with 4K RAM and 16K Flash, using the best practices of object-oriented languages, using advanced design patterns and creating more than one level of abstraction, your program will never work. "Premature optimization is the root of all evil," said the guy who never programmed a platform with 128 bytes of RAM.

Answer 3

We can assume that the commentator was not serious.

I cannot imagine anyone claiming that modulation and abstraction is bad practice and actually does mean that.

Answer 4

Abstraction and modulation in general are good and important. There may be poor abstractions, for example: frameworks that are no longer supported or expensive or simply not used, or large, or outdated, or the 2nd choice, and so on. The library "market" as a whole is huge. Which libraries you use depends on the circumstances and personal preferences.

Why do some people consider the wrong practice of abstraction and modulation? Are not libraries created to facilitate and accelerate development?

Change and learning are sometimes difficult, so people struggle with it. If you like to study this look, you can start your research: http://thedailywtf.com/ :-) I would just ignore them and use the libraries and as they serve you and improve the work of your programmer.

Answer 5

The developer will state that abstraction or modulation is bad practice when they can or should interact with the specified abstraction or modular structure and cannot understand its purpose or design.

Answer 6

When each function (and auxiliary functions) is in its own module?

Answer 7

It was a bit quiet, but the manual for the fortran compiler recommended choosing identifiers in the form of strings of the same length and randomly selected letters.

Explanation? it allows you to evenly distribute the names in the compiler’s internal hash table and because of this provides faster compilation.

I think the text you are quoting is next to this recommendation

Answer 8

Good abstractions are often used.

Good abstractions refer to 2 or more places in your software.

Examples:

• Functions with +2 + sites.
• An abstract class with 2+ concrete classes.
• Interfaces with 2+ implementations.
• Common with 2+ instances
• Libraries with 2+ users.
• and etc.

An abstraction that refers to 2 or more places helps reduce code size by decomposing common things, which is good.

But if you have many abstractions that are referenced only once, then this is a good chance that the abstraction is not needed.

Some examples where unnecessary abstractions occur:

• Writing object code (interfaces and abstract classes having only 1 implementation or nodule). These interfaces and abstract classes are not needed (at this moment of development). The principle of YAGNI.
• Someone creates a "brilliant new" interface on the old one, where new functions, after some conversion, call only 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 one call site, so they are not needed. You need to move the code from the old functions to the new one or not to write a new one and change the old one.

Some examples of really good abstractions:

• Equipment abstraction level: provides a single interface for applications, so they do not need to develop code for each type of equipment.
• File System: It doesn't matter if you use FAT, NTFS, EXT3. It allows you to use files and directories, the file system driver does the rest.
• C language: you do not need to port your program for each CPU architecture. Just compile it.

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

As for modulation, its subjectivity: you can organize your code the way you want. If the source code of the library is in the same source file, this does not make it worse than if you put several hundred files into it.

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