Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C isn't a programming language anymore (2022)

faultlore.com

Post reply on HN
Print view View original

111–120 of 217 posts

Re: C isn't a programming language anymore (2022)

#111

Post by pjmlp »

kreco wrote: post #95
pjmlp wrote: post #78

Earlier quoted context omitted.

Outside UNIX clones, and embedded space where it is mostly a religious point of view than available compiler toolchains, C has already been displaced. Even the most relevant C compilers are no longer written in C.

> Even the most relevant C compilers are no longer written in C. Worth to point out that most of the C compilers are also C++ compilers. So the point is kind of distorted.

On the contrary, GNU Compiler Collection is written in C++ and happens to have C as one of the supported fronteds, having moved away from C in 2008.

LLVM is written in C++, also supports multiple language frontends, one of them happens to be C.

Visual C++, also written in C++, happens to still compile some form of C, and after adding some C11 and C17 support (a few items are still missing in 2026), Microsoft is in no rush to add anything else.

The language that matters is the implementation, otherwise we can also talk about the relevance of PL/I compilers from IBM and Unisys, written in C++.

Re: C isn't a programming language anymore (2022)

#112

Post by Nevermark »

pjmlp wrote: post #85
Nevermark wrote: post #75

Earlier quoted context omitted.

> the concepts of pointers, variable sizes and memory layout of structs all represent the machine at some level. Exactly. Everything in assembly is still one-to-one in terms of functional/stateful behavior to actual execution. Runtime hardware optimization (pinhole instruction decomposition and reordering, speculative branching, automated caching, etc.) give a performance boost but do not change the model. Doing so w…

Lets play a game of what ISO C can do, and no other systems programming language has similar feature available? If language extensions to ISO C are allowed, then same goes for my selection on competing systems languages.

Yes, most languages allow C type code, if that’s what you are trying to do.

Java with only primitive values, arrays, and classes only with fields and static methods.

But that wouldn’t be idiomatic Java, so typically non-explicit abstractions such as polymorphism have code generated for them that you don’t have explicit control over.

C is consistently low level because that’s all you get. Down to direct access to addressing and RAM, the stack frame, etc. as with assembly.

Re: C isn't a programming language anymore (2022)

#113

Post by donkeybeer »

danhau wrote: post #110
donkeybeer wrote: post #104

Earlier quoted context omitted.

Which systems in the 70s or even 90s would have had good hardware support for all these lengths? I think overall perhaps its better that the thing named int works on both the arduino and my amd64 otherwise we might needlessly need to rename all types for each platform to fit the most natural type lengths there. Imagine the 32 bit to 64 bit transition under those conditions.

All of them, through software implementation, as assembly programmers have done since forever. You simply choose the integer type that your problem or task requires. If the hardware genuinely can‘t cope with it (performance), you reevaluate your requirements, define new constraints and choose new types. This is basic requirements engineering, which C only made more convoluted.

I think overall it's better to provide "natural" default types but also have had something like stdint.h. But then again mandatong even a stdint.h that early would have made writing implementations quite difficult. I think it was and is an alright tradeoff.

Re: C isn't a programming language anymore (2022)

#114

Post by donkeybeer »

danhau wrote: post #108
1718627440 wrote: post #103

Earlier quoted context omitted.

> - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. I strongly disagree. The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have. Does this variable represent the size of an object, an address, a difference or just a random positive integer? Then use size_t, uintptr_t, ptrdiff_t and unsigned int respectively.…

How will you know if your integer type is adequate for the problem at hand, if you don‘t know its size? Choosing the right type is a function of signedness, upper/lower bound (number of things), and sometimes alignment. These are fundamental properties of the problem domain. Guesstimating is simply not doing the required work.

The idea is mostly that we shouldn't worry. The user of the lib on an arduino will feed it arduino sized problems and the amd64 user will likewise larger problems. Again I think just think of the transition from 32 to 64 bit. Most ranges are "input"/"user " dependent and it would have been needlessly messy to have to even with automatic conversion help rewrite say every i32 to i64 or which ones to convert.

Re: C isn't a programming language anymore (2022)

#115

Post by phicoh »

pjmlp wrote: post #109
phicoh wrote: post #102

Earlier quoted context omitted.

The thing for me at least is that when I looked at Pascal, MODULA-2, Ada, if you had complex data structures which had to allocate and deallocate memory, then those language would not help at all. They would allow you to make pointer mistakes. Pascal and MODULA-2 were also very restrictive in various area (no generics). Ada is better in that respect, but Ada compilers were rare. In my opinion it is only Rust that off…

First of all C did not had any generics, so same playing field. C has a runtime, even if tiny. That is what calls into main(), handles floating point arithmetic when none is available, functions that run before and after main(), nowadays also does threading. Heap memory handling in Pascal, Modula-2, Ada, is much safer than C, first of all no need to do math to calculate the right size, arenas are available on the sta…

C uses pointer casts all over the place to fake generics. If you don't have that (in Pascal or MODULA-2) then life becomes very unpleasant.

There is a quite a bit of C code that makes creative use of the size of allocations. For example linked lists with a variable sized payload. Again one of the things that would prevent a C programmer from switching to Pascal.

I don't expect the Zig user base to become larger than the Rust user base any time soon. But we have to wait and see, Zig is quite young.

Re: C isn't a programming language anymore (2022)

#116

Post by tmtvl »

pjmlp wrote: post #84
uecker wrote: post #68

Earlier quoted context omitted.

This is a meme which is repeated often, but not really true. If you disagree, please state specifically what property of PDP-11 you think it different from how modern computers work, and where this affects C but not other languages.

It lacked SIMD instructions.

Don't forget about branch prediction (GCC may have __builtin_expect, but that's not standard C).

Re: C isn't a programming language anymore (2022)

#117

Post by direwolf20 »

pjmlp wrote: post #82
chasil wrote: post #40

Earlier quoted context omitted.

In pieces of my code, I need to call setuserid() to manage some of the security that I designed in 2010. There was no Rust at that point, and I used the most basic tool that could do it. Could I have done this in Java with gymnastics of JNI, linking C into the JRE? Definite maybe.

Yes, nowadays with Panama, and before Rust was around, JNA was already there so using JNI wasn't strictly necessary.

JNA is a whole dependency of its own, shame it's not built into the JRE

Re: C isn't a programming language anymore (2022)

#118

Post by ghosty141 »

1718627440 wrote: post #100
ghosty141 wrote: post #94

Earlier quoted context omitted.

Its not a meme. For example, C has pointer provenance, so pointers arent just addresses. Thats why type punning is such a mess. If a lang claims to be super close to the hardware this seems like a very weird thing.

C is super close to the hardware in that it works exactly like the abstract C machine, which is kind of a generalization of the common subset of a lot of machines, invented to make it portable, i.e. viable to be implemented straightforwardly on various architectures. For example pointer provenance makes it work on machines with segmented storage, these can occur anywhere, so there is no guarantee that addresses beyon…

The C abstract machine is exactly the important part. There is a difference between saying C is close to "the hardware" and C is close to the C abstract machine. The latter like you described has a few concepts that allow for abstraction and thus portability but obviously they lead to situations where the "maps to the hardware" doesn't seem to hold true.

My gripe is only with people acting like the C abstract machine doesn't exist and C is just syntax sugar for a bit of assembly. It's a bit more involved than that.

Re: C isn't a programming language anymore (2022)

#119

Post by direwolf20 »

tmtvl wrote: post #116
pjmlp wrote: post #84

Earlier quoted context omitted.

It lacked SIMD instructions.

Don't forget about branch prediction (GCC may have __builtin_expect, but that's not standard C).

The compiler usually can't do anything about branch prediction. Expect is more about keeping cold paths out of the cache.

Re: C isn't a programming language anymore (2022)

#120

Post by direwolf20 »

donkeybeer wrote: post #101
thayne wrote: post #67

Earlier quoted context omitted.

The things complained about in the article are not a minimal reflection of how computers work. Take the "wobbly types" for example. It would have been more "minimal" to have types tied directly to their sizes instead of having short, int, long, etc. There isn't any reason that compilers on the same platform have to disagree on the layout of the same basic type, but they do. The complaints about parsing header files c…

There were many different types of computers back then. Some even had 36 bit word sizes. I don't think there was any clear winner like amd64 back then that they could have prioritized. 16 and 32 bit machines existed in decent amounts and so on.

For that, we have uint_fast32_t and so on.
Post reply on HN