Update

c.md

@@ -2,9 +2,13 @@
 
 { We have a [C tutorial](c_tutorial.md)! ~drummyfish }
 
-C is a [low level](low_level.md), [statically typed](static_typing.md) [imperative](imperative.md) compiled [programming language](programming_language.md), the go-to language of most [less retarded](lrs.md). It is the absolutely preferred language of the [suckless](suckless.md) community as well as of most true experts, for example the [Linux](linux.md) and [OpenBSD](openbsd.md) developers, because of its good minimal design, level of control, uncontested performance and a greatly established and tested status.
+C is a [low level](low_level.md), structured, [statically typed](static_typing.md) [imperative](imperative.md) compiled [programming language](programming_language.md), the go-to language of [less retarded](lrs.md) programmers. It is the absolutely preferred language of the [suckless](suckless.md) community as well as of most true experts, for example the [Linux](linux.md) and [OpenBSD](openbsd.md) developers, because of its good, relatively simple design, uncontested performance, wide support, great number of compilers, level of control and a greatly established and tested status. C is perhaps the most important language in history, it influenced, to smaller or greater degree, basically all of the widely used languages today such as [C++](c.md), [Java](java.md), [JavaScript](javascript.md) etc., however it is not a thing of the past -- in the area of low level programming C is still the number one unsurpassed language.
 
-C is usually not considered an easy language to learn because of its low level nature: it requires good understanding of how a computer actually works and doesn't prevent the programmer from shooting himself in the foot. Programmer is given full control (and therefore responsibility). There are things considered "tricky" which one must be aware of, such as undefined behavior of certain operators and raw pointers. This is what can discourage a lot of modern "coding monkeys" from choosing C, but it's also what inevitably allows such great performance -- undefined behavior allows the compiler to choose the most efficient implementation.
+It is usually not considered an easy language to learn because of its low level nature: it requires good understanding of how a [computer](computer.md) actually works and doesn't prevent the programmer from shooting himself in the foot. Programmer is given full control (and therefore responsibility). There are things considered "tricky" which one must be aware of, such as undefined behavior of certain operators and raw pointers. This is what can discourage a lot of modern "coding monkeys" from choosing C, but it's also what inevitably allows such great performance -- undefined behavior allows the compiler to choose the most efficient implementation. On the other hand, C as a language is pretty simple without [modern](modern.md) bullshit concepts such as [OOP](oop.md), it is not as much hard to learn but rather hard to master, as any other true art.
+
+C is said to be the **"platform independent [assembly](assembly.md)"** because of its low level nature, great performance etc. -- though C is structured (has control structures such as branches and loops) and can be used in a relatively high level manner, it is also possible to write assembly-like code that operates directly with bytes in memory through [pointers](pointer.md) without many safety mechanisms, so C is often used for writing things like hardware [drivers](driver.md). On the other hand some restrain from likening C to assembly because C compilers still perform many transformations of the code and what you write is not necessarily always what you get.
+
+Mainstream consensus acknowledges that C is among the best languages for writing low level code and code that requires performance, such as [operating systems](operating_system.md), [drivers](driver.md) or [games](game.md). Even scientific libraries with normie-language interfaces -- e.g. various [machine learning](machine_learning.md) [Python](python.md) libraries -- usually have the performance critical core written in [C](c.md). Normies will tell you that for things outside this scope C is not a good language, with which we disagree -- [we](lrs.md) recommend using C for basically everything that's supposed to last, i.e. if you want to write a good website, you should write it in C etc.
 
 ## History and Context
 
@@ -26,7 +30,7 @@ C is not a single language, there have been a few standards over the years since
 - **C17/C18**: Yet another update, yet more bloated and not worth using anymore.
 - ...
 
-LRS should use C99 or C89 as the newer versions are considered [bloat](bloat.md) and don't have such great support in compilers, making them less portable and therefore less free.
+[LRS](lrs.md) should use C99 or C89 as the newer versions are considered [bloat](bloat.md) and don't have such great support in compilers, making them less portable and therefore less free.
 
 The standards of C99 and older are considered pretty [future-proof](future_proof.md) and using them will help your program be future-proof as well. This is to a high degree due to C having been established and tested better than any other language; it is one of the oldest languages and a majority of the most essential software is written in C, C compiler is one of the very first things a new hardware platform needs to implement, so C compilers will always be around, at least for historical reasons. C has also been very well designed in a relatively minimal fashion, before the advent of modern feature-creep and and bullshit such as [OOP](oop.md) which cripples almost all "modern" languages.
 
@@ -41,7 +45,9 @@ The standards of C99 and older are considered pretty [future-proof](future_proof
 
 ## Standard Library
 
-So the standard library (libc) is a subject of live debate because while its interface and behavior are given by the C standard, its implementation is a matter of each compiler; since the standard library is so commonly used, we should take great care in assuring it's extremely well written. As you probably guessed, the popular implementations ([glibc](glibc.md) et al) are [bloat](bloat.md). Better alternatives thankfully exist, such as:
+Besides the pure C language the C standard specifies a set of [libraries](library.md) that have to come with a standard-compliant C implementation -- so called standard library. This includes e.g. the *stdio* library for performing standard [input/output](io.md) (reading/writing to/from screen/files) or the *math* library for mathematical functions. It is usually relatively okay to use these libraries as they are required by the standard to exist so the [dependency](dependency.md) they create is not as dangerous, however many C implementations aren't completely compliant with the standard and may come without the standard library. So for sake of [portability](portability.md) it is best if you can avoid using standard library.
+
+The standard library (libc) is a subject of live debate because while its interface and behavior are given by the C standard, its implementation is a matter of each compiler; since the standard library is so commonly used, we should take great care in assuring it's extremely well written. As you probably guessed, the popular implementations ([glibc](glibc.md) et al) are [bloat](bloat.md). Better alternatives thankfully exist, such as:
 
 - [musl](musl.md)
 - [uclibc](uclibc.md)
@@ -55,10 +61,10 @@ C isn't perfect, it was one of the first relatively higher level languages and e
 - **The specification is also long as fuck**. A good, free language should have a simple definition. It could be simplified a lot by simplifying the language itself as well as dropping some truly legacy considerations (like [BCD](bcd.md) systems?) and removing a lot of undefined behavior.
 - **Some behavior is weird and has exceptions**, for example a function can return anything, including a `struct`, except for an array. This makes it awkward to e.g. implement vectors which would best be made as arrays but you want functions to return them, so you may do hacks like wrapping them instide a struct just for this.
 - **Some things could be made simpler**, e.g. using [reverse polish](reverse_polish.md) notation for expressions, rather than expressions with brackets and operator precedence, would make implementations much simpler, increasing sucklessness.
-- Some things like [enums](enum.md) could be dropped entirely, they can easily be replaced with macros.
-- **The preprocessor isn't exactly elegant**, it has completely different syntax and rules from the main language, not very suckless.
+- Some things like [enums](enum.md) or [bitfields](bitfield.md) could be dropped entirely, they can be done imitated in other ways without much hassle.
+- **The preprocessor isn't exactly elegant**, it has completely different syntax and rules from the main language, not very suckless -- ideally preprocessor uses the same language as the base language.
 - **The syntax isn't perfect**, e.g. it's pretty weird that the condition after `if` has to be in brackets, it could be designed better. Keywords also might be better being single chars, like `?` instead of `if` or the weird long ass names with spaces like `unsigned long long` could be made nicer. A shorter, natural-language-neutral source code would be probably better. Both line and block comments could be implemented with a single character, e.g. `#` which would end either with a newline or another `#`.
-- **Some basic things that are part of the standard library or extensions**, like fixed with types and binary literals, could be part of the language itself.
+- **Some basic things that are part of libraries or extensions**, like fixed with types and binary literals, could be part of the language itself.
 - TODO: moar
 
 ## Basics