this post was submitted on 25 Mar 2024
13 points (68.6% liked)
C Programming Language
931 readers
22 users here now
Welcome to the C community!
C is quirky, flawed, and an enormous success.
... When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd.
... The only way to learn a new programming language is by writing programs in it.
- irc: #c
🌐 https://en.cppreference.com/w/c
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I can't speak for C, as I don't follow it that much, but for C++, this is just not fair. It has been proven repeatedly that it can be done better, and much better. Each iteration has made so many things simpler, more productive, and also safer. Now, there are two problems with what I just said:
If that last part is what you mean, fine. But the way that you phrased (and that I quoted) is just not right.
Surely not for everything. Of course I see great value if I can stop depending on OpenSSL, and move to a better library written in a better language. Seriously looking forward for the day when I see dynamic libraries written in Rust in my package manager. But I'd like to see what's the plan for moving a large stack of C and C++ code, like a Linux distribution, to some "better language". I work everyday on such a stack (e.g. KDE Neon in my case, but applicable to any other typical distro with KDE or GNOME), and deploy to customers on such a stack (on Linux embedded like Yocto). Will the D-Bus daemon be written in Rust? Perhaps. Systemd? Maybe. NetworkManager, Udisks, etc.? Who knows. All the plethora of C and C++ applications that we use everyday? Doubtful.
That comment was not talking about programming languages, it was talking about human's inability to write perfect code. Humans are unable to solve problems correctly 100% of the time. So if the language doesn't do it for them then it will not happen. See Java for a great example of this. Java has Null Pointer Exceptions absolutely everywhere. So a bunch of different groups created annotations that would give you warnings, and even fail to compile if something was mismatched or a null check was missed. But if you miss a single
@NotNull
annotation anywhere in the code, then suddenly you can get null errors again. It's not enforced by the type system and as a result humans can forget. Kotlin came along and 'solved it' at the type level, where types are nullable or non-nullable. But, hilariously enough, you can still get NPEs in Kotlin because it's commonly used to interop with Java.My point is that C/C++ can't solve this at a fundamental level, the same way Kotlin and Java cannot solve this. Programmers are the problem, so you have to have a system that was built from the ground up to solve the problem. That's what we are getting in modern day languages. You can't just tack the system on after the fact, unless it completely removes any need for the programmer to do literally anything, because the programmer is the problem.
I'm not talking about whole scale rewrites. I'm talking about what Linux is already doing with writing new code in Rust, or small portions of performance critical code in a memory safe language. I'm not talking about like what Fish Shell did and rewrote the whole codebase in one go, because that's not realistic. But slowly converting an entire codebase over? That's incredibly realistic. I've done so with several 250k+ line Java codebases, converting them to Kotlin. When languages are built to be easy to move to (Rust, Kotlin, etc), then migrating to them slowly over time where it matters is easily attainable.