Hacker News Reader

Comment by teyc | Hacker News Reader

First off, I didn't realize. I'm sorry.

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

I had to read that a few times. Are you advocating a clean break so that whatever that is future is clearly not called C or even purports to be backwards compatible with C? That would be difficult wouldn't it? It simply wouldn't get traction.

View on HN

I'm not sure I have a coherent proposal. Clearly ISO-C is a cul-de-sac by now, and will have to be ditched. What we should replace it with is not clear to me.

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.

Perhaps the only place for C to go is for a final consolidation specification, which will be frozen for 50 years. You might even remove some broken parts of previous specifications, but with 50 years of stability, it gives a lot of confidence that any work would be worthwhile.

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.

Reply on news.ycombinator.com