Hacker News Reader

Hacker News

Comment by pjmlp | Hacker News Reader

Full thread

pjmlp

Programming languages are software products like everything else in the industry, they either stagnate or evolve.

View on HN

As in biological evolution, the parts with the most "breaking changes" tend to remain quite stable.

At a far far slower pace, maybe.

Depends on the language, ISO/ECMA ones take their time, around three years, others every year/six months.

Then what happened to C?

Maybe an unique historical opportunity for a tool "good enough" to do the job, seizing the widespread adoption possibility, and letting no room in this ecological niche.

That is, yes, there is room for stable languages, but it’s already fully occupied. So only languages targeting market with a mindset open to "better moving continuously anywhere than risking sclerosis" can flourish.

Now, that might be a bit caricatural of course.

C has had plenty of updates, see my reply.

Stable is not frozen. Yes, C got updates, it doesn’t mean they introduced large sets of features, which is what this thread is about. C did not incorporated much things over the years, unlike C++ for example.

I recommend a thorough read of ISO standards and accompanying documents.

http://www.open-std.org/jtc1/sc22/wg14/

http://www.open-std.org/jtc1/sc22/wg14/www/projects

The introduction of the C11 memory model was a huge change. Superficially, only a small amount of features was added, but the impact on writing parallel/concurrent code in a portable way is hard to overstate.

C got C89, C90, C99, C11, C17, and is on its way to get C2X.

C has been evolving, there are C89, C90, C99, C11 and C17 standards and a new one is in the make.

But the last version with major changes was C11, nearly a decade ago. Even that was almost entirely backward-compatible, other than a few very specific cases like removing the inherently dangerous `gets` function from the standard library. And even that removal followed formal deprecation several years earlier, and widespread advice not to use it at all for many years before that.

Put another way, while the C language has evolved, you can still compile C code written several decades ago using modern tool chains with an excellent chance of having it work immediately or at worst needing some very minor changes.

It’s depressing that some of the comments in today’s discussion are praising Clojure because code often still works after 5 years. Obviously that is itself a good thing, but is only 5 years now a remarkably long time for code to still work?

Actually no, because C11 has removed features from C89 and C99, while C17 has done some UB "improvements".

There is very little that has changed that isn’t backward compatible, though, and what there is has mostly been in areas that no sensible programmer should ever have relied on in more than toy programs anyway, like inherently unsafe functions or undefined behaviour. You probably have to go back to C99 prohibiting some things that used to be implicit and therefore to code written over two decades ago to find “real” exceptions to that. Compared to many “modern” languages, I’d say that’s still an excellent track record for longevity and compatibility.

Toy programs like Linux kernel, once an heavy user of VLAs, which only GCC and clang ever implementated, while everyone else just moved from C89 to C11 without ever caring about them.

Sorry, I’m not sure I’m understanding your point here. Are you claiming that variable length arrays have been removed from C in recent standards after they were added in C99? Or is your objection that some compilers are very slow to support language features even after they have been standardised? Or something else?

I am not claiming, it is a fact.

It was dropped from C11, moved into optional annexes and all commercial compilers that were yet to be fully C99 compliant just moved to C11 instead, without bothering with optional annexes.

The world of C compilers isn't only GCC and clang.

Something being dropped is not the same as making something optional. In this case, the latter action was an explicit recognition of the reality that many compilers never fully implemented the previous standard anyway.

The point here was about backward compatibility. What standard C99 code is not also standard C11 code? What used to compile a few years ago but won’t compile today? We all understand that there are some minor exceptions, but I think it’s fair to say the answer to both question is not much.

VLAs, can't make it any clearer than that.

Any use of Annex K functions, gets(), any code that is considered semantic invalid under C11 memory model, or gets wiped away with the new UB cases from C17.

Reply on news.ycombinator.com