"Old man yells at cloud", but in so-so-so many words
replies(3):
But it's not specifically about assembly, it's about software design. You can take a modern programming language (say Swift or Rust) and look at how software written with those languages is architected, and the points still stand: abstractions above abstractions above abstractions because people don't understand the lower levels.
People routinely write completely wrong CMakeLists and then complain about CMake being "sooo bad". But give them Meson and they will make a mess as well. People have no clue about packaging and distribution, so they will say "it sucks sooo badly" and will distribute their code as a docker container, embedded in a 6GB Ubuntu image. Most emails you receive just contain a couple lines of useful information, yet they are generated by higher-level systems, full of HTML and bullshit and it's impossible to read in a simple client. Etc.
Software quality is going down year after year, it is a fact. Probably because it is becoming more and more accessible, but the fact remains.
No matter how many times I do it, I'm always re-shocked by the sheer size of email headers from mainstream email providers. Maybe it's a non-issue but just holy god that's a lot of crap that means absolutely nothing to me.
> [...] and then complain about CMake being "sooo bad"
OoOh yeah I'm one of those. I gave the whole heck up on C++ years ago because of the many many interlocking compilers and compiler-compilers and meta-compilers and makers and whatever else is going on. SOOOOO confusing. Like dude I just want to take this code I have right here... and compile it. Such a simple task but first I have to learn 3 layers of compilers and builder and uggggghhhh.
And don't even get me started on "projects" (i.e. in Visual Studio or whatever). "Project" is not inherent to the language, but they don't teach that to beginners. Everything is taught so anti-agnostically.
I just write a few lines in a CMakeLists and compile C++ code, I don't see where you need "3 layers of compilers and builder and ugggggghhhh".
But I see a lot of C++ projects out there that have a mess of CMakeLists and are impossible to compile. When that happens inside my company, I just rewrite the CMakeLists and remove all the mess, and voila. Then guess what? Some other developer suddenly needs to add a dependency, doesn't take 10s to see how I dealt with dependencies and adds 200 lines of mess for their own dependency. And then they complain about CMake.
And I have actually seen that: I "fixed" a project to bring it down to something like 40 lines of CMakeLists for 10 dependencies. The next dev changed that to 250 lines by adding an 11th dependency and complained about CMake. I changed it back to 43 lines for 11 dependencies. I did it in 3 lines, they did it in 210 and didn't even realised they were wrong. You could say "sure, but they learned from the next time". Nope, they did the same mess in other projects.
Bear in mind I was adamant about not using some fancy I-dont-know-whats-happening IDE with their fancy "projects" and "run buttons". Those are just more confusing. I wanted to WRITE CODE, and then COMPILE THAT CODE, and then RUN THE RESULTING EXECUTABLE. With commands.
I found a Reddit post I made [1] when I was trying to learn C++. Maybe it sheds more light on what I was confused about?
- [1]: https://www.reddit.com/r/AskProgramming/comments/uc2p5q/i_kn...
edit: I'm famously (among friends) bad at the beginner stage. I get angry at things that are obviously more confusing than they need to be. Current thing is CloudFlare tunnels. Just like why does it need to be this hard? I have server. I have domain. Just dammit let me slap a pipe between them.
This is not specific to C++, that's just how computers work.
I think it's important to understand that at the lowest level, different hardware works differently. A bit like if you take the pedals from your car and put them on your bike, your bike won't suddenly accelerate when you press the gas pedal. For instance, different CPU architectures have different sets of instructions; machine code compiled for one just doesn't fit in the other.
The programming language is an abstraction. You can write code in C (which can be seen as a standardised set of instructions, I guess) and "compile" it for the CPU architecture you want. The "compiler" is the thing that understands C and translates it to machine code. It is an abstraction itself: you could write the machine code (the bits) manually, but it's easier to write C. The abstraction is here to make it "easier", but it's usually not perfect. When you need very very high performance, it's not uncommon to look at the assembly level.
So yeah, if you want to compile for ARM, you need a compiler that knows how to translate your C into the ARM set of instructions. Now there are "families" of architectures, I guess that's what you mean by "groupings"? Say you build parts for cars. If you build pedals that fit in one car model A, they won't necessarily fit in car model B. But there can be variants of car A: automatic or manual. They have different sets of pedals: the manual one has a clutch pedal that does not exist in automatic. If you build the whole set of pedals for car model A, you have to know about that and provide a set for the automatic flavour and another set for the manual flavour. But if you only build gas pedals, you don't have to care: all the flavours of A have the same gas pedal. Some CPUs share a lot of instructions, but not all of them. Maybe there is a flavour of CPU that provides new instructions that are more efficient for some computations. If you don't care about performance, you can just use the "basic set of instructions", but if you actually want to leverage those efficient instructions specific to that particular CPU... well you have to use a compiler that knows about them.
In C/C++, you can't "make this for all computers". It's not possible to make one binary that works everywhere, just because there are very different systems (be it different CPU architectures, but also just the file format between Windows and Linux for instance). But there are ways to abstract that, for instance that's what the JVM does. Instead of compiling your Java (or Kotlin, Scala, etc) to machine code, your compiler compiles it to JVM bytecode. That's an abstraction again. Bytecode is just code that the JVM can run with. And this "works everywhere" in the sense that "it works as long as you have a JVM that can run it". But there are tons of different JVM binaries, because you can't just make one that runs everywhere. It's just that someone built a JVM for your machine, so that now you can run any JVM program on it. But the JVM itself is very much not portable.
It's all about abstraction. If you work in Javascript or Python, you may never have to know about anything that's happening below, because you live in your nice abstraction level. But as soon as you want to compile a native binary, you have to go down the abstraction layers and start understanding more of what's happening. It's not a C++ problem: you can compile Kotlin code to a native binary and you'll have the same problems. Same for any language that compiles to a native binary.
> I get angry at things that are obviously more confusing than they need to be.
Are they obviously more confusing than they need to be, or is the world just more complicated than one might expect? Computer are extremely complex machines. If something is easy, that's because you're staying at a comfortable abstraction level (with all the limitations that come with it).
I hope this helps.