Live data from Hacker News

The Problem with C (2020)

cor3ntin.github.io

51–60 of 177 posts

Re: The Problem with C (2020)

#52

Earlier quoted context omitted.

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++.

And then the question is whether it will grow fast enough, or get overshadowed by a language that’s a bit more like a weed, growing fast in whatever direction it can, and whether it will then die because of lack of sunlight.

It’s tricky to balance features, backward compatibility and ‘cleanliness’ in a (language, standard library)

Re: The Problem with C (2020)

#53
post #26

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 h…

Yes, people mistake OS ABI with C, not understanding that is only a reality on pure C OSes.

You forgot mainframes or even Android (C ABI without JNI is of not much help), or ChromeOS (WASM yeah).

Linux has such an option, D-BUS, now adopting it at scale is another matter.

Re: The Problem with C (2020)

#54
For me, C is perfect and just works and C++ doesnt. That being said, both their std libs are a big mess. It's absolutely horrible. The problem is the macro preprocessor. It's a horrible feature that should not have existed.

Re: The Problem with C (2020)

#55
post #50
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…

I guess you haven't kept up to date with ISO C work.

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)

Re: The Problem with C (2020)

#56

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?

C++'s problem, which was its killer feature for adoption, but now has grown into a problem was having been born in UNIX world with copy-paste compatibility with C.

So in many cases, although a better solution exists, many devs will code C+ unless forced to do otherwise.

Objective-C suffers from the same problem.

Re: The Problem with C (2020)

#57
post #35
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.

Butchers are also free not to wear metal glovers, if they lose part of the hand because they don't know what they are doing, tought luck.

Any competent butcher will never cut themselves.

Re: The Problem with C (2020)

#58
post #36
post #35

Earlier quoted context omitted.

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).

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 interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

https://www.bell-labs.com/usr/dmr/www/chist.html

Re: The Problem with C (2020)

#59

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…

> 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 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.

Again passing things between two languages will always necessitate that. One language might have a different fat pointer implementation than another.

And the nice thing about glue code is that it can be easily automatically generated calling wrappers so "awkward" does not come into it - you change one language's data types into another's.

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

I don't see how this matters for the interface glue. You can define the error handling with it how you like. You put it in your language's namespaces and modules.

Re: The Problem with C (2020)

#60
post #55
post #50

Earlier quoted context omitted.

I guess you haven't kept up to date with ISO C work.

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.

Post reply on HN