Sometimes I get tired of working in higher-level languages like Python and I feel inspired to try my hand at something lower-level and closer to the machine. Go and Java are too corporate, Zig and Odin and Hare are too trendy, Rust is too industrial and C++ too Lovecraftian.
“I know”, I say, “I’ll use C - it’s been around for fifty years, it’s small and simple and got to be polished to a sheen by now.” Then I read an article like this one.
“I know”, I say, “I’ll use C - it’s been around for fifty years, it’s small and simple and got to be polished to a sheen by now.” Then I read an article like this one.
Which, you will note, is not about C. It’s about its standard library.
I know, I know. In practice a programming language isn’t just syntax and semantics, it’s also the standard library, the tools, the third party libraries, the package managers, the community, the entire freaking ecosystem. With C however, you can save yourself quite a bit of trouble if you avoid the standard library as much as you can, be extremely picky about your dependencies, then vendor and statically link pretty much everything.
Many depressing articles would suddenly be irrelevant to you if you did that. In this case, all you have to do is parse those numbers yourself. It’s work, but at least you can escape most of the madness.
I think there’s a lot to love about the idea of C, but its reality is much messier and more annoying.
Being around for fifty years doesn’t automatically mean it get polished to a sheen, because C is not one single artifact that one single group worked on for fifty years. Instead, it’s got fifty years of weird legacy cruft accumulated from divergence between various implementations, concessions to historical constraints that no longer apply and (yes!) human error.
This is kind of by design. The process by which C is developed (including the ANSI/ISO standardization processes) is very focused on backwards compatibility. That makes it an amazingly stable environment, there is tons of decades-old C code being used unchanged in production with modern compilers. However, that also means that all the really bad parts can’t ever truly be fixed. If you want something that looks like a perfectly cut and polished gem after fifty years, you need a process that is able to sand off some rough edges once in a while. I think we can have a systems programming language designed through such a process, even for decades, but it can’t also simultaneously have the kingpin role that C plays for compatibility and interoperability.
Sometimes I get tired of working in higher-level languages like Python and I feel inspired to try my hand at something lower-level and closer to the machine. Go and Java are too corporate, Zig and Odin and Hare are too trendy, Rust is too industrial and C++ too Lovecraftian.
“I know”, I say, “I’ll use C - it’s been around for fifty years, it’s small and simple and got to be polished to a sheen by now.” Then I read an article like this one.
Maybe I need to look more into Forth…
score 1 · canonical
D is still around!
score 1 · canonical
Which, you will note, is not about C. It’s about its standard library.
I know, I know. In practice a programming language isn’t just syntax and semantics, it’s also the standard library, the tools, the third party libraries, the package managers, the community, the entire freaking ecosystem. With C however, you can save yourself quite a bit of trouble if you avoid the standard library as much as you can, be extremely picky about your dependencies, then vendor and statically link pretty much everything.
Many depressing articles would suddenly be irrelevant to you if you did that. In this case, all you have to do is parse those numbers yourself. It’s work, but at least you can escape most of the madness.
score 1 · canonical
I think there’s a lot to love about the idea of C, but its reality is much messier and more annoying.
Being around for fifty years doesn’t automatically mean it get polished to a sheen, because C is not one single artifact that one single group worked on for fifty years. Instead, it’s got fifty years of weird legacy cruft accumulated from divergence between various implementations, concessions to historical constraints that no longer apply and (yes!) human error.
This is kind of by design. The process by which C is developed (including the ANSI/ISO standardization processes) is very focused on backwards compatibility. That makes it an amazingly stable environment, there is tons of decades-old C code being used unchanged in production with modern compilers. However, that also means that all the really bad parts can’t ever truly be fixed. If you want something that looks like a perfectly cut and polished gem after fifty years, you need a process that is able to sand off some rough edges once in a while. I think we can have a systems programming language designed through such a process, even for decades, but it can’t also simultaneously have the kingpin role that C plays for compatibility and interoperability.
score 1 · canonical
I have never heard these names in my life :D
score 1 · canonical
Honestly, assembly is fun…
That said, don’t avoid trendy things only because they are trendy. I sympathize though.
score 1 · canonical
“Rust is too industrial” eh… I wouldn’t characterize it like that…
score 1 · canonical
It has a bit of a corporate feel
score 1 · canonical
Writing a forth would definitely be a winner for ya, or Factor, or Uiua!
score 2 · canonical
Mirth gets my vote
score 1 · canonical