C isn't a programming language anymore (2022) • Hacker News Board

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

#171

Post by jenadine » Fri, Feb 06, 2026, 11:01 PM UTC

Nevermark wrote: post #156

pjmlp wrote: post #133

Earlier quoted context omitted.

How do you do direct accessing to CPU registers in C as with Assembly? Being idiomatic or not doesn't matter, what counts are what language features are available.

I am puzzled by the claim that C and assembly are not relatively close. Note here “close” being used in the injective, not bijective, sense. (Scratch out “one-to-one” in my earlier comment.) And “closer” lowers the bar here too. C isn’t simply decorated assembly. But closer to it. And “close” being used informally. Arguments for closeness are several and strong (I think), but a bit of a hodgepodge. In terms of non-bi…

> I am puzzled by the claim that C and assembly are not relatively close.

Did anyone say that? I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C.

The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they are even closer since they got more features builtins that modern assembly can now do that was not part of the design in C. (SIMD, threading, ...)

Modern languages also have extra abstractions that makes programming easier without compromising on the cost. There are more abstractions than in C, but they also are optional. (Just like you could use goto instead of while or for loop, but you're happy this abstractions exist. We could also use functions pointer in C++ instead of virtual functions, but why would we if the language provide tools that make programming easier, for the same result)

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

#172

Post by 1718627440 » Fri, Feb 06, 2026, 11:12 PM UTC

direwolf20 wrote: post #169

Borg3 wrote: post #161

Earlier quoted context omitted.

Then use long.. Does Arduino CPU cannot do 16bit add/sub with carry? wtf?

I'm not writing the app. The app was written according to your preferred design and I'm compiling it for Arduino. You say to just use int because it always has enough bits, then you say to sometimes use long because int might not have enough bits.

There is a platform where int has less than the prescribed 16 bits? How much does it have then, just 8bit or something weird?

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

#173

Post by Borg3 » Sat, Feb 07, 2026, 12:45 AM UTC

direwolf20 wrote: post #169

Borg3 wrote: post #161

Earlier quoted context omitted.

Then use long.. Does Arduino CPU cannot do 16bit add/sub with carry? wtf?

I'm not writing the app. The app was written according to your preferred design and I'm compiling it for Arduino. You say to just use int because it always has enough bits, then you say to sometimes use long because int might not have enough bits.

I dont know the indented use. If you need delay or difference, 16bit is more than enough. If you writting generic clock w/ ms accuracy, it will be not enough. You either split it or use larger storage. Its not rocket science...

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

#174

Post by smackeyacky » Sat, Feb 07, 2026, 1:27 AM UTC

jonjacky wrote: post #163

pjmlp wrote: post #87

Earlier quoted context omitted.

> Unix wasn't the first operating system to be written in a high-level language. The Burroughs OS was written in Algol, Multics was written in PL/I, and much of VMS was written in BLISS. None of those languages became popular. Of course, they weren't available as free beer with source tapes. > Apple replaced the original Macintosh OS with a system based on a Unix. Only because they decided to buy NeXT instead of Be.…

> Of course, they weren't available as free beer with source tapes. I think this was less important then, than people sometimes think. I recall those days. In the 1980s and 90s I worked as a scientific programmer in a university department. Some of our software was commercialized and sold and supported as a product for a time in the 80s. Pardon the following long memoir, but I think some reporting on what actually ha…

My recollection of working in a similar environment was very different. The Comp Sci department wanted Unix but not for its own sake. They wanted access to the burgeoning software being produced for it aimed at academics. Tex/LaTeX was the biggest driver because it was the best way at the time to make a readable research paper that was heavy in math.

Then the students needed access to lex/yacc etc for their courses and X Windows too.

That we produced other Unix programs was just an artifact of the original drive to have Unix. The Compaq 386 or Macintosh II were niche products for that job and VMS had been turfed by the late eighties.

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

#175

Post by bigbuppo » Sat, Feb 07, 2026, 2:24 AM UTC

pjmlp wrote: post #93

Ygg2 wrote: post #36

Earlier quoted context omitted.

Except the author has moved on from Rust, and is still fighting ABI hellscape in different language - Swift.

Which has a standard ABI.

With all the ABI standards and non-standard ABIs, what we really need is a unifying standard ABI.

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

#176

Post by kazinator » Sat, Feb 07, 2026, 4:16 AM UTC

Nevermark wrote: post #156

pjmlp wrote: post #133

Earlier quoted context omitted.

How do you do direct accessing to CPU registers in C as with Assembly? Being idiomatic or not doesn't matter, what counts are what language features are available.

I am puzzled by the claim that C and assembly are not relatively close. Note here “close” being used in the injective, not bijective, sense. (Scratch out “one-to-one” in my earlier comment.) And “closer” lowers the bar here too. C isn’t simply decorated assembly. But closer to it. And “close” being used informally. Arguments for closeness are several and strong (I think), but a bit of a hodgepodge. In terms of non-bi…

There is no "C's convenient inline assembly": that is a vendor extension, if available, and its convenience could vary considerably.

The manipulation of memory by C programs is close semantically to the manipulation of memory by assembly programs. Memory accessed through pointers is similarly "external" to both assembly language and C programs.

The evaluation of C program code is not close to assembly language. C programs cannot reflect on themselves portably; features like parameter passing, returning, and allocating local storage during procedure activation, are not in the programming model.

C loses access to detailed machine state. Errors that machine language can catch, like overflows, division by zero and whatnot, are "undefined behavior". An assembly language program can easily add two integers together and then two more integers which include the carry out from the previous addition. Not so in C.

Assembly language instruction set designs (with some exceptions) tend to bend over backwards to preserve the functioning of existing binary programs, by maintaining the illusion that instructions are executed in sequence as if there were no pipelining or speculative execution, or register renaming, etc.

Meanwhile, C compiler vendors bend over backwards to prove that code you wrote 17 years ago was wrong and make it fail. C is full of unspecified evaluation orders and various kinds of undefined behavior in just the basic evaluation model of its syntactic, built-in constructs; and then some more in the use of libraries.

In assembly language, you would never have doubt about the order of evaluation of arguments for a procedure.

Even when it comes to memory, where C and asasembly language agree in many points, there are some subtle ways C can screw you. In assembly language, you would never wonder whether copying a structure from one memory location to another included the alignment padding bits. In C you also don't have to wonder, if you use memcpy. Oh, but if you use memset to clear some memory which you don't touch afterward and which goes out of scope, the compiler can optimize that away, oops!

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

#177

Post by SanjayMehta » Sat, Feb 07, 2026, 4:20 AM UTC

pjmlp wrote: post #92

SanjayMehta wrote: post #24

Earlier quoted context omitted.

VHDL vs Verilog is a good parallel from the chip world. VHDL was designed from ground up. Verilog is loosely based on C. Most designs are done in Verilog.

VHDL tends to reign in European hardware companies.

And Japan, I'm told.

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

#178

Post by Nevermark » Sat, Feb 07, 2026, 6:36 AM UTC

jenadine wrote: post #171

Nevermark wrote: post #156

Earlier quoted context omitted.

I am puzzled by the claim that C and assembly are not relatively close. Note here “close” being used in the injective, not bijective, sense. (Scratch out “one-to-one” in my earlier comment.) And “closer” lowers the bar here too. C isn’t simply decorated assembly. But closer to it. And “close” being used informally. Arguments for closeness are several and strong (I think), but a bit of a hodgepodge. In terms of non-bi…

> I am puzzled by the claim that C and assembly are not relatively close. Did anyone say that? I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C. The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they ar…

As I noted, closeness has several meanings.

> The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things.

C is not just low level friendly, but low level out of the box. That is the level that all C must be written in, even when creating higher abstractions.

Some higher level languages are also low level friendly, not low level strict. Which is a kind dual.

I would argue that what makes C lower level, is that it comes in at, or under, the low levels of other languages, and its high bar comes in much lower than the abstractions built into other languages.

Forth is a good candidate for being even lower level.

But if someone else doesn't see things that way, that is fine. It is just one lens for comparing languages.

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

#179

Post by president_zippy » Sat, Feb 07, 2026, 6:54 AM UTC

OP, I would strongly recommend you try to play devil's advocate against your own case before making it, so you have a chance to refine your thoughts and rebut at least the top 2-3 counterarguments. More than that, you would do well to understand the concept of Chesterton's Fence as it applies to engineering:

"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.""

-G.K. Chesterton

#1: What you consider a "language" is one with its own official runtime. By your logic, Javascript is not a language either because the interpreter is usually written in C++ (e.g. V8, spidermonkey).

#2: Dogfooding a compiler and a runtime is common practice because most people believe that it will help the makers of a language identify bugs in their implementation or identify undefined behavior in the very definition of their language. However, every language must bootstrap from another language: most languages bootstrapped from a compiler written in C. If you trace the lineage from compiler to compiler to ... compiler, you'll most likely find that the second C compiler ever written was written in C and the first compiler was written in some architecture's assembly language. The same still applies for the new, new language of C99 which is less than half the age of C. C is so mature that rooting out new undefined behaviors is no longer a significant concern.

#3: libc is not just a "language runtime", it's the interface into the OS kernel for most operating systems. The runtime for every "real language" as you describe it ultimately uses libc. It doesn't make sense to separate the functions in the C99 standard from the OS's own syscalls and special-purpose user land functions call C standard library functions, and C's standard library relies on the OS's special functions. If they were separate libraries, there would be a circular dependency.

Think of C not as "not a language" but as a language that serves the unusual purpose of being the foundation for nearly everything else.

You have a point on integer types being a mess, but we have stdint.h for that.

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

#180

Post by jenadine » Sat, Feb 07, 2026, 7:38 AM UTC

Nevermark wrote: post #178

jenadine wrote: post #171

Earlier quoted context omitted.

> I am puzzled by the claim that C and assembly are not relatively close. Did anyone say that? I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C. The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they ar…

As I noted, closeness has several meanings. > The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. C is not just low level friendly, but low level out of the box. That is the level that all C must be written in, even when creating higher abstractions. Some higher level languages are also low level friendly, not low level strict. Which is a kind dual. I wou…

> C is not just low level friendly, but low level out of the box. That is the level that all C must be written in

No, it is not:

- People use for/while loop, for example, instead of the "low level" 'goto'

- C compiler compute pointer aliasing, assume operations don't overflow, etc., in order to optimise your code: What you write doesn't translate directly to assembly.

- Some low level operations cannot even be represented in pure C (without using __asm__ extension escape hatch)