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

91–100 of 177 posts

Re: The Problem with C (2020)

#91

Post by galangalalgol »

loup-vaillant wrote: post #88
pjmlp wrote: post #82

Earlier quoted context omitted.

The best way to put it for modern generations is that C++ was "TypeScript" for C, with all the plus and minus that it entails.

If only. For all the "moar strong types" goodness C++ claimed, in practice there was very little. The same could have been achieved with stricter warnings, that C compilers now have . With TypeScript at least you have the option to go from full dynamic typing auto cast madness to meaningful compile time checks. That being said, if I had to write a serious web app today (that is, something that absolutely requires cli…

Will wasm ever get direct access to the dom so that isn't needed? I keep wanting to jump into wasm, but I don't really want to learn any more javascript than I already know, which is just enough to play codespells and screeps. And I certainly don't want to learn a framework which seems to follow the madden nfl release schedule.

Re: The Problem with C (2020)

#92

Post by flohofwoe »

my123 wrote: post #26
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 h…

> Windows sidestepped it with COM

Erm, isn't the whole point of COM that it is also just a "C glue interface"? Not how one would typically design C APIs, but COM APIs are C APIs nonetheless.

Re: The Problem with C (2020)

#93

Post by pjmlp »

loup-vaillant wrote: post #88
pjmlp wrote: post #82

Earlier quoted context omitted.

The best way to put it for modern generations is that C++ was "TypeScript" for C, with all the plus and minus that it entails.

If only. For all the "moar strong types" goodness C++ claimed, in practice there was very little. The same could have been achieved with stricter warnings, that C compilers now have . With TypeScript at least you have the option to go from full dynamic typing auto cast madness to meaningful compile time checks. That being said, if I had to write a serious web app today (that is, something that absolutely requires cli…

The compilers might have them, yet the large majority doesn't care they exist.

Unless devops plugs them into the CI/CD pipeline with -Wall -Werror, most people will keep coding as they ever did.

Why do you think Google is sponsoring KSPP and pushing C cleanups of bad code, despite all review processes that the kernel has?

Re: The Problem with C (2020)

#94

Post by flohofwoe »

sirwhinesalot wrote: post #68
throwawaylinux wrote: post #59

Earlier quoted context omitted.

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

Your comment is assuming that language A knows about language B. That's one case, but not the usual one. Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. By necessity this involves using standard types available in C otherwise the othe…

> If C had better builtin constructs...

Such annotations exist in specific compilers (e.g. clang has things like _Nullable and _Nonnull), they are just not part of the standard (unfortunately). But those annotations are visible in Clang's ast-dump, so they can be used to create more correct language bindings.

Re: The Problem with C (2020)

#95

Post by throwaway984393 »

Most programming languages are really good. People who talk ill of them just don't know them well, and also probably never lived while there were no high-level languages. And honestly, people are creatures of trends; we don't use the most popular languages because they're flawless.

The only major problem with C is its community never took off with a popular library packager and linter. Every other language that seems so cool today would be just as painful as C if they didn't have so many contributed modules and tweaks. Port those to C and people would fall in love with it all over again.

Re: The Problem with C (2020)

#96

Post by flohofwoe »

kstenerud wrote: post #18
galangalalgol wrote: post #17

Earlier quoted context omitted.

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.

> that wants closer relations between C and C++

That wasn't possible anymore from the moment on when C++ decided to not treat C as a proper subset (like Objective-C did), but instead fork its C subset into a slightly different language.

Re: The Problem with C (2020)

#97

Post by flohofwoe »

pjmlp wrote: post #82
loup-vaillant wrote: post #62

Earlier quoted context omitted.

If C++ had just treated C from the start, it would have been much cleaner, and nobody would have used it. Humans are stupid, short-sighted creatures, and programmers are no exception. The only way to get C programmers to use C++ was to make C-with-classes a drop-in replacement for C. Replace "cc" by "CC" in your build system, and you magically get new features, without breaking old code (at least not too much). Sure…

The best way to put it for modern generations is that C++ was "TypeScript" for C, with all the plus and minus that it entails.

The comparison is flawed, because Javascript is a subset of Typescript, but C is not a subset of C++. A better analogy would be that C++ is to C what Dart is to Javascript.

Re: The Problem with C (2020)

#98

Post by bollu »

_0w8t wrote: post #39
mjevans wrote: post #25

Earlier quoted context omitted.

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.

What's a non flat address space, and what would I use it for?

Re: The Problem with C (2020)

#99

Post by seiferteric »

smorgusofborg wrote: post #76
sirwhinesalot wrote: post #68

Earlier quoted context omitted.

Your comment is assuming that language A knows about language B. That's one case, but not the usual one. Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. By necessity this involves using standard types available in C otherwise the othe…

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one. You are free to expose an API where strings are not null terminated, etc. Anyone in any language is going to have to work their data into the API you provide so if it is alternatively complicated to make an intermediary language happy that's not really helping.

This brings up a vague idea I have had. Redis is sort of a data structure server that can be used across languages. Could we not have an opensource data structure and algorithm library? Where languages, instead of implementing their core types and algorithms in their own library, instead add them (or reuse existing) ones to this library. Then your language becomes just a mapping of your languages semantics over these existing structures & functions.

Re: The Problem with C (2020)

#100

Post by marwis »

flohofwoe wrote: post #92
my123 wrote: post #26

Earlier quoted context omitted.

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

> Windows sidestepped it with COM Erm, isn't the whole point of COM that it is also just a "C glue interface"? Not how one would typically design C APIs, but COM APIs are C APIs nonetheless.

But it's higher level. It lets you expose interfaces and defines memory management and threading vs using raw C functions where you have to manually encode all of that for every other language.
Post reply on HN