Reading boost:: gives me shivers and flashbacks of my Diploma thesis

I still point to wide adoption of boost:: as reason why C++ should never be used. If 4 pages of a single error message isn't enough to convince someone, nothing will.

Those 4 pages of errors are useful as hell though. Some languages are better at giving you just the important bits (Rust) but a lot of languages suffer from "simple errors obscuring complex problems" syndrome.

C++ compile errors, particularly overloading and template errors are normally just some fairly tiny succinct errors (could not find a suitable method/type/operator) with a whole bunch of debug information attached that tells you exactly what the compiler tried and how it came to the conclusion that it could not proceed.

I can take that information and work out exactly why my code is failing to compile 99% of the time but it's rather often in other languages that I get a succinct 1-3 line error that provides little to no context beyond where in the code it is. That leaves me to dig through stack overflow in the hopes that I can find someone with the same error and a similar code layout such that I can determine what is inducing the error.

Don't get me wrong, C++ has a whole lot of issues which justify why things like Rust should be preferred wherever possible but the errors aren't nearly as bad as people make them out to be. I'm much more concerned with the cancer that are C & C++ arithmetic rules(https://twitter.com/hackingcpp/status/1492242039110524935). Likewise for the numerous ways you can accidentally introduce undefined behavior when interacting with non "new C++" code (and even sometimes then as well).

The bigger issue is the template overloading in the first place that makes libraries like boost possible.

A language should not be able to do stuff like this https://blog.mattbierner.com/stupid-template-tricks-super-te.... This is on the same level as JSFuck with javascript.

At its core, template metaprogramming is just functional programming at compile time. STT is just a template and a runtime function which do the following:

1, take an input via compile time flag (the `-D DIRECTION`)

2. take a type input from an included header file containing the current state (`#include "current_game.h"`)

3. via functional programming, compute the results of a single step of the game.

4. specialise a single function using the results of step 3. this function prints the computed result to the screen and the computed game state to a file (`./current_game.h`).

5. gcc/clang exits. compilation is complete.

6. call the compiled binary.

7. the binary runs the specialised function and prints the outputs.

Sure it's fucky and you shouldn't do that in production but what sane individual is writing a piece of code that at runtime (after compiling) seeks out one of its own source files and modifies that file?

To prevent this from being possible you'd have to remove runtime file IO from the language. The other potential solutions wouldn't work:

1. Remove templates entirely: Still would be possible using https://github.com/Hirrolot/metalang99 which solely uses the preprocessor. Given that the pre-processor is literally just term substitution(a glorified copy/paste engine), if you removed that as well, you'd have to accept no form of metaprogramming at all.

2. Remove the ability to #include other files: Could still be done by doing everything inline. `#include` is just copy-paste anyways so it's more an abstraction than anything else to the compiler and preprocessor, it's basically the same as if all the code was pasted into the same file.

That leaves you with removing file IO. Without IO a programming language is basically useless, particularly as a systems programming language.