Update

abstraction.md

@@ -4,7 +4,7 @@ Abstraction is an important concept in [programming](programming.md), [mathemati
 
 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.
+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 programming languages 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. The art of choosing right abstraction ([model](model.md)) is important e.g. in designing computer [simulations](simulation.md) -- if we want so simulate e.g. human society, do we simulate individual people in it or just societies as whole entities? Do we simulate wars as a simple dice roll or do we let individual soldiers fight their own battles? Do we represent roads as actual surfaces on top of which cars move according to laws of physics, or do we simplify to something like mathematical graph connecting cities with mere abstract lines, or something in between like a cellular automaton maybe? Do we consider beings living on a round planet, with possibilities like meteor impacts and space flights, or do we simply consider people living on a flat 2D sheet of paper? Similar though has come to designing [games](game.md) (another kind of simulation).
 
 Let's take a look at a possible division of a [computer](computer.md) to different levels of abstraction, from lowest to highest (keep in mind it's also possible to define the individual levels differently):