Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with C (2020)

cor3ntin.github.io

Post reply on HN
Print view View original

61–70 of 177 posts

Re: The Problem with C (2020)

#61

Post by bb88 »

unwind wrote: 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.

Re: The Problem with C (2020)

#62

Post by loup-vaillant »

kstenerud wrote: post #18
galangalalgol wrote: post #17

Earlier quoted context omitted.

Indeed, and rust, zig, fortran, and julia don't have the problems with c that c++ does, so is it a problem with c or with c++ that the author is actually talking about?

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 it crippled C++ from the start.

If C++ had stopped at binary compatibility (either with an FFI like Rust or Zig, or by deciding on a subset that can talk to C interfaces), it would have forced users to use two compilers, as well as learn an entire new language. Few people would have been willing to put in the work, Stroustrup knew this, and he wanted his language to be useful now.

And now we have this mess.

Re: The Problem with C (2020)

#63

Post by perryizgr8 »

scoutt wrote: post #47

> > There Are No C Conferences. Maybe that’s why the C++ committee is now over 10 times the size of the C committee. I have this controversial thought: C people understood one thing before everyone else (including the creators of C++, Rust, and any other language), and is this: “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away” -- Antoine de Saint-Exupery. Supe…

C++ is great if you forbid the class keyword in your project. It turns into an amazing new-age language with cutting-edge concepts.

Re: The Problem with C (2020)

#64

Post by ginko »

perryizgr8 wrote: post #63
scoutt wrote: post #47

> > There Are No C Conferences. Maybe that’s why the C++ committee is now over 10 times the size of the C committee. I have this controversial thought: C people understood one thing before everyone else (including the creators of C++, Rust, and any other language), and is this: “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away” -- Antoine de Saint-Exupery. Supe…

C++ is great if you forbid the class keyword in your project. It turns into an amazing new-age language with cutting-edge concepts.

So just define your classes with struct. ¯\_(ツ)_/¯

Re: The Problem with C (2020)

#65

Post by loup-vaillant »

google234123 wrote: post #29
slaymaker1907 wrote: post #7

I write a lot of code in a C++ codebase and I'd say C++ is horrific. Not just because of its roots in C, no I think it is actually a worse language than C. Notable detriments in the language include references, classes, a lot of template stuff (some of it is ok, but it makes separate compilation almost impossible).

Your examples for why C++ is bad are references, classes, and templates? So I guess you like Fortran77?

References are kind of redundant when you already have pointers, and they make the performance characteristic of the code you read less clear (am I passing down a pointer, or am I copying the whole thing?).

C structs can already do most of what C++ classes can do. Including inheritance and virtual methods, when you really really need them. As for encapsulation, pointer to implementation provide a more stable, harder to cheat interface than private members. A must for stable ABIs.

C does lack generics, and I do often miss them, but templates really aren't a good solution. I don't know what a good solution looks like, I haven't looked at Zig or Rust yet.

Another thing I miss in C is a namespace system, especially when you ship libraries: makes every name longer, and you still have annoying name clashes from time to time.

Re: The Problem with C (2020)

#66

Post by scoutt »

pjmlp wrote: post #60
scoutt wrote: post #55

Earlier quoted context omitted.

May be, but... https://en.wikipedia.org/wiki/C17_(C_standard_revision) "C17 addressed defects in C11 without introducing new language features" means a lot. https://en.wikipedia.org/wiki/C2x Has a few additions compared to C++20 ( https://en.wikipedia.org/wiki/C%2B%2B20 )

Have fun reading these ones instead of relying on Wikipedia, https://news.ycombinator.com/item?id=30160590 Also you forgot the endless amount of compiler specific language extensions.

Let's see what (and how it) lands in C2x. Of course, as any other language, C might be taken over in the future by a new generation and be bloated, too. But so far, it is contained.

In any case, nobody can deny the amount of bloat in C++ has no parallel.

> Naturally at this point one could ask why not just use C++ instead

I might do, in a limited and simpler form, as I said before. Of course I am not developing something like SKIA; just firmware in a limited and constrained environment (not even using std).

Re: The Problem with C (2020)

#67

Post by tialaramex »

pjmlp wrote: post #58
0x008 wrote: post #36

Earlier quoted context omitted.

I agree, the tools should make it very clear what implications using a certain feature has (e.g. unsafe in rust).

C did it already in 1979, yet people keep ignoring it. > Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find inter…

We've been here before with other aspects of human behaviour.

If you really don't want people to do it, make it impossible and then they can't. You can't write an integer overflow in WUFFS because that doesn't compile. You can't use your Google.com WebAuthn credentials to sign into fakegoogle.example, even if you really, really want to, even if you're 100% sure this is a good idea, it can't be done. Any time you stop short of this, you mustn't really want people to stop doing it and so they won't.

The next strongest defence, still not used often enough, is to make it very annoying to do things that are a bad idea. Default deny for example, the compiler obliges you to go in and explicitly allow the obviously bad thing you've done each and every single time you do it. A DLR train can be driven in fully manual mode instead of being automated, but it goes annoyingly slowly if you do that.

Linting is far below the visibility of even compiler warnings, most of your target audience will never see the message. It's not even "Do not look into laser with remaining eye" but more like a "Caution: Eye hazard" warning written inside the never-opened instruction manual.

Re: The Problem with C (2020)

#68

Post by sirwhinesalot »

throwawaylinux wrote: post #59
sirwhinesalot wrote: post #31

Earlier quoted context omitted.

> C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. Indeed, this is one of the two things where C is still king, the other being running on weird hardware with specialized compilers. That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language need…

> That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language needs to do a copy to pass a string to C, even C++ (for string_view at least). I don't think that's what he's talking about. No matter what glue you had, you need to pass NUL terminated strings to C code that uses NUL terminated strings. The glue interface does not require any such thing though. > A lack…

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.

By necessity this involves using standard types available in C otherwise the other languages have nothing to go on, they'd just have a bunch of opaque types and no way to create them.

If C had better builtin constructs, these "extern C" APIs could be much better semantically, such that automatically generating wrappers to this C API would result in safer, more efficient, and more ergonomic code in the host language.

Re: The Problem with C (2020)

#69

Post by tsimionescu »

kstenerud wrote: post #46
tsimionescu wrote: post #30

Earlier quoted context omitted.

It's not a particular operation that is the problem, it's writing a whole real-life program with no UB that is the problem. Even so, one example in C++ where it's almost impossible to avoid UB is treating a piece of memory as both a struct and raw bytes with guarantees of no copying. This comes up a lot in network packet processing.

This makes me wonder how protobufs manages to implement zero-copy structs.

Well, in practice memcpy and std::bit_cast will not normally copy, if you're careful with how you use the variables and so on, so it's not completely impossible to do this.

There are also compilers (g++ for example, if I understand correctly) that define type punning through unions to work like in C (allowing you to read and write through different members of the union, which the C++ standard prohibits).

Re: The Problem with C (2020)

#70

Post by sirwhinesalot »

_the_inflator wrote: post #40
sirwhinesalot wrote: post #31

Earlier quoted context omitted.

> C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. Indeed, this is one of the two things where C is still king, the other being running on weird hardware with specialized compilers. That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language need…

I agree with you. However, I think the real value of the language is that, despite flaws, it provides a reasonably consistent platform in this "glue" context. It better to have one imperfect language, than a dozen perfect.

I know "upvote" comments are frowned upon, but I just wanted to say I most certainly agree. I'm glad we ended up with such a language, even with all its flaws.
Post reply on HN