3 ms·

I think it's interesting that C still exists despite great efforts to kill it. First it was C++, then it was Java, now it's rust. Perhaps it would be easier t

I think it's interesting that C still exists despite great efforts to kill it. First it was C++, then it was Java, now it's rust. Perhaps it would be easier to fire WG14 for incompetence[1], add a few things to the language, and update the standard library. [1] These guys haven't been able to come up with a non broken version of strcpy with 40 years of trying.

jvanderbot 3y ago
I'm an old programmer. I started with Java, learned Ada because I thought it'd be the next best thing. Then learned Cpp for windows programming, then php. Then a job with Java, then embedded work with C. And coursework in C. My thesis was a data structure implemented in C and Java. Then a decade and a half of Cpp because robotics and ROS dominates that area. Distrbuted robotics in Cpp. Along the way Python took off, I've used R and Matlab for research for years at a time. Now Rust is here. I have never stopped "thinking in C" from my few years of embedded work near the operating system or on bare metal. It's the language that makes the most sense when you study CPUs. The concepts match OS apis. It is simple to write C glue for any of the above languages. C libraries are not mangled. Etc etc. C feels like the language that computers and software are made with, and all other languages just try to hide that by building someone on top of it. I say that as a feeling but it might just be true. Now Rust is here and I love it when it tries to be like C. It's clean, pure, I believe the compiler when it says something (not like Cpp), and the mental leap to the borrow checked matches ownership dynamics from C pretty well. I hate it when it tries to be like Python or JavaScript, pulling 1000 libraries for something flashy and simple. But that's us, the programmers. The language is strict because it's the core of C without the generality. If C is the wilderness, Rust is the national park. It's beautiful, sparse, you can get lost for days, but it's safer.
pjmlp 3y ago
> I think it's interesting that C still exists despite great efforts to kill it. You won't get rid of C until UNIX/POSIX goes away, that is why C is still around mostly. Now i fully agree with WG14's incompetence, it is impossible to understand that in 40 years, it was so hard to add proper string and array types to the language, between new native types, additional struct based standard library functions, or fat pointers, one approach would definitly have worked out, if they bothered.
jstimpfle 3y ago
> These guys haven't been able to come up with a non broken version of strcpy with 40 years of trying. strcpy() is there for historic reasons, and is staying for compatibility. Functions like strtok() and in fact most functions in <string.h> are awful -- don't use them for new code. In the same way, zero-terminated strings are there for historic reasons. They weren't a C invention. And they are staying for compatibility. There's no practical way to get rid of them. I don't think that it would be useful to add another string type to the C library. The types of programming where C is useful today, you need memcpy and snprintf, that's about it. To add another standardized string type would only lead to a situation where we now have 15 incompatible solutions, and none of them are good for everyone. Built in string types are more useful for languages with some form of automated resource management where one is used to mindlessly concatenating and splitting strings. The types of programming where that's a valid approach, don't use C in the first place. It's a bad fit. Btw. zero-terminators are not entirely bad. They are an in-band signal (and can be easily completed using an additional out-of-band signal). And that can be quite useful, for example when looking at a plain binary. The space saving part that comes with zero terminators for small text strings is another thing, but admittedly has become irrelevant.

jvanderbot 3y ago

I'm an old programmer. I started with Java, learned Ada because I thought it'd be the next best thing. Then learned Cpp for windows programming, then php. Then a job with Java, then embedded work with C. And coursework in C. My thesis was a data structure implemented in C and Java. Then a decade and a half of Cpp because robotics and ROS dominates that area. Distrbuted robotics in Cpp. Along the way Python took off, I've used R and Matlab for research for years at a time. Now Rust is here. I have never stopped "thinking in C" from my few years of embedded work near the operating system or on bare metal. It's the language that makes the most sense when you study CPUs. The concepts match OS apis. It is simple to write C glue for any of the above languages. C libraries are not mangled. Etc etc. C feels like the language that computers and software are made with, and all other languages just try to hide that by building someone on top of it. I say that as a feeling but it might just be true. Now Rust is here and I love it when it tries to be like C. It's clean, pure, I believe the compiler when it says something (not like Cpp), and the mental leap to the borrow checked matches ownership dynamics from C pretty well. I hate it when it tries to be like Python or JavaScript, pulling 1000 libraries for something flashy and simple. But that's us, the programmers. The language is strict because it's the core of C without the generality. If C is the wilderness, Rust is the national park. It's beautiful, sparse, you can get lost for days, but it's safer.

pjmlp 3y ago

> I think it's interesting that C still exists despite great efforts to kill it. You won't get rid of C until UNIX/POSIX goes away, that is why C is still around mostly. Now i fully agree with WG14's incompetence, it is impossible to understand that in 40 years, it was so hard to add proper string and array types to the language, between new native types, additional struct based standard library functions, or fat pointers, one approach would definitly have worked out, if they bothered.

jstimpfle 3y ago

> These guys haven't been able to come up with a non broken version of strcpy with 40 years of trying. strcpy() is there for historic reasons, and is staying for compatibility. Functions like strtok() and in fact most functions in <string.h> are awful -- don't use them for new code. In the same way, zero-terminated strings are there for historic reasons. They weren't a C invention. And they are staying for compatibility. There's no practical way to get rid of them. I don't think that it would be useful to add another string type to the C library. The types of programming where C is useful today, you need memcpy and snprintf, that's about it. To add another standardized string type would only lead to a situation where we now have 15 incompatible solutions, and none of them are good for everyone. Built in string types are more useful for languages with some form of automated resource management where one is used to mindlessly concatenating and splitting strings. The types of programming where that's a valid approach, don't use C in the first place. It's a bad fit. Btw. zero-terminators are not entirely bad. They are an in-band signal (and can be easily completed using an additional out-of-band signal). And that can be quite useful, for example when looking at a plain binary. The space saving part that comes with zero terminators for small text strings is another thing, but admittedly has become irrelevant.