Here's an example where innocuous decisions can lead to needlessly complex software.

Let's say you're working on some software and you decide to use asprintf, a GNU extension. It's a fairly benign extension, after all, and clearly useful. You might not even notice it's an extension because someone on stackoverflow told you to add -D_GNU_SOURCE to your build 30 problems ago. Your system is glibc anyway.

Now your program doesn't work on musl libc, which eliminates Alpine and Void Linux. It also no longer works on newlib, so that's most embedded devices out. Linux is the only system which ships glibc, so it's also done for on BSD, Minix, and so on. The next big operating system will have to resort to reverse engineering glibc to support your program, since asprintf isn't defined by any standard.

That was just one small, seemingly benign change. What if, knowingly or not, you've made dozens of such changes in your project? What if you pull in a dependency which has made similar concessions? What about transitive dependencies? What if we build an entire industry of computers on the shoulders of software which has made these little compromises, all the way down?

If we're ever going to make it out of this mess, we have a responsibility as programmers to strive for simple software, to dig our way out of this enormous hole we've put ourselves in. The only way up is to become more simple, not more complex.

This is why I see languages like Rust, systems like Fuchsia, and so on - as if they were handing out shovels.

@sir I don't understand what is the link between your reasoning on GNU extensions (which is valid) and Rust language...

Rust is clearly documented and spec will come later to help implement compilers. Meanwhile it is ported to various operating system already and is clearly good at handling FFI and differences between the language version.

@amdg2 Rust does not have a spec, nor multiple implementations. It comes down to complexity and the value of choosing the simplest options in the simplest environments.


@sir > Rust does not have a spec, nor multiple implementations.
True, we are looking at facts here.

> It comes down to complexity and the value of choosing the simplest options in the simplest environments.
Yes, we agree, but how does this relate to Rust being "needlessly complex"

Did you consider all the magic that is happening in the processor and C compiler to make you write your program as if it was running on good old PDP-11? Isn't this overly complex?

· · Web · 1 · 0 · 0

@amdg2 I never said C was perfect, in fact it's far from it. Instead what I said is that Rust is also bad. You don't get to say "but C is bad!" to justify some other language also being bad

@sir seems legit. Then what do you consider good ?

@amdg2 there are no good programming languages, just varying degrees of bad. IMO Go is probably one of the least bad, but I still have serious problems with it. I still prefer C over Rust as well, though again it's not like C is good.

Sign in to participate in the conversation
Diaspodon est une instance majoritairement francophone et généraliste. Aucun contenu du fédiverse n'est filtré par une décision d'administrateur ou de modérateur.