Live data from Hacker News

The Problem with C (2020)

cor3ntin.github.io

11–20 of 177 posts

Re: The Problem with C (2020)

#11
post #6

> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?

I found a post claiming it was used in B and C to specify a data type stored on the stack. https://stackoverflow.com/a/8272497/7608007

C23 is considering following C++ footsteps and repurpose auto as well.

Re: The Problem with C (2020)

#12
post #6

> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?

I found a post claiming it was used in B and C to specify a data type stored on the stack. https://stackoverflow.com/a/8272497/7608007

Not "was", "is"! auto is the opposite of static in a way. Since it's the default method of storage for local variables, it's very rare to specify it explicitly. C++ just took this C keyword and made it mean something completely different.

Re: The Problem with C (2020)

#13

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. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…

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

Re: The Problem with C (2020)

#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's not "a thing" for me.

Anyway, some things I think would make for interesting content at such a conference, should one decide to exist:

Modern C. It would be useful with practical down-to-earth comparison between C the way (I feel) many think it "should" be written, i.e. C89-style with lots of worry that the compiler may be broken, and something more modern/sensible.

Standard directions. Some kind of survey-style talk trying to both summarize known interests covered by the committe now, and also perhaps polling the audience for input about where C needs to go.

Compiler architect's thoughts. Get the major compiler writers in a panel, have them talk about how various language (mis)features affect their ability to write good compilers, and what changes would help with that, if any.

Code sight-seeing. Just having a few knowledgable folks navigate some well-known codebases on a projector with commentary/analysis would be very interesting I think, both to see how others have solved things, and perhaps spot problems/possible improvements. Must be done respectfully of course.

Now I almost feel as if I miss that conference. :/ More ideas, anyone?

(Edited for typos and grammar)

Re: The Problem with C (2020)

#15

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. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…

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

There's absolutely no guarantee that these problems will be avoided in rust and zig; we only have the benefit of hindsight to avoid the problems we have now, and a recorded history of the kinds of things that tend to go wrong in committees (factions, infighting, BigCo interference, intrigue, egos, bike shedding, etc).

Re: The Problem with C (2020)

#16
C++ is a semantically overloaded language. It is very far from "C with classes" at this point. In C, every construct has a direct mental mapping to its rough representation as machine code, and its corresponding side effects. C++ adds a "meta stage" after which the machine code might be the same, but it takes a lot of time for the programmer to figure out what is really happening.

Re: The Problem with C (2020)

#17

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. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…

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?

Re: The Problem with C (2020)

#18

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. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…

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.

Re: The Problem with C (2020)

#19
In classic "get off my lawn" style I thought C++ divergence from C when they abandoned cfront was where it all went wrong.

At least with cfront you had some idea of what was getting generated.

My favourite C++ compiler was Symantec 7 on windows. It was a great, affordable tool for making MFC applications and had a neat GUI builder too. I still have the CD of it but it refuses to install on windows 11 sadly.

Nowadays I just use C or C#, C++ just seems like a hard to use version of C# and I have little use for the extra performance it might have.

Re: The Problem with C (2020)

#20

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. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…

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

The Zig creator is very conscious of this, talks a lot about rejecting many proposals and ideas to keep the language simple, not being an ass-hole about it, just to avoid what happened to C++.
Post reply on HN