The Problem with C (2020)
51–60 of 177 posts
Re: The Problem with C (2020)
#52Earlier 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++.
It’s tricky to balance features, backward compatibility and ‘cleanliness’ in a (language, standard library)
Re: The Problem with C (2020)
#53C 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…
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)
#54Re: The Problem with C (2020)
#55> > 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.
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)
#56C 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?
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)
#57Earlier 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.
Any competent butcher will never cut themselves.
Re: The Problem with C (2020)
#58Earlier 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).
> 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.
Re: The Problem with C (2020)
#59C 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 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)
#60Earlier 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 )
https://news.ycombinator.com/item?id=30160590
Also you forgot the endless amount of compiler specific language extensions.