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.
@epicmorphism @sir @amdg2 MIR (it's intermediate representation) is also formally verified (or at least most of it is?)
And for what I used it for, Rust's complexity allowed me to write simpler software than C or C++.
And the memory safety benefits it brings are not negligible. Now that we have rust we can actually see how linear types are used in practice, and the next implementation can learn from that and simplify things. But we needed a language people actually used to get there.
@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?
@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.
@sir mmmh, that explains some rant of yours 😅
@sir Just for the sake of absolute correctness, note that asprintf is implemented in musl (alongside some other GNU extensions). That said, it's still non-standard and not implemented by all libcs.
@sir but why does glibc have non standard extensions?
@sir because it's lacking in the base language
@sir in other words - - the problem is that C is /too simple/
@a_breakin_glass none of this is true
@epicmorphism yo Rust doesn't have a specification and literally defines no behavior
I'm maintaining C software written from 1988-2003, and the decline in maintainability in the more recent software is remarkable. The Diplomacy judge, written in 1988 and maintained through 1995 with Draconian attention to dependencies and no significant changes since, consistently builds on any posix system
To Boldly Go, 1995-2001, compiles as long as I can track down version 1 of a CGI library, but I needed to revert out some changes from a subsequent maintainer to have a successful launch
Olympia: The Age of Gods was written in the late 90s, but source code from before ~2010 isn't available. I still don't have that SOB running yet
I'm using Ubuntu on my leased hardware and my 64 bit single board, but I could use a recommendation for a lightweight build system for converted cloud book that would expose issues like that. It's a slow 64 bit Celeron with a 30GB SSD
@yaaps builds.sr.ht is pretty easy to use and supports systems with a variety of libcs and kernels, if you wanted to try that out
Oh, I'll check it out...
Also, look at the answer from lhf (one of the Lua authors) to this question about Lua portability:
@sir I may not be in a position to say this because I'm a newbie developer, but I kinda feel the same way with C. I look at lower level languages like C and I think "this looks awesome but at the same time complicated", while I look at C# and just think it has many great features to solve the complexity of lower level programming.
or maybe I just don't know much C and it's actually easier than it looks. :shrug:
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!