[palata]

I understand how it may sound like this, given that older people will talk about assembly and electronics which most young developers have absolutely no clue about today and are still considered "software developers".

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.

[BillyTheMage]

> Most emails you receive just contain a couple lines of useful information

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.

[palata]

> Such a simple task but first I have to learn 3 layers of compilers and builder and uggggghhhh.

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.

[BillyTheMage]

It's been a long time since then, but IIRC it was like... there's a compiler for every conceivable CPU ever made, and then there's a layer on top of that for... groupings? and then there's the compiler that bundles all that crap together into something that can run across all the CPUs of the same architecture. And then another layer for something that I can just go "make this for all computers".

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.

[palata]

> there's a compiler for every conceivable CPU ever made

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.

[CoastalCoder]

> People routinely write completely wrong CMakeLists and then complain about CMake being "sooo bad".

I think this conflates a few issues.

I believe you that some people have problems with both CMake and Meson.

But in my opinion CMake's scripting language really is pretty poorly suited for it's role, e.g. because of its blurry distinction between strings and lists.

[palata]

> CMake's scripting language really is pretty poorly suited for it's role

The vast majority of projects only need a handful of features from CMake. Sure, it's a weird language and there is enough to criticise. The fact remains that 99% of the complaints I see are from people who write very bad CMakeLists. First learn how to not make a big mess with it, and then you can start complaining, IMHO.

I have had that with other technologies that "everybody hates but is forced to use". The technology is never perfect, so there are always reasons for criticism. But I see a lot more invalid criticisms from people who don't use the technology correctly than valid ones.

Because Javascript is not perfect does not mean that the developers can't possibly be responsible for a bad Javascript codebase.

[scott_w]

> I understand how it may sound like this, given that older people will talk about assembly and electronics which most young developers have absolutely no clue about today and are still considered "software developers".

As a software engineer in his mid-30s now, I can assure you many "older people" will have little-to-no memory of messing around with assembly and electronics. When I was getting started, my boss told me about an engineer who had a deep knowledge of how to lay out data to efficiently read and process it. My response? "I just stick it in Postgres and it does it all for me!" No shade to that engineer but I do believe he was in his 50s/60s at the time, so it's quite likely he's retired on a decent pension by now!

[palata]

I am not sure exactly where you are going with that. But yeah, sure, not everybody needs assembly.

My point is that because the author uses assembly as an example does not mean that their points are not valid.

[scott_w]

I think even this point about seeing through all the abstractions being "real engineers" still limits you to, basically, people in their 60s at the youngest.

I just think it's a reductionist view and one that's not necessary. Practical example: beyond reading SQL ANALYZE, I have no idea how Postgres organises and queries data beyond a rough understanding of the model that it exposes. I guess I'm not a "real engineer" because I couldn't tell you how that data is laid out on the disk for efficiency. Yet I'm generally able to write pretty performant data models and query it.

I know engineers who can't even do that, yet their knowledge of DOM and browser logic is so fucking insane, they fixed a shitload of longstanding issues in our product. Where is the line on them being "real engineers?" Is that good enough, or do they need to go deeper into the browser?

I know engineers who don't have that level of depth in either, yet they're consistently able to write bug-free code that's extremely well tested. Do they understand how Python bytecode works? No, they don't have a clue (frankly, neither do I). Yet they solve every problem in their space.