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

71–80 of 217 posts

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

#71

Post by jonjacky »

munificent wrote: post #20
jonjacky wrote: post #18

Earlier quoted context omitted.

It wasn't a coincidence, or an accident. C was specifically designed to write Unix, by people who had experience with a lot of other computer languages, and had programmed other operating systems including Multics and some earlier versions of Unix. They knew exactly what they were doing, and exactly what they wanted.

I'm not sure what you mean by "coincidence" or "accident" here. C is a pretty OK language for writing an OS in the 70s. UNIX got popular for reasons I think largely orthogonal to being written in C. UNIX was one of the first operating systems that was widely licensed to universities. Students were obliged to learn C to work with it. If the Macintosh OS had come out first and taken over the world, we'd probably all be…

> I'm not sure what you mean by "coincidence" or "accident" here.

I mean Unix had to be written in C, not in, say, Algol or PL/I or BLISS, high-level languages used to write other operating systems.

I also meant that the features of C were not put there by impulse or whim, they were the outcome of considered decisions guided by the specific needs of Unix.

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

#72

Post by krior »

smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

Not the error "handling"? The array implementation? The weak type system? The barebones-macro-system? The nearly unuseable standard-library? The standard itself, a 750-page-tome you have to memorize, lest C is allowed to erase your hard drive?

C is sin incarnated.

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

#73

Post by uecker »

TZubiri wrote: post #15
orionblastar wrote: post #2

I always thought that C was a stepping stone to learn other languages. Like Pascal, it was educational to learn. My Comp Sci courses in 1986-1990 used Turbo Pascal and Turbo C.

I think so to, for most devs C is like Latin, or Roman Law, not something we develop and use, but rather something we learn for context and to understand future developments. There's some people that still develop on C for sure, but it's limited to FOSS and embedded at this point, Low Level proprietary systems having migrated to C++ or Rust mostly. I agree with the main thesis that C isn't a language like the others,…

There is also still a lot of low-level proprietary code developed in C. I would guess far more than what is developed in Rust.

I fully agree about your last point. The proposed solutions to some of the deficiencies of C are sometimes worse than the disease while its benefits are often exaggerated, at the same time adding unnecessary layers of complexity that will haunt us for decades. In contrast, my hope would be to to carefully revise the things we have, but this takes time and patience.

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

#74

Post by haberman »

drnick1 wrote: post #31
munificent wrote: post #16

Earlier quoted context omitted.

> why C gets to be the foundation for how systems software is written. Is there an answer here more interesting than "it's what Unix and Windows were written in, so that's how programs talked to the OS, and once you have an interface, it's impossible to change"?

Yes and no. Clearly what you said is true, but the more profound reason is that C just minimally reflects how computers work. The rest is just convention.

More concretely, I think the magic lies in these two properties:

1. Conservation of mass: the amount of C code you put in will be pretty close to the amount of machine code you get out. Aside from the preprocessor, which is very obviously expanding macros, there are almost no features of C that will take a small amount of code and expand it to a large amount of output. This makes some things annoyingly verbose to code in C (eg. string manipulation), but that annoyance is reflecting a true fact of machine code, which is that it cannot handle strings very easily.

2. Conservation of energy: the only work that will be performed is the code that you put into your program. There is no "supervisor" performing work on the side (garbage collection, stack checking, context switching), on your behalf. From a practical perspective, this means that the machine code produced by a C compiler is standalone, and can be called from any runtime without needing a special environment to be set up. This is what makes C such a good language for implementing garbage collection, stack checking, context switching, etc.

There are some exceptions to both of these principles. Auto-vectorizing compilers can produce large amounts of output from small amounts of input. Some C compilers do support stack checking (eg. `-fstack-check`). Some implementations of C will perform garbage collection (eg. Boehm, Fil-C). For dynamically linked executables, the PLT stubs will perform hash table lookups the first time you call a function. The point is that C makes it very possible to avoid all of these things, which has made it a great technology for programming close to the machine.

Some languages excel at one but not the other. Byte-code oriented languages generally do well at (1): for example, Java .class files are usually pretty lean, as the byte-code semantics are pretty close to the Java langauge. Go is also pretty good at (1). Languages like C++ or Rust are generally good at (2), but have much larger binaries on average than C thanks to generics, exceptions/panics, and other features. C is one of the few languages I've seen that does both (1) and (2) well.

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

#75

Post by Nevermark »

kristianp wrote: post #64
stackghost wrote: post #60

Earlier quoted context omitted.

> C just minimally reflects how computers work. The rest is just convention. This hasn't been true for decades. x86 assembly is now itself an abstraction over what the CPU is actually doing. Microcode, speculative execution, etc.

It seems to be a meme on HN that C doesn't reflect hardware, now you're extending that to assembly. It seems silly to me. It was always an approximation of what happens under the hood, but I think the concepts of pointers, variable sizes and memory layout of structs all represent the machine at some level.

> 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 would mean it didn't work!

And C is still very close to the assembly, in terms of basic operations. Even if a compiler is able to map the same C operations to different instructions (i.e. regular, SIMD, etc.)

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

#76

Post by Nevermark »

twangist wrote: post #4
orionblastar wrote: post #2

I always thought that C was a stepping stone to learn other languages. Like Pascal, it was educational to learn. My Comp Sci courses in 1986-1990 used Turbo Pascal and Turbo C.

C was never a gateway to any flavor of Pascal, a "police state language".

It's not a coincidence that Rust was invented in 1984 by some animals on a farm! Stay in thy lane, programmer!

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

#77

Post by player1234 »

CGamesPlay wrote: post #49
TZubiri wrote: post #10

[flagged]

This is just an ad hominem attack. Doesn't seem like the author is "in over their head"; they seem to have a pretty solid grasp of actual identifiable gaps between implementations and various specs, and the article was written with the same kind of "chastising" tone as you would see from any grey-bearded hacker who's unsatisfied with the way things are.

[dead]

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

#78

Post by pjmlp »

nacozarina wrote: post #3

None of the alternatives have stability. What was exemplary & idiomatic rust pre-pandemic would be churlish & rejected now and the toolchain use would be different anyway. Carpenters, plumbers, masons & electricians work on houses 3-300 yrs old, navigate the range of legacy styles & tech they encounter, and predictably get good outcomes. Only C has, yet, given use that level of serviceability. C99, baby, why pay more…

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.

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

#79

Post by pjmlp »

PaulDavisThe1st wrote: post #53
okanat wrote: post #6

Earlier quoted context omitted.

The replacement has already happened. It is HTTP and JSON for 99% of the software developed today. The reason C stayed has multiple reasons but most obvious ones are for me are: - People just stopped caring about operating systems research and systems programming after ~2005. Actual engineering implementations of the concepts largely stopped after the second half of 90s. Most developers moved on to making websites or…

> People just stopped caring about operating systems research and systems programming after ~2005. and so it was that after that date, all development of embedded systems kernel drivers digital audio workstations video editors codecs for audio and video anything that involved actually controlling non-computer hardware game engines came to a grinding halt, and no further work was done.

On Windows, macOS and Android, most of that development on that list is done in C++, not C.

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

#80

Post by pjmlp »

noosphr wrote: post #35
okanat wrote: post #6

Earlier quoted context omitted.

The replacement has already happened. It is HTTP and JSON for 99% of the software developed today. The reason C stayed has multiple reasons but most obvious ones are for me are: - People just stopped caring about operating systems research and systems programming after ~2005. Actual engineering implementations of the concepts largely stopped after the second half of 90s. Most developers moved on to making websites or…

I'd never thought I'd see the day that anyone praises COM.

As idea it is great, as the tooling available in C++ Builder, Delphi, VB 6, C++/CX (WinRT is basically COM with extras) also great.

Using it from MFC, kind of alright.

Using it from .NET, depends if Framework, .NET Native, or modern, with various levels of usability.

Using it from ATL, WRL, C++/WinRT, is a mess unfortunely.

Post reply on HN