Update
This commit is contained in:
parent
5c43f56dc3
commit
1c2717e515
8 changed files with 48 additions and 29 deletions
|
@ -2,7 +2,7 @@
|
|||
|
||||
Abstraction is an important concept in [programming](programming.md), [mathematics](math.md) and other fields of science, philosophy and art, which in simple words can be described as "viewing an issue from a distance", thinking in higher-level concepts, i.e. paying less attention to fine detail so that one can see the bigger picture. In programming for example we distinguish [programming languages](programming_language.md) of high and low level of abstraction, depending on how close they are "to the [hardware](hardware.md)" (e.g. [assembly](assembly.md) being low level, [JavaScript](js.md) being high level); in [art](art.md) high abstraction means portraying and capturing things such as ideas, feelings and emotions with shapes that may seem "distant", not resembling anything concrete or familiar. We usually talk about different **levels of abstraction**, depending on the "distance" we take in vieweing the issue at hand -- this concept may very well be demonstrated on [sciences](science.md): particle [physics](physics.md) researches the world at the lowest level of abstraction, in extreme close-up, for example by examining individual atoms that make up our brains, while [biology](biology.md) resides at a higher level of abstraction, viewing the brain at the level of individual cells, and finally [psychology](psychology.md) shows a very high level of abstraction because it looks at the brain from great distance and just studies its behavior.
|
||||
|
||||
In mainstream [programming](programming.md) education it is generally taught to "abstract as much as possible" because that's aligned with the [capitalist](capitalism.md) way of technology -- high abstraction is easy to handle for incompetent programming monkeys, it helps preventing them from making damage by employing billions of safety mechanisms, it also perpetuates the cult of never stopping layering of the abstraction sandwich, creating [bloat](bloat.md), bullshit jobs, it makes computers slower, constantly outdated and so drives software consumerism. **This is extremely wrong.** [LRS](lrs.md) advocates to employ only as little abstraction as needed, so as to support [minimalism](minimalism.md), i.e. **too much abstraction is bad.** For example a widely used general purpose programming language should basically only have as much abstraction as to allow [portability](portability.md), it should definitely NOT succumb high abstraction such as [object obsessed programming](oop.md).
|
||||
In mainstream [programming](programming.md) education it is generally taught to "abstract as much as possible" because that's aligned with the [capitalist](capitalism.md) way of technology -- high abstraction is easy to handle for incompetent programming monkeys, it helps preventing them from making damage by employing billions of safety mechanisms, it also perpetuates the cult of never stopping layering of the abstraction sandwich, creating [bloat](bloat.md), [hype](hype.md), bullshit jobs, it makes computers slower, constantly outdated and so drives software [consumerism](consumerism.md). As with everything in capitalism, new abstractions are products hyped on grounds of immediate benefit: creating more comfort, being something new and "[modern](modern.md)", increasing "[productivity](productivity_cult.md)", lowering "barriers of entry" so that ANYONE CAN NOW BE A PROGRAMMER without even knowing anything about computers (try to imagine this e.g. in the field of medicine) etc. -- of course, long term negative effects are completely ignored. **This is extremely wrong.** It is basically why technology has been on such a huge downfall in the latest decades. Opposing this, [LRS](lrs.md) advocates to employ only as little abstraction as needed, so as to support [minimalism](minimalism.md). **Too much abstraction is bad.** For example a widely used general purpose programming language should basically only have as much abstraction as to allow [portability](portability.md), it should definitely NOT succumb high abstraction such as [object obsessed programming](oop.md).
|
||||
|
||||
In a more detailed view abstraction is not one-dimensional, we may abstract in different directions ("look at the issue from different angles"); for example [functional](functional.md), [logic](logic_paradigm.md) and [object](object.md) paradigms are different ways of abstracting from the low level, each one in different way. So the matter of abstracting is further complicated by trying to **choose the right abstraction** -- one kind of abstraction may work well for certain kinds of problems (i.e. solving these problems will become simple when applying this abstraction) but badly for other kinds of problems.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue