Live data from Hacker News

The Problem with C (2020)

cor3ntin.github.io

81–90 of 177 posts

Re: The Problem with C (2020)

#81
As far as I can tell, the definition of C++ is mostly driven by compiler folks (and wannabes), motivated to add features for their own career benefit and generally doing so in the way that's most convenient for them (e.g. std::move as a pseudo-function instead of as real syntax that the already-insane parser would have to handle). Since only the in-group's interests are considered, the much more numerous regular C++ users are ill served.

For all its faults, there's much less churn in the definition of C and what change does occur seems to be driven by clearly demonstrated needs out in the real world. C might seem stagnant, outdated, incomplete, or unsafe - all fair criticisms - but at least a competent C programmer's hard-won knowledge of how to overcome these deficiencies doesn't get turned on its head every few years as a new language version comes out. Even decades-old C (at least since the K&R vs. ANSI function-declaration change) is still readable and scarcely less idiomatic than something written last week.

So, referring to the OP's title, which language has the bigger problem?

Re: The Problem with C (2020)

#82

Earlier quoted context omitted.

The biggest problem is that there is still a significant faction within the C++ committee that wants closer relations between C and C++, or even a merging (if such a thing were possible). "C++ is a better C" is a mantra that can still be heard to this day within those hallowed halls. If C++ would just treat C as an interface like everyone else does, this problem would shrink considerably.

If C++ had just treated C from the start, it would have been much cleaner, and nobody would have used it. Humans are stupid, short-sighted creatures, and programmers are no exception. The only way to get C programmers to use C++ was to make C-with-classes a drop-in replacement for C. Replace "cc" by "CC" in your build system, and you magically get new features, without breaking old code (at least not too much). Sure…

The best way to put it for modern generations is that C++ was "TypeScript" for C, with all the plus and minus that it entails.

Re: The Problem with C (2020)

#83
post #43

Earlier quoted context omitted.

What makes you think Rust and Zig will not suffer the same issue given enough time?

Computer science is less than a century old. There's no reason to think we know enough to design perfect languages yet. But with an additional 30 years of hindsight, we can make somewhat better languages now, and we should.

We already had 20 years of hinsight that C's authors decided to ignore, had UNIX not been free beer for all practical purposes, history would have taken another path regarding C's adoption.

Re: The Problem with C (2020)

#84
post #61
post #14

As a long-time C aficionado, part-time wanna-be language-lawyer, and just general supporter and fan, the fact that there is no C conference was interesting. I guess I knew that, because if there was such a conference I would have known, at least I would like to think that. On the other hand I've never been to a programming language conference (probably self-fulfilling by being primarily a C programmer at heart) so it…

> As a long-time C aficionado, part-time wanna-be language-lawyer, and just general supporter and fan, the fact that there is no C conference was interesting. There doesn't need to be a conference for everything under the sun. I don't see a screwdriver conference popping up around me anytime soon.

You might find the latest screwdriver tech at one of these ones, https://www.conexpoconagg.com/

Re: The Problem with C (2020)

#85
post #32

C++ is an overloaded language whose complexity seems to be growing with each revision. Heck, I remember Bjarne Stroustrup even semi-lamenting it in one of the interviews. I don't understand why this is a C problem, whose syntax and definitions have been relatively stable for the last 3 decades. Author has gripes with C++ 'universality' IMHO but just piling it on C.

> I don't understand why this is a C problem Because it isn't a C problem. C has been basically stable for decades. C++ is free to overload itself by piling ever more stuff onto itself, but any problems this language has, are not problems of C, or problems C needs to fix.

ISO C11, ISO C17, ISO C23,

GCC C, clang C, xlc, aC, TICC, MSVC C, ...

Re: The Problem with C (2020)

#86

Earlier quoted context omitted.

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one. > Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. The C interface glue is not the problem here. You can write the library with…

I'm sorry, maybe I'm not making myself clear and we're talking in circles. Yes the C interface is the problem. Lets say I'm developing an API in Rust that I want everyone to be able to use. I wrap this API in some C functions. I use fat pointers (slices), strings with length, etc. all custom struct types. I choose to signal errors in some my_err* parameter. Then someone developing in Java wants to use my library. If…

Since you seem to have vastly the scope of your complaint down to "it doesn't generate all wrapper code automatically for all features", I'll take that as you conceding that the interface does not prevent these features from being implemented across it. Great.

And if that's the biggest remaining problem with it, it would be possible to address by augment the interface glue with some extra metadata in a C comment or something nice and simple to describes higher level constructs without the base being tied to or require some specific implementation of them. Just write up a spec and we're done.

Re: The Problem with C (2020)

#87

Earlier quoted context omitted.

I'm sorry, maybe I'm not making myself clear and we're talking in circles. Yes the C interface is the problem. Lets say I'm developing an API in Rust that I want everyone to be able to use. I wrap this API in some C functions. I use fat pointers (slices), strings with length, etc. all custom struct types. I choose to signal errors in some my_err* parameter. Then someone developing in Java wants to use my library. If…

Since you seem to have vastly the scope of your complaint down to "it doesn't generate all wrapper code automatically for all features", I'll take that as you conceding that the interface does not prevent these features from being implemented across it. Great. And if that's the biggest remaining problem with it, it would be possible to address by augment the interface glue with some extra metadata in a C comment or s…

I agree with you, you can certainly do it, but whatever you do is not the standard that every language talks, because that standard is C :).

I can add all the metadata comments I want to my C header saying that the int I return from foo() is an error code, but I'm not going to get Java, C#, Haskell, COBOL, and so on to agree on that new metadata, specially not when each of them would probably come up their own solution.

That C became a standard glue that everyone agrees on was a miracle. I can't think of many other standards that pulled that off. It's not happening again. Hence any improvement to C, and C specifically, benefits everyone. Adding extra crap outside the standard does not accomplish the same purpose.

I've actually thought of defining such a thing before, but I'd just be reimplementing SWIG, and of course the problem with SWIG is that they have to make all the infrastructure to support the different languages, it isn't the language developers themselves developing the interface (pinvoke, jni, etc.)

Re: The Problem with C (2020)

#88
post #82

Earlier quoted context omitted.

If C++ had just treated C from the start, it would have been much cleaner, and nobody would have used it. Humans are stupid, short-sighted creatures, and programmers are no exception. The only way to get C programmers to use C++ was to make C-with-classes a drop-in replacement for C. Replace "cc" by "CC" in your build system, and you magically get new features, without breaking old code (at least not too much). Sure…

The best way to put it for modern generations is that C++ was "TypeScript" for C, with all the plus and minus that it entails.

If only. For all the "moar strong types" goodness C++ claimed, in practice there was very little. The same could have been achieved with stricter warnings, that C compilers now have. With TypeScript at least you have the option to go from full dynamic typing auto cast madness to meaningful compile time checks.

That being said, if I had to write a serious web app today (that is, something that absolutely requires client-side scripting), I would consider using JavaScript as a compilation target only, alongside WebAssembly.

Re: The Problem with C (2020)

#89

Earlier quoted context omitted.

The biggest problem is that there is still a significant faction within the C++ committee that wants closer relations between C and C++, or even a merging (if such a thing were possible). "C++ is a better C" is a mantra that can still be heard to this day within those hallowed halls. If C++ would just treat C as an interface like everyone else does, this problem would shrink considerably.

If C++ had just treated C from the start, it would have been much cleaner, and nobody would have used it. Humans are stupid, short-sighted creatures, and programmers are no exception. The only way to get C programmers to use C++ was to make C-with-classes a drop-in replacement for C. Replace "cc" by "CC" in your build system, and you magically get new features, without breaking old code (at least not too much). Sure…

Add to that c++ is infectious, both in a code base, because once you add c++ you can't go back, and in dependency chains. A c++ library that depends on c libraries often only exports c++ interfaces so the things that would build on them must be c++. Where julia might call into a rust library with a fortran and zig dependency.

Re: The Problem with C (2020)

#90
As a (now, primarily) C developer who still uses plenty of C++ in mixed-language projects when needed: C++ should only provide as much C compatibility as is needed for consuming headers with C-API declarations, and nothing more.

Microsoft's 2012 advice [1] to compile C code with a C++ compiler was misguided (at the time this was just an excuse to not support the latest C standards in MSVC). Writing C code in the so-called "common C/C++ subset" is a massive PITA for a C coder, because this common subset is a nonstandard dialect of C which will forever be stuck in the mid-90s.

[1] https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

Post reply on HN