C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now.

If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.

C, as a language, is very simple. Which leads to horribly complex and monsterous code, especially in large projects. The language makes even simple paradigms impossible to represent, forcing you, instead, to just remember what to do and then do that every time, forever.

I made no value judgement of the language. Simply an assessment of its simplicity. I’m glad you agree with that. Feel free to let the other commenters know, not me.

I am quite sure many people would fail Pub Quizzes related to C, when taking into account the whole language alongside compiler extensions, regardless of the compiler.

To learn all of the common GCC and MSVC extensions would make up a fraction of the language features of C# or Java. You’re really overstating the complexity to make some invalid point.

“Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”

And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.

A pub quizz would consider more than GCC and MSVC, and still I would bet many would fail if talking only about those two.

And I would double down on my bet regarding ISO C related questions, as I have met a few folks that contrary to myself as language nerd, hardly know what is written there or have even opened the PDF drafts at least once in their life.

Yeah, it does not take a long time to learn GCC / Clang extensions, IMO. Have an LLM give you a list of these with examples, really. :P

You can learn everything about undefined behavior in 30mins?

It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus.

But, if you want an answer to your question:

You can learn to avoid undefined behavior in about 30 seconds.

If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.

Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized.

> You can learn to avoid undefined behavior in about 30 seconds.

Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.

Before you could assume...null pointer derefs will be trapped by the OS

Before when?

  Microsoft(R) MS-DOS(R) Version 6.22
               (C)Copyright Microsoft Corp 1981-1994.
  
  C:\TMP>type foo.c
  void main() {
      long q = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od foo.c
  Microsoft (R) Optimizing Compiler Version 5.10
  Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved.
  
  [...]
  
  C:\TMP>foo

  run-time error R6003
  - integer divide by 0
  
  C:\TMP>type bar.c
  void main() {
      long far *p = 0;
      long q = 0;
      *p = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od bar.c

  [...]

  C:\TMP>bar

(system hangs)

In DOS you always had to manage your expectations, not sure what you're trying to prove here?

I think he's thinking more along the lines of PHP 5-8.5

That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.

Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.

And what exactly 9-5 has to do with caring for coding or time investment in language learning?

A person that cares for coding will inevitably code more then 9-5 and consequently get familiar with new syntax

A person that invests time into their language knowledge will not have issues handling new syntax because they spend as much time as necessary to get familiar with the new syntax

So the criteria is being a 9-5 who doesn't particularly care about coding and doesn't invest time into their language knowledge

Not GP, but I assume the suggestion is that it's difficult to stay abreast of new developments within the constraints of a typical work day. Especially if your job utilises older technologies, as most do.