Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty.

There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time.

Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers.

Besides: I have yet to see a compiler that didn't have flags to make it compile to a slew of older dialects of C, so if C1X happens to break your old code, you set such an option, or you fix your source code.

There, fixed it for you.

The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits.

Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.

typedef char bool

And thus compiling this code in C99 would not work if bool were a keyword of the language. That is why the boolean datatype is called _Bool, so it doesn't clash with old code. In new code, you can still use the bool datatype, but instead of defining it yourself with char or int, you should better use a typedef of the _Bool datatype in stdbool.h

Defending the status quo by saying "well duh, you should know better, take it or leave it" is just a way of rejecting someone's contentions without actually addressing them. In a reasoned debate that's indefensible.

If he's wrong, tell him why rather than telling him to take his ball and go home.

Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee 20 did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator.

Note that this guiding principle was listed first. The author disagrees with one of their fundamental guiding principles. My point is that he then has a fundamental disagreement with the purpose of the standard, and for that reason, perhaps he is using the wrong tool.

If someone has the guiding principle X, and someone else has the guiding principle !X, I contend that difference is irreconcilable.

[1] http://cm.bell-labs.com/sys/doc/comp.html

[2] http://cm.bell-labs.com/sys/doc/compiler.html

Huh? stdnoreturn.h only makes sense with the new _Noreturn keyword. The old code can keep using __attribute__((noreturn)) or (if it was portable code) nothing at all, without including any headers.

> Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.

I think C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless, and I'd like to see the whole standard library included by default (using some yet-to-be-invented more flexible PCH magic to ensure it doesn't slow down compilation). But in lieu of that, it's hardly a big jump from library to syntax - and if keeping backward compatibility isn't hard, why not do it?

But doesn't most languages do this? Like java's imports (only a really small subset is included by default) or python. I would have thought that namespace separation is a good thing.

(maybe pick something other than double colons, heh.)

    python -m this | head -4 | tail -1

That would be nice, if only I believed it.

Ha. You're adorable.

While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles.

There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time.

But in the future, it's all Javascript/Ruby/CSS/HTML5! Why worry about writing more C code? ;)

Only you have to use the same molecules of metal by the laws of physics, while compilers you can IMPROVE. Heck, we even produce new metal alloys and materials all the time. So, the analogy is 100% flawed.

  The "Backwards compatibility, no matter the cost" 
  mentaility is costing us dearly in the quality of
  the tools we have work with in the future, while
  providing us no relevant new benefits.

It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.

     I am responsible for so much old code that 
     I say we should not cripple the future for it.

It is a big problem that so many standards, requirements and tools (from EMACS to Coverity over lint) have their fingers in the C-syntax. The autocrap abomination is a further complication.

So I guess a good place to start is to swear that we will never touch or use the botched ISO-C thread API, and beat some sense into the WG14, by whatever means are available.

A long period of stability may also make it easy for C to interact with other languages. I'm out of my depth here. Some standard specifications for pinning memory from garbage collection, if Scheme could specify TCO, perhaps C-consolidation release could improve its toolability for things like Coverity; A better autoconf; Makefiles; Standard compilation error codes; Something that would clean up all the rough edges in supporting C compilers.

ballard 3 hours ago | link [dead]

Java was an over-reaction to C.

Go was a reaction to Java back to almost center.

C is close to hardware, which is important for things like game engine cores, video drivers, varnish and the list of use-cases goes on and on.

Finally, people tend to complain about their tools even when those tools work. Be thankful if you didn't have to write the tool yourself. But if you would feel compelled to complain, write a better one yourself first instead. :)

@phk: When was the last time you wrote inline asm in C to solve any problem on an non-embedded system? Mine was 1996.

I will, however, say "ugly".

If you direct your remarks at what's being said instead of who (you think) is saying it, you wouldn't miss so wildly.

Many of the libraries on a typical Linux system (anything glib/gtk based, libxml2, etc.) use _Word extensively.

The spec could contain, "don't add any bugs into your C programs" but that doesn't magically mean that everyone would write bug free code.

Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee.

How do you expect the compiler to enforce the "identifiers that begin with two underscores are reserved for use by the implementation" rule? Some things just belong in the documentation.

Problem solved. Instead, they did something awkward by trying to carve out namespaces for the stdlib too but quite frequently don't adhere to their own rules.

Go and read your /usr/include/stdio.h (or equivalent). It will be filled with such symbols. Obviously the compiler must lex them exactly as it would unreserved symbols.

This is an unfortunately legacy of C's decision to pass compilation information around by textual inclusion, and isn't really fixable at this point.

I do think compilers ought to have warnings for using identifiers in the reserved namespace. Most projects probably wouldn't trip over the ^_[A-Z] reserved space; however, numerous projects would trip over the reservation of any identifier containing two adjacent underscores.

Conceptually a warning is a nice idea, but it just isn't practical.

The problem is that too many people assume that their usage of C is the same as everyone elses. I don't want to be writing a system library and fighting my compiler everytime I put something in the symbol table that isn't in the C spec.

Python 3 is the default on some Linux distros (e.g. Arch Linux)...

Python 3 chose pain now - and I think they made the correct choice - but three years later, people are still upset and many, many Python libraries have not made the transition.

This is exactly the problem. Distros (c.f. Red Hat, SUSE, Ubuntu) with large installed bases simply cannot ever ship a /usr/bin/python as anything but python 2 for exactly the same reason that the kernel cannot change syscall numbers. It will break their customer's software. Arch Linux doesn't really have "customers" in this sense, so they're free to play. The serious distros aren't.

Just mark my words: python 3 will never be a default "python". We're entering year 4 of the python3 era. You really think anyone's going to jump now if they haven't already?

Yeah, he says the same thing at the bottom:

>Poul-Henning

I guess it would be nice if he warned you up front, but at least he does include the warning.