The problem is not that we forgot how to program, the problem is that we never actually learned how to create a good programming language which avoids these problems.
Just look at the whole build system and module hell of C and C++...
I totally like the language C++ but I hate the tooling around it with a passion. As long as you only need stuff from stdlib then you are fine, but as soon as you want to create some custom library for use in your other projects? Which should compile on Linux and Windows? Either you use make and Visual Studio solutions or you have to fight with cmake... Just thinking about it makes me angry.
For this reason I just don't use C++ very often. It is way easier to just use Python because most stuff is just an 'import library' away and you can concentrate on your actual program instead of fighting against the build system.
But god forbid you actually try to ship your Python program to your customers...
Why do I as a programmer have to deal with all this crap? I want to focus on programming and not on library management amd writing make files. My CPU is idle 95% of the time so there is enough processing power which could solve these problems.
I have high hopes for Rust and it's integrated build/module system!
It sounds like your problem with C/C++ tooling is that it's hard to support Windows. The reason for that is simply that microsoft bundles its own proprietary C++ toolchain with the platform-specific tools that Windows developers need. Windows developers don't want to install a second posix-like toolchain, and os x/bsd/linux developers don't want to install a Windows-like toolchain because in both cases the new toolchain wouldn't integrate as well with the rest of the system, and it would add unnecessary complexity to the operating system.
The problem with proper unix tools, the ones that do one thing well and integrate with other programs as a part of their design, is that they make doing cross platform work a problem, because those other programs might not exist on other platforms. GNU Make works just fine on Windows, but you're not using just make when you write a makefile. Makefiles typically depend on GNU Make, pkg-config, gcc/clang (or another compiler with the same CLI), coreutils, bourne shell, and an assortment of a few other utilities. That means that Makefiles by design will only work on a single platform.
The other operating systems have essentially made themselves into the same platform for these purposes through the use of system package managers. I've heard Windows is kind of getting one? More like homebrew than what we have in linux/bsd-land but that might still help. But maybe Windows developers will still be reluctant to install software with MinGW dependencies. That would be unfortunate, but fair; I wouldn't install a package that had Wine/Mono dependencies just because some asshole wanted to use their Windows build system on Linux! Hell, I avoid installing smaller things with a Qt or GTK3 dependency simply because none of the software I use needs those and I don't want to clutter my installed-packages list for something that isn't important.
I'm not a huge fan of Rust's Cargo. The list of requirements that the Rust team had for their package manager and build system made sense, and if I had to design a tool that met those requirements, it probably would have looked quite a bit like Cargo, but it makes me sad that the most reasonable design is that which abandons the unix-like simplicity of the python and C (and perl?) toolchains.
> It sounds like your problem with C/C++ tooling is that it's hard to support Windows
No, the problem is that there is no standardized way to deal with modules and libraries in C and C++. If it would be in the standard the cross-plattform support would be much better.
> the unix-like simplicity of the python and C (and perl?) toolchains.
For small C projects the make/autotools system might be "simple", but for larger projects? It is horrible.
Supporting multiple platforms is simple. Assume the user has an existing build pipeline and you need to integrate into it. That means doing one of:
1) provide a single, amalgamated .h/.cpp pair
2) provide per-platform, per-config precompiled static and/or dynamic libs
3) provide all dependencies in the form of 1 or 2
Voila! Your goal should be to provide something that can be trivially added to an existing pipeline.
Of course we learned how to create good programming languages which deal with this problem. A very good and thorough approach was introduced with Modula-2, which, as the name hints to, had modules as a main focus point. Building Modula programs was an easy and quick process. The module system lives on today in the form of Golang - one of the founders was a student or Wirth.
Just look at the whole build system and module hell of C and C++...
I totally like the language C++ but I hate the tooling around it with a passion. As long as you only need stuff from stdlib then you are fine, but as soon as you want to create some custom library for use in your other projects? Which should compile on Linux and Windows? Either you use make and Visual Studio solutions or you have to fight with cmake... Just thinking about it makes me angry.
For this reason I just don't use C++ very often. It is way easier to just use Python because most stuff is just an 'import library' away and you can concentrate on your actual program instead of fighting against the build system.
But god forbid you actually try to ship your Python program to your customers...
Why do I as a programmer have to deal with all this crap? I want to focus on programming and not on library management amd writing make files. My CPU is idle 95% of the time so there is enough processing power which could solve these problems.
I have high hopes for Rust and it's integrated build/module system!