Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO C is increasingly moronic

varnish-cache.org

Post reply on HN
Print view View original

41–50 of 175 posts

Re: ISO C is increasingly moronic

#41

Post by ajross »

reacweb wrote: post #38
ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

breakage of pre-existing code is really a poor excuse for such craziness. Seriously do you prefer an error message during compilation that is easy to understand and not so difficult to fix or a language so tricky that nobody can read the huge reference manual. I fully agree with the author. Seek and hang the culprits !

That's not what C1X is for. It's a straightforward evolution of ISO C99 which adds features without breaking anything. If you want a similar low level language which is not compatible with legacy C you don't have to look far: history is littered with their carcasses.

Re: ISO C is increasingly moronic

#42

Post by angersock »

dextorious wrote: post #30
angersock wrote: post #26

Earlier quoted context omitted.

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. 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 / what…

"""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."""" Only you have to use the…

I've got one involving cars if you prefer. :)

Re: ISO C is increasingly moronic

#43

Post by phkamp »

scott_s wrote: post #31
phkamp wrote: post #22

Earlier quoted context omitted.

You are rationalizing: C was not "novel", it was pretty much BCPL-light. There also were portable operating systems before UNIX, some of them were written in PL/1 and FORTRAN.

BCPL had a single data type (the "word") and no structures. Ritchie's paper above covers the innovations in C quite well. See sections "The Problems of B", "Embryonic C" and "Neonatal C".

And that's where C started out (as 'B').

Adding structures or for that matter pointers to a programming language was not "novel" in 1970.

The sheer success of the UNIX and the myth it has built, has many contemporary programmers thinking that everybody else punched cards with flint tools around the bonfire. Even MULTICS, a very innovative and in many ways wonderful OS has gotten a bad rap because of the UNIX-fanboiz cult-building.

Dennis, Ken & Brian broke ground, but very few people can correctly say what new ground they broke. (Hint: namespaces, file structure, what a file contains).

Re: ISO C is increasingly moronic

#44

Post by forgotusername »

phkamp wrote: post #40
forgotusername wrote: post #33

Earlier quoted context omitted.

For the third time, the API for setting stack size should be implementation defined because there are perfectly practical implementations for which any specification would be meaningless. Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory,…

Please give an example of an implementation of this thread API where having the ability to specify the desired stacksize would "be meaningless" ? Even on 64bit machines you can and will have memory fragmentation when you approach a million threads. PS: A bad analogy is like a wet screwdriver.

1) http://gcc.gnu.org/wiki/SplitStacks

> This is currently implemented for 32-bit and 64-bit x86 targets running GNU/Linux in gcc 4.6.0 and later. For full functionality you must be using the gold linker, which you can get by building binutils 2.21 or later with --enable-gold.

2) You're still conflating heap and stack.

Re: ISO C is increasingly moronic

#45

Post by phkamp »

forgotusername wrote: post #44
phkamp wrote: post #40

Earlier quoted context omitted.

Please give an example of an implementation of this thread API where having the ability to specify the desired stacksize would "be meaningless" ? Even on 64bit machines you can and will have memory fragmentation when you approach a million threads. PS: A bad analogy is like a wet screwdriver.

1) http://gcc.gnu.org/wiki/SplitStacks > This is currently implemented for 32-bit and 64-bit x86 targets running GNU/Linux in gcc 4.6.0 and later. For full functionality you must be using the gold linker, which you can get by building binutils 2.21 or later with --enable-gold. 2) You're still conflating heap and stack.

Too bad it is not part of the ABI specification on any known platform, so if you call a library function compiled without this magic compiler you're totally screwed.

But an interesting research project, I'll grant you that.

Re: ISO C is increasingly moronic

#46

Post by alexis-d »

ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

"For an example of what happens when you break compatibility in the name of "progress" see Python3, which years on is still not installed by default anywhere, and probably never will be."

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

Re: ISO C is increasingly moronic

#47

Post by reacweb »

ajross wrote: post #41
reacweb wrote: post #38

Earlier quoted context omitted.

breakage of pre-existing code is really a poor excuse for such craziness. Seriously do you prefer an error message during compilation that is easy to understand and not so difficult to fix or a language so tricky that nobody can read the huge reference manual. I fully agree with the author. Seek and hang the culprits !

That's not what C1X is for. It's a straightforward evolution of ISO C99 which adds features without breaking anything. If you want a similar low level language which is not compatible with legacy C you don't have to look far: history is littered with their carcasses .

Think about C++: not only legacy C++ was broken by each standard, it was also broken by each compiler releases. The change of compiler release was always a journey.
It is normal that introduction of a new keyword breaks legacy C. A new standard is compatible with legacy code if the only adaptation required is to rename identifiers that collides with new keywords. There is no excuse for producing such a crap.

Re: ISO C is increasingly moronic

#48

Post by derobert »

phkamp wrote: post #34
jemfinch wrote: post #18

Earlier quoted context omitted.

The constitutional convention of 1787 seems to have done a pretty decent job.

You mean the job where the first 10 ammendments were necessary after just two years ? :-)

Amendments 1–10 and 27 were products of the same Philadelphia Convention that produced the US Constitution, and were proposed along with it.

You could try Wikipedia: http://en.wikipedia.org/wiki/United_States_Bill_of_Rights#Ph...

Re: ISO C is increasingly moronic

#49

Post by teyc »

phkamp wrote: post #17
ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

First of all: You're wrong, the compatibility is the other way around: The old code will have to include if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. 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 ve…

  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.
That is only because you don't have a vested interest in old code bases. (Taking a rough guess here: you're under 30?)

Re: ISO C is increasingly moronic

#50

Post by chipsy »

phkamp wrote: post #17
ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

First of all: You're wrong, the compatibility is the other way around: The old code will have to include if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. 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 ve…

Maybe the ISO committee is conspiring to destroy C with mediocrity so that a shiny new systems language can take its place, correcting C's deeper warts in the process.

That would be nice, if only I believed it.

Post reply on HN