Update

c_tutorial.md

@@ -35,12 +35,12 @@ Potentially supplemental articles to this tutorial are:
 - Very **widely supported and [portable](portability.md)** to almost anything.
 - **[Low level](low_level.md)**, i.e. there is relatively little [abstraction](abstraction.md) and not many comfortable built-in functionality such as [garbage collection](garbage_collection.md), you have to write many things yourself, you will deal with [pointers](pointer.md), [endianness](endianness.md) etc.
 - [Imperative](imperative.md) (based on sequences of commands), without [object oriented programming](oop.md).
-- Considered **hard**, but in certain ways it's simple, it lacks [bloat](bloat.md) and [bullshit](bullshit.md) of "[modern](modern.md)" languages which is an essential thing. It will take long to learn (don't worry, not nearly as long as learning a foreign language) but it's the most basic thing you should know if you want to create good software. You won't regret.
-- **Not holding your hand**, i.e. you may very easily "shoot yourself in your foot" and crash your program. This is the price for the language's power.
-- Very old, well established and tested by time.
-- Recommended by us for serious programs.
+- Considered rather **difficult to learn**, but in certain ways it's simple, it lacks [bloat](bloat.md) and [bullshit](bullshit.md) of "[modern](modern.md)" languages which is an essential thing. It will take long to learn (don't worry, not nearly as long as learning a foreign language) but it's the most basic thing you should know if you want to create good software. You won't regret.
+- **Not holding your hand**, i.e. you may very easily "shoot yourself in your foot" and crash your program. This is the price for the language's power. It can also be [fun](fun.md).
+- Very [old](old.md), well established and tested by time.
+- One of the languages recommended by [us](lrs.md) for serious programs.
 
-If you come from a language like [Python](python.md) or [JavaScript](javascript.md), you may be shocked that C doesn't come with its own [package manager](package_manager.md), [debugger](debugger.md) or [build system](build_system.md), it doesn't have [modules](module.md), [generics](generics.md), [garabage collection](garbage_collection.md), [OOP](oop.md), [hashmaps](hashmap.md), dynamic [lists](list.md), [type inference](type_inference.md) and similar "[modern](modern.md)" features. When you truly get into C, you'll find it's a good thing. 
+If by chance you're already familiar with languages like [Python](python.md) or [JavaScript](javascript.md), you may be shocked that C doesn't come with its own [package manager](package_manager.md), [debugger](debugger.md) or [build system](build_system.md), it doesn't have [modules](module.md), [generics](generics.md), [garabage collection](garbage_collection.md), [OOP](oop.md), [hashmaps](hashmap.md), dynamic [lists](list.md), [type inference](type_inference.md) and similar "[modern](modern.md)" features. When you truly get into C, you'll find it's a [good](good.md) thing.
 
 Programming in C works like this:
 
@@ -48,13 +48,13 @@ Programming in C works like this:
 2. You compile the file with a C [compiler](compiler.md) such as [gcc](gcc.md) (which is just a program that turns source code into a runnable program). This gives you the executable program.
 3. You run the program, test it, see how it works and potentially get back to modifying the source code (step 1).
 
-So, for writing the source code you'll need a [text editor](text_editor.md); any [plain text](plain_text.md) editor will do but you should use some that can highlight C [syntax](syntax.md)  -- this helps very much when programming and is practically a necessity. Ideal editor is [vim](vim.md) but it's a bit difficult to learn so you can use something as simple as [Gedit](gedit.md) or [Geany](geany.md). We do NOT recommend using huge programming [IDEs](ide.md) such as "VS Code" and whatnot. You definitely can NOT use an advanced document editor that works with [rich text](rich_text.md) such as [LibreOffice](libreoffice.md) or that [shit](shit.md) from Micro$oft, this won't work because it's not plain text.
+So, for typing source code you'll need a [text editor](text_editor.md); any [plain text](plain_text.md) editor will do but you should use some that can highlight C [syntax](syntax.md)  -- this helps very much when programming and is practically a necessity. Ideal editor is [vim](vim.md) but it's a bit difficult to learn so you can use something as simple as [Gedit](gedit.md) or [Geany](geany.md). We do NOT recommend using large programming [IDEs](ide.md) such as "VS Code" and whatnot. You definitely can NOT use an advanced document editor that edits [rich text](rich_text.md) such as [LibreOffice](libreoffice.md) or that [shit](shit.md) from [Micro$oft](microsoft.md), this won't work because it's not plain text.
 
 Next you'll need a C [compiler](compiler.md), the program that will turn your source code into a runnable program. We'll use the most commonly used one called [gcc](gcc.md) (you can try different ones such as [clang](clang.md) or [tcc](tcc.md) if you want). If you're on a [Unix](unix.md)-like system such as [GNU](gnu.md)/[Linux](linux.md) (which you probably should), gcc is probably already installed. Open up a terminal and write `gcc` to see if it's installed -- if not, then install it (e.g. with `sudo apt install build-essential` if you're on a Debian-based system).
 
-If you're extremely lazy, there are online web C compilers that work in a web browser (find them with a search engine). You can use these for quick experiments but note there are some limitations (e.g. not being able to work with files), and you should definitely know how to compile programs yourself.
+If you're super lazy (as programmers often are), you may appreciate the existence of online web C compilers that conveniently work in a web browser (search for "online C compiler" or something). These may serve for quick experimentation but, as could be expected, browser tools won't replace the real deal, there are limitations (e.g. not being able to install [libraries](library.md) and so on), and you should definitely know how to compile programs yourself.
 
-Last thing: there are multiple standards of C. Here we will be covering [C99](c99.md), but this likely doesn't have to bother you at this point.
+And one last note: there are multiple standards of C. Here we will be covering [C99](c99.md), but this likely doesn't have to bother you at this point. Let's proceed to some real action now.
 
 ## First Program
 
@@ -1729,7 +1729,7 @@ Of course, you may use the prints in other ways, for example to detect at which
 
 What if the program isn't exactly crashing but is giving wrong results? Then you need to trace the program step by step (not exactly line by line, but maybe function by function) and check which step has a problem in it. If for example your game AI is behaving stupid, you firstly check (with prints) if it correctly detects its circumstances, then you check whether it makes the correct decision based on the circumstances, then you check whether the pathfinding algorithm finds the correct path etc. At each step you need to know what the correct behavior should be and you try to find where the behavior is broken.
 
-Knowing how to fix a bug isn't everything, we also need to find the bugs in the first place. **[Testing](testing.md)** is the process of trying to find bugs by simply running and using the program. Remember, testing can't prove there are no bugs in the program, it can only prove bugs exist. You can do testing manually or automate the tests. Automated tests are very important for preventing so called **[regressions](regression.md)** (so the tests are called regression tests). Regression happens when during further development you break some of its already working features (it is very common, don't think it won't be happening to you). Regression test (which can simply be just a normal C program) simply automatically checks whether the already implemented functions still give the same results as before (e.g. if *sin(0) = 0* etc.). These tests should be run and pass before releasing any new version of the program (or even before any commit of new code).
+Knowing how to fix a bug isn't everything, we also need to find the bugs in the first place. **[Testing](testing.md)** is the process of searching for bugs by simply running and using the program. Remember, testing can't prove there are no bugs in the program, it can only prove bugs exist. You can do testing manually or automate the tests. Automated tests are very important for preventing so called **[regressions](regression.md)** (so the tests are called regression tests). Regression happens when during further development you break some of its already working features (it is very common, don't think it won't be happening to you). Regression test (which can simply be just a normal C program) simply automatically checks whether the already implemented functions still give the same results as before (e.g. if *sin(0) = 0* etc.). These tests should be run and pass before releasing any new version of the program (or even before any commit of new code).
 
 [Optimization](optimization.md) is also a process of improving an already working program, but here we try to make the program more efficient -- the most common goal is to make the program faster, smaller or consume less [RAM](ram.md). This can be a very complex task, so we'll only mention it briefly.
 
@@ -1737,7 +1737,7 @@ The very basic thing we can do is to turn on automatic optimization with a compi
 
 ## Final Program
 
-Now is the time to write a final program that showcases what we've learned, so let's write a quite simple but possibly useful [hex viewer](hex_editor.md). The program will allow us to interactively inspect bytes in any file, drawing their hexadecimal values along with their addresses, supporting one character commands to move within the file. If you want, you can take it and improve it as an exercise, for example by adding more viewing modes (showing decimal octal or ASCII values), maybe even allowing editing and saving the file. Here is the source code:
+Now comes the time for the final program to showcase what we've learned, so let's write a quite simple but possibly useful [hex viewer](hex_editor.md). The program will allow us to interactively inspect bytes in any file, drawing their hexadecimal values along with their addresses, supporting one character commands to move within the file. If you want, you can take it and improve it as an exercise, for example by adding more viewing modes (showing decimal octal or ASCII values), maybe even allowing editing and saving the file. Here is the source code:
 
 ```
 /* Simple interactive hex file viewer. */
@@ -1890,7 +1890,7 @@ Let's stress you should only get into graphics after you've written several pure
 
 For start please note that:
 
-- **C itself doesn't know anything about graphics**. C is just trying to be a good programming language, it leaves the vast area of graphics for others to solve, therefore though you can try to avoid it (see below), typically you will use a third party [library](library.md) to draw some real pixels to the screen, there isn't a universal way of doing it, you have to choose specific solution based on what you want to achieve, what's available etc.
+- **C itself doesn't know anything about graphics**. C merely focuses on being a good programming language, it leaves the vast area of graphics for others to solve, therefore even though you can try to avoid it (see below), typically you will use a third party [library](library.md) to draw some real [pixels](pixel.md) to the screen, there isn't a universal way of doing it, you have to choose specific solution based on what you want to achieve, what's available etc.
 - **By graphics we really just mean drawing [pixels](pixel.md)**. Things like keyboard and mouse [input](io.md) (which you need for anything [interactive](interactivity.md) like [games](game.md)), loading [PNG](png.md) pictures, playing sounds, loading and displaying 3D models, detecting [collisions](collision.md) of virtual objects and so on won't necessarily be covered here, it's all too much to learn at once. We will ONLY be trying to show basic shapes on the screen.
 - We'll be doing things in simplified ways here, omitting common [optimizations](optimization.md), safety checks and so on. Just know that in practice things will be yet a bit more complex.