Update

programming_tips.md

@@ -8,6 +8,7 @@ This is a place for sharing some practical programming tips.
 - **No indentation for temporary code**: Tiny "workflow" tip: when adding new code, keep it unindented so that you know it's the newly added code and can delete it at any time. Only when you test the added code, indent it correctly to incorporate it as the final code. Of course, this fails in languages where indentation matters ([Python](python.md) cough cough) but similar effects can be achieved e.g. by adding many empty lines in front of/after the temporary code.
 - **[Comments](comment.md)/[preprocessor](preprocessor.md) to quickly hide code**: It is a basic trick to comment out lines of code we want to temporarily disable. However preprocessor may work even better, e.g. in C if you want to be switching between two parts of code, instead of constantly commenting one part and uncommenting the other just use `#if 0` and `#else` directives around the two parts. You can switch between them by just changing 0 to 1 and back. This can also disable parts of code that already contain multiline comments (unlike a comment as nested multiline comments aren't allowed).
 - **[KEEP IT SIMPLE](kiss.md)** and keep it [LRS](lrs.md), do not blindly follow mainstream ways and "workflows" as those are more often than not horrible. For example instead of using some uber bug tracker, you should use a simple plaintext TODO.txt file; instead of using and IDE use [vim](vim.md) or something similar. Stay away from [OOP](oop.md), [dependencies](dependency.md) etc.
+- **It's hard, but you MUST adopt good minimalist tools, avoid the easy path of big shiny "comfortable", easy-to-learn [IDE](ide.md)s and languages**: this must come naturally with [LRS](lrs.md) mindset but still can't be overstressed because nowadays you'll be constantly pressured to start using this newest [modern](modern.md) [GUI](gui.md) programming tool with [AI](ai.md) assistant and nodes programming and zoomable code minimap that has a debugger and space rockets built right but succumbing to the pressure is short sighted and will reduce you to a zombie, a mere [coding](coding.md) monkey, you'll never actually acquire true control, understanding and craftsmanship, you'll just become a well paid button pressing slave no different from the cashier at a supermarket. It is difficult to learn tools like [vim](vim.md), [gdb](gdb.md), [C](c.md), [Forth](forth.md), [assembly](assembly.md) etc., but it's required in order to become a truly good, independent programmer, you will probably have to FORCE yourself to it, but it's the best investment of your time and energy: it's a long term investment you will later on thank yourself for. Choosing the more difficult but long-term-valuable road must become henceforth your mindset, this will apply whenever you can comfortably use a library or rather invest more energy into learning the math and programming your own library -- this is the difference between someone who uses a translator app on his smartphone and someone who learns to speak the foreign language, it's the difference between a computer slave and a good programmer.
 - **Never listen to advice of anyone who does programming for living** (not [anymore](21st_century.md)), he's most definitely accustomed to the worst ways of programming and will try to push you to [OOP](oop.md), [bloat](bloat.md), [proprietary](proprietary.md) tech, [tranny software](tranny_software.md), [GitHub](github.md) etc. Listening to advice of such people is like taking advice on whether to take drugs from a drug dealer.
 - **Most true programming is done away from the computer** -- soydevs think that a good programmer just spends hours in front of a computer bashing the keyboard and drinking litres of coffee to stay alive and [PRODUCTIVE](productivity_cult.md); indeed, they usually do, but they are not good programmers, their time is spent slaving the computer doing [maintenance](maintenance.md), debugging, googling, updating and socializing on Twitter. A good programmer actually programs everywhere: when going for walk, before falling asleep, when sleeping, when watching a movie etc. He only starts writing a serious program after years of thinking about it and already having most of it programmed in his head; sitting in front of a computer and writing the algorithm down is only the final smaller part of the journey.
 - It can't be repeated enough times: minimize ALL kinds of [dependencies](dependency.md), don't use what you don't necessarily need -- this doesn't just apply to libraries but also design decisions. E.g. if you're making a compiler, make it a single pass compiler if at all possible, don't perform several source code passes if that's not absolutely necessary (which would however likely signify some flaw in the design of your language). Use [fixed point](fixed_point.md) instead of [floating point](float.md) if you can, [software rendering](sw_rendering.md) instead of GPU rendering etc. If you're making something that transforms text to another text (e.g. machine translation), make it a [filter](filter.md) with constant memory complexity if that's possible, i.e. do not require the program to load a whole input file to memory. Etcetc.