Even worse is the realization that hardware has bent to the whims of almighty C.

(don't get me wrong - I love C, it was my first "proper" programming language, learnt it when it was indeed still a) simple to parse, b) a high level assembly language, but I think it's time to exit stage left and leave some space for the newcomers)

the newcomers already have all the space they need. C is not stopping them - its just their language isn't really much better as it doesnt really shrink the massive problem space which is the hard thing to learn how to code in! The problems Rust and Swift 'solve' are all solvable in C and C++ build environments and software methods.

C survives and thrives because it solves many problems well or well enough. Developers of new languages crying about C and its problems doesn't win converts. Its kinda pathetic. If these new wonder languages are so good why do they need to define themselves by trying to prove how much better than C they are?

There is a lot to be said for solutions that work. In my work as a sysadmin I write lots of Bash scripts. Is Bash a great language? No. Is it the right tool for a lot of the work I'm doing, yes absolutely. The nice thing about shell script is that if I run into something too hard to do I can always write a bit of C and call it. Not necessarily pretty but it gets the job done. Language purity is for academic papers, not doing work in the real world. The real world is messy.

Thanks. You've just explained quite nicely why I still use Bash after so many years in spite of my litany of complaints about it. It does the job, and as much as alternatives might look somehow tempting, they don't do the job as effectively (or at all); and/or they're just too much effort and cba. I think maybe I'm becoming a bit unreasonable with age if I'm scolding it for sometimes taking as much as ½ a second to complete a procedure that involves checking through thousands of filenames with arbitrarily complex string wrangling (using a current example that had me fretting about "but why is it taking so long?!") especially as I could rewrite it in C, as you mention. I mean it isn't that long since I was using the college Vax which could take up to 5 minutes to log you in at stressful times.

And well, a lot of what we do as IT folk is copying and pasting existing samples to save time and effort. Wanna parse a text file in bash and/or C? There's a litany of examples out there that you can copy and it just works. Wanna do the same in Java? I'm sure it's doable, but now I gotta think…

"it isn't that long since I was using the college Vax"

It is, but only when you stop to think about it. Welcome to the club.

I try not to think about it....

In this context, worth noting that there was something called the VAX Procedure Calling Standard that made it (relatively) easier to call one programming language from another, but there are some fundamental differences that can't be wished away.

C was never even a particularly good language for writing operating systems - Linux depended for years on specific quirks of gcc, which isn't ideal: you'd like to get the behaviour you want by design rather than by accident.

But when you have to get down to details like addressability, word length, byte ordering and specific machine instructions high-level languages can only get you so far.

"C survives and thrives because it solves many problems well or well enough. "

Does it? Does it, really? Exactly how many CSV's do we need to show that C doesn't really solve "all problems well or well enough", because its inherent obscurity in handling some constructs (as the article mentioned) leave holes that the developer is [constantly] responsible for solving.

Every single time.

C programmers are so entrenched in their belief of superiority that they dismiss the inherent problems in the design and (current) implementation of the language on modern computers, computers that are logarithmically more complex than the computers the language was originally designed to run on. System complexity that C was never designed to handle intrinsically, leaving the modern developer to constantly dot the i's and cross the t's in [trying to] assure that the code handles faults and attacks properly.

Yet, instead of leveraging the power of these complex computers and let the language construct do this work for them, C programmers doggedly hang on to their beliefs of superiority.

THAT'S the point of the article.

C programmers are so entrenched in their belief of superiority that they dismiss the inherent problems in the design and (current) implementation of the language on modern computers, computers that are logarithmically more complex than the computers the language was originally designed to run on

Computers made of 'straw'? OK that was a different kind of 'logic'. [Bad PUNishment. yeah]

I noticed you also used the word 'modern'. I am reminded of how THAT has been misused to describe "fad of the week", usually another FLATSO user interface or some "new, shiny" something that's trying to become relevant.

Seriously I have not seen any CPU or system designs, with the exception of quantum computing, where a programming lingo like C would NOT be useful. (for quantum computing I'm still waiting for a programming model that actually works)

(If it can run Linux, it can be programmed in C)

Language purity is for academic papers, not doing work in the real world

see icon

This. C has been around for 50 years, with 50 years of libraries to go.

It always baffles me how it always seems like these new languages have to push for some sort of coup d'etat where overnight the newcomer penetrates everything from embedded processors to desktop applications. Might be part of the instant-everything syndrome. If Rust/Language X is so much better, it will prevail. Be it for kernels, web assembly or both.

I could even mention how useful it is to learn a language like C that forces you to learn to think more like a computer, rather than a compiler who goes out of its way to pretend you can just write plain english instead of code, but I am not sure whether that'd be more of an emotional rather than a rational argument.

I think I disagree with you, but from a religious rather than rational perspective.

Religiously, I love C, I don’t like programming in other languages, but only because I’m comfortable with it, and I’m closer to the grave than the cradle - so I really don’t want to learn something new.

Rationally, I know I need to learn something new (so I do) or get out of the game.

So you’re right - though I wish you weren’t - so have a thumbs up.

I don't know. How many Fortran programmers love Fortran? How many COBAL programmers love COBAL? The fact C is so very pervasive and yet its programmers still love it is very telling.

I've tried to read some of how Rust works. However certain things never make sense to me in many of these new languages.

io::stdin()

.read_line(&mut guess)

.expect("Failed to read line");

Why would you chain together operations for input? Doesn't it make more sense to split complex problems into small independent pieces? If anything this looks a lot like an over-loaded function with optional parameters in C++.

So, OK. These new languages are there and OK and all that, but I don't think any of them are "better" than C. (Even C++ really isn't better.) In some ways they have advantages that C can / should never have. Garbage collection, memory safety, true exceptions. But none of that would ever have been possible in the 1970s, and such features have significant overhead.

C really is a great language. There are some others too. Swift and Rust are probably still too new to really tell how good they are.

As to OS calling conventions. If there's a better way to call functions across module and even program boundaries than C API, we should probably try to use it. I'm not sure how "Result" is going to cross language and environment boundaries though (or indeed even exceptions don't do that so well).

I think it's time to exit stage left and leave some space for the newcomers

Considering that we use a time system that originated in Babylonia 2.5 millennia ago it may be a while before that happens.

"There is no problem that can't be solved by another layer of abstraction - except for the problem of too many layers of abstraction."

Just like [1]XKCD's standards . We should write one new language to rule them all... and then we just have one more. We make one more abstraction to abstract it all... etc.

Maybe we should teach the next generation to use the appropriate tool for the particular job and adapt to a heterogeneous landscape that should be embraced instead of cursed.

[1] https://xkcd.com/927/

"We should write one new language to rule them all"

We tried that in the 1980s. The result was Ada and it didn't have a happy ending.

The result was Ada and it didn't have a happy ending.

Especially not for the first Ariane 5.

I've given you an upvote for humour, but the real issue was of regression testing and input sanitisation.

Ariane 5 reused a system from Ariane 4, but a parameter that it measured was greater on the new bigger/faster/etc. rocket, so when it type converted a value before sending it to another system it eventually overflowed and generated an error message instead. The receiving system tried to parse the error message as if it was the correct output and came up with a random number, which was then fed in to the flight control parameters and it all went horribly wrong!

The optimism was enough that I'm still almost sold on the idea 35 years after first using it and keep intending to go back to it any day now. But until that day, I still mostly use C, or Bash or whevs.

"We should write one new language to rule them all"

We tried that in the 1980s. The result was Ada and it didn't have a happy ending.

Especially since Ada was supposed to the one true language to rule (depending on who you ask) C, or PL/1 (which was itself the one true language to rule them all before the next one true language to rule them all...)

Whew! I got dizzy there for a second...

There is no problem that can't be solved by another layer of abstraction

I always liked the bit in Vernor Vinge's A Deepness in the Sky where the Qeng Ho use "software archaeologists" to handle the multiple layers of software right down to the bottom which is "one of Humankind's first computer operating systems" with an epoch that's "actually about fifteen million seconds later" than the first time a human set foot on the Moon.

I wish I could upvote this comment multiple times for calling out the best SF novel ever written.

Buffy: There is no problem that cannot be solved by chocolate.

Willow: I think I am going to barf.

"for almost any program to do anything useful or interesting, it has to run on an operating system"

No, it doesn't. In the old days, I wrote plenty of programs in C which, as the first action after starting, deliberately disconnected MS-DOS from all the machine's interrupt vectors so that my program and the BIOS could work without MS-DOS getting in the way.

Hence the -almost-. And a program or game taking over the whole hardware/shutting down the OS was already rare some 20 years ago

I’d suggest that you might have this the wrong way round. The world does not end at the door of the data centre, the edge of the desktop, or the vanishingly thin bezel of your tablet or phone. There is a whole lot of code running in washing machines, heating appliances, and in anonymous looking boxes in utility cupboards which either runs on bare metal or on an RTOS so vanishingly thin that you’d barely know it was there.

C is still very popular for embedded stuff, and it’s not just because it annoys the younglings…

I've written useful, interesting and more importantly code I was paid to write that ran directly on processors like the 6502, PIC processors, etc. None of them had even the slightest whiff of an operating system.

The new argument goes something like this: for almost any program to do anything useful or interesting, it has to run on an operating system.

That really isn't so; there are hundreds of thousands (quite possibly more) of microcontrollers running bare metal and doing very interesting things. Even where an OS is desirable, many microcontroller architectures (including ARM based devices) map very neatly to C. I know that from several dozens of projects where they were a mixture of bare metal / various OS and the code was written in C simply because it was the best choice for the task .

That also debunks the myth that C hasn't matched (bare metal) processor architectures since the 1970s; it demonstrably does so to this day. I am not saying it maps to all processor architectures because it doesn't at the bare metal level.

I would be the first to admit that C has its issues (as does every language) and there are parts of it to steer clear of especially if portability for either the target architecture or compiler is important, but the use of a [1]decent set of rules avoids the vast majority of problems.

There are places where C really is the best choice and others where a different language may be a better fit, but to try and argue that it is not a programming language is rather over the top and smacks of 'language elites'.

There is no single programming language that is appropriate to every task.

C is widely used for a lot of reasons; every language choice is a trade-off for a given project.

[1] https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard

Not seen the Barr rules before. Over the years I built up a much larger set of rules which I found useful and could write bits of code to check for. I was playing with RHide on Freedos the other day getting all nostalgic and then found Motor which I might just have a play with to backfill with the old things I used to use on C/C++ code that made it pretty much bulletproof- if you can save a piece of code with potential error in it (and automatic idiots guides) then you're at least somewhere a bit safer.

MISRA is the obvious one, based on automotive safety concerns, and then the is also the ones drawing up for the Joint Strike Fighter systems:

https://www.stroustrup.com/JSF-AV-rules.pdf

Another good overview and guide comes from the Numerical Recipes books, they cover many things but mostly it is about being consistent and readable. If only programmers could start with that!

I looked at the link in your post under 'decent set of rules' and gave it a quick glance. Not only did it advocate the use of Allman style indents and braces, it also said "The tab character (ASCII 0x09) shall never appear within any source code file." .

It has my approval!

(that way the editor or merge tool or viewing tool you use does not affect the appearance of the code)

-> 'Beingessner should know. They've'

She's more than one person?

We are not amused

Surely that should be 'we is not amused', or 'I are not amused'.

The royal 'we'

Or, as we might say in South London: "VoiceOfTruth, is you more than one person?"

"is you more than one person?"

Fair question as we don't use 2nd person singular pronouns any more.

One of my favorite entries in the controversy is

http://itre.cis.upenn.edu/~myl/languagelog/archives/003572.html

but this is a mere sip from the well. I'm sure your [1] google-fu will be able to find many more, and some are well written and funny.

In fact, Language Log is a well of information and (usually) friendly debate on matters of language. A respite from editor wars and pleas for "A computer language that will let me do anything but make a mistake".

[1] All y'all's (just in case you're are a hive mind)

Joke icon "just in case", but the whole subject does sometimes remind me a bit too much of the Babelfish wars

All the issues discussed flow from C running on top of a modern OS or on top of the hardware abstraction layer of the OS which is written in C, and a processor geared to servicing the needs of that OS. There it emulates a low level language, and is extremely useful doing it: so good, in fact that all modern OS's and their key libraries are written in C, and very few problems have arisen (the fact that it is possible to list named examples of problems illustrates how few they are). For every instance of a OS based system, there are a hundred embedded devices too small to require an OS, and the code there is written in C and it works on the bare metal.

The article (and the ACM piece it draws from) could more accurately be rewritten as 'C is vital to modern computing, and does it's job very well, but not perfectly.' Of course, this, while evidently true, is so evidently true as to be boring and unworthy of reporting. Much more interesting to report on the mitherings of the proponents of newer languages who don't want to do the work required to get their new toys to work well with existing infrastructure.

Arguably C is one of the very few programming languages.

For example, most languages such as Python, Lua, CSharp.NET/Java are just C programs that interpret glorified text files and do different things depending on whats in them.

Rust, Go and Swift are languages that finally started to appear once people got bored of the old Limbo-style VM languages like .NET and Java.

However much of a developers life using them is spent writing wrappers around C libraries! Bindings suck but you either write them yourself or you rack up technical debt dragging in thousands of packages from NPM, crates.io, PIP, CPAN, etc.

A [1]tweet from a couple of days back by Colin Percival on the advantages that working in C can have, even where most of us might not think of using it.

[1] https://twitter.com/cperciva/status/1505817985654530050

"My problem is that C was elevated to a role of prestige and power, its reign so absolute and eternal that it has completely distorted the way we speak to each other."

No. Your problem is with History. Just grow up and damn well deal with it.

Really getting sick of these people whining about a revolution that happened 50 years ago, and blaming all their current problems on that.

If you can't take it, hand over to those who can.

re: "it's very difficult to parse; there are multiple competing and subtly incompatible implementations; and then there are the complex ways that C defines and handles integers."

You can say the same about Welsh, and that's still considered a language.

-mobailey

"You can say the same about Welsh"

Even the bit about integers?

> [ ... ] C isn't a programming language anymore.

After 50 years - and counting - of software written in C, that's a pretty bold statement.

> There are many problems with the C language.

Yes, indeed. C requires the programmer to think . As opposed to copy-pasta from StackOverflow. In 2022 that may be a bridge too far.

> it's very difficult to parse.

No, it's not. Actually, in terms of parsing and AST generation, it's one of the cleanest programming languages ever invented.

Wanna talk about hard to parse languages? Try C++ or Java.

In fact, there exists at least one freely available implementation of a C11 LALR(1) grammar, written for Lex/Yacc. Obviously it works with Flex and Bison as well:

[1]http://www.quut.com/c/ANSI-C-grammar-l-2011.html

[2]http://www.quut.com/c/ANSI-C-grammar-y-2011.html

It's been around since 1985 or thereabouts, for various iterations of the C Standard.

Yes, http. I don't know why it's not https, but such is life.

And then there's this:

[3]https://hal.archives-ouvertes.fr/hal-01633123/document

Seriously? Stuck figuring out the ambiguity between the * pointer operator and the * multiplication operator because C is not a context-free grammar?

I confess: I stopped reading after that.

Free hint: there's three possibilities: a binary operation, a unary operation or a declaration. Figure it out.

If you haven't figured out that this won't be resolved during the initial AST generation pass, and you need Sema, stop trying to write parsers. Go back to copying and pasting Python, Go or Rust.

[1] http://www.quut.com/c/ANSI-C-grammar-l-2011.html

[2] http://www.quut.com/c/ANSI-C-grammar-y-2011.html

[3] https://hal.archives-ouvertes.fr/hal-01633123/document

Your comment couldn't be more spot on. With C Brian Kernigan and Dennis Ritchie found the goldilocks zone between unforgiving hardware assembly programming and inefficient ideas of dreamers.

C is humble, easy to learn and powerful.

Those who know the pdp-11 would agree that comparing its instruction set to the C programming language is actually a great compliment for C, since pdp-11 is an example of a beautiful and clean system architecture, contrary to for instance Intel which is a total mess of garbled and mostly failed ideas

C brought us where we are today, it is relative easy to build compilers for various hardware, hence the unparalleled success of Unix on countless processor types and applications running directly on micro controllers.

The "its from the 70's !!" argument the author of the article highlights so triumphantly, gets old as well, in the 70's great accomplishments and advances in technology were realized, which are the basis of the IT technology we use today.

Am I right in stating, that from your article that any language that needs an OS is "not" a programming language, or have I misunderstood the point here?

The reason I felt compelled to respond as I don't believe what you are saying is correct, actually, I feel it is very wrong. Anyways, moving on with life, I'm going back to programming, ermm actually maybe I shouldn't be calling it programming anymore, ermm developing perhaps, so confused by this article now...

[Article author here]

Yes, you have misunderstood the point. Completely, in fact.

I suggest re-reading it *and* following the links and reading the original author's explanation closely, too.

What was it Wirth said about the choice of programming language affecting the way you think about a problem? (I'll find it, I'll find it.)