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

31–40 of 177 posts

Re: The Problem with C (2020)

#31

Post by sirwhinesalot »

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. 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 needs to do a copy to pass a string to C, even C++ (for string_view at least).

- A lack of fat pointers means that buffers need to pass their pointer and length separately, which is awkward, or use a custom struct which other languages will know nothing about.

- It has no standardized error handling mechanism to help with writing automatic wrappers on the other language endpoints.

- It has no modules or namespacing.

So while C will continue to be the glue language of the programming world, I wish it was just a bit better than what it is, would make language interoperability a lot nicer...

Re: The Problem with C (2020)

#32

Post by srvmshr »

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.

Re: The Problem with C (2020)

#33

Post by foldr »

colonwqbang wrote: post #22
pjmlp wrote: post #11

Earlier quoted context omitted.

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.

Would it change the meaning of existing valid programs? C's "type inference" algorithm is to assume that everything is an int by default. So

    auto x = 7;
is equivalent to

    auto int x = 7;
which is equivalent to

    int x = 7;
(since "auto" is the default storage class). If the C standard folks do things right, then the only change will be to allow some previously invalid code like the following:

    auto str = "foo";
Such code will compile on a C compiler (hopefully with a warning!) but won't have a defined behavior. I guess a more problematic case would be

    auto x = 9999999999999L;
Where the value will be truncated in C but will be inferred as a long in C++ (assuming typical sizes for int and long int). Again, though, I am not sure if truncation of signed constants has a defined behavior in the standard.

Re: The Problem with C (2020)

#34

Post by username91 »

usrbinbash wrote: post #24

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…

The title doesn't seem to correspond to the article at all; basically it's clickbait.

Re: The Problem with C (2020)

#35

Post by 0xFFFE »

0x008 wrote: post #27
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.

C is generally better because it doesn't treat you with kid gloves, if you don't know what you are doing you will get fucked in the ass. That said, any competent engineer would know what tool to use to solve a given problem. You don't use a sledge hammer to fix a watch.

Re: The Problem with C (2020)

#36

Post by 0x008 »

0xFFFE wrote: post #35
0x008 wrote: post #27

Earlier quoted context omitted.

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.

C is generally better because it doesn't treat you with kid gloves, if you don't know what you are doing you will get fucked in the ass. That said, any competent engineer would know what tool to use to solve a given problem. You don't use a sledge hammer to fix a watch.

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

Re: The Problem with C (2020)

#39

Post by _0w8t »

mjevans wrote: post #25
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.

C cannot express quite a few useful things that assembly can. Things like tail calls, stack management, non-flat address space just cannot be expressed.

Re: The Problem with C (2020)

#40

Post by _the_inflator »

sirwhinesalot wrote: post #31
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. 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.
Post reply on HN