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

21–30 of 177 posts

Re: The Problem with C (2020)

#21

Post by unwind »

kstenerud wrote: post #4

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…

Do you have a concrete example of some operation where avoiding undefined behavior is impossible?

Re: The Problem with C (2020)

#22

Post by colonwqbang »

pjmlp wrote: post #11
slaymaker1907 wrote: post #8

Earlier quoted context omitted.

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.

I hope they don't, at the very least we can afford to choose a new keyword. Even if auto was infrequently used, it's no good to silently change the meaning of existing valid programs.

Re: The Problem with C (2020)

#23

Post by nnoitra »

I dislike C++ for the same reason I dislike all languages that try to be everything. You can use the language for years and there are still parts of it that you don't understand properly. C on the other hand has such a minimal and clear syntax that you can learn it pretty fast and feel confident about the language.

Re: The Problem with C (2020)

#24

Post by usrbinbash »

So what is the then again exactly?

Because my takeaway from the article is this: C++ piled loads and loads and them some loads of stuff onto a slim, easy, comprehensible language, is now a gigantic pile of complexity. that has precious little to do with its roots any more...and every attempt to solve its problems includes piling on more complexity.

So, how is that a problem of C?

C is not responsible for C++, simple as that.

Re: The Problem with C (2020)

#25

Post by mjevans »

kstenerud wrote: post #4

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…

I'm still a proponent of C as portable assembly, and any sort of optimizations / UB that gets used resulting in warning messages that can improve the source code of the program rather than the one time artifacts the compiler produces.

Re: The Problem with C (2020)

#26

Post by my123 »

kstenerud wrote: post #4

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…

> C is the glue interface that connects all the different languages together.

That's one of the issues in most UNIX systems. Windows sidestepped it with COM (and a much improved WinRT as a successor, with a .NET-y object model). On Apple systems, Obj-C is pretty much usable from other languages too, being the standard ABI to glue it all.

My takeaway: bring one of those two options properly to Linux, which is needed hard by now, to not fall to the lowest-common denominator.

(C++ isn't a solution because of a dubiously stable ABI on quite some platforms)

Re: The Problem with C (2020)

#27

Post by 0x008 »

theherk wrote: post #2

Oh boy. Can't wait to see how this comment section materializes.

Of course it will be a circle jerk about how C is generally better because it is more simple. Then a bunch of people mentioning we should abandon C++ in favor of rust.

Re: The Problem with C (2020)

#28

Post by kstenerud »

unwind wrote: post #21
kstenerud wrote: post #4

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…

Do you have a concrete example of some operation where avoiding undefined behavior is impossible?

Not offhand, no. It's been more than 5 years since I last did any serious C dev work.

But for an entertaining read, there are some fun stories floating around about Linux vs GCC with the kernel devs resisting compiler optimisations, and even holding back the "supported compiler versions" over it :)

Re: The Problem with C (2020)

#29

Post by google234123 »

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?

Re: The Problem with C (2020)

#30

Post by tsimionescu »

unwind wrote: post #21
kstenerud wrote: post #4

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…

Do you have a concrete example of some operation where avoiding undefined behavior is impossible?

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.

Post reply on HN