8 ms·

In what way does C fail to have sane syntax and semantics? You may not like the syntax or semantics, but they are reasonably simple and clean; I would say they

In what way does C fail to have sane syntax and semantics? You may not like the syntax or semantics, but they are reasonably simple and clean; I would say they are eminently sane. The portion of the C spec that defines the language (chapter 6) is actually quite straightforward compared to most language specifications. The syntax is especially straightforward. I can find a few complaints about the semantics (mostly that there would ideally be less implementation- and undefined-behavior), but no worse than my complaints about any other language.

Executor 14y ago
If C had only one source file (i.e. headerless C), then I'd agree that C was great. Otherwise, its a verbose piece of shit language.
- jspthrowaway2 14y ago
  Something Hacker News has taught me is that no matter what, someone's opinion will surprise me.
tikhonj 14y ago
The syntax may be familiar, but I've always thought it's rather arbitrary. There's relatively little over-arching design: it's like they just stuck together features until they had something relatively big. The exact selection of syntactical forms only seems reasonable because it's been around so long and influenced so many popular languages, not because it's particularly neat or simple. Some syntactic forms are rather annoying. For example, you have different ways to write pointer types: int* foo vs int * foo. (Hmm, I am no good at escaping asterisks in HN comments.) This just causes confusion; conceptually, the * is part of the type, but syntactically it isn't! The array syntax is also rather arbitrary. Why can you do foo[0] or 0[foo] when every other similar operation is an infix operator? Why do you write int foo[] when the type of foo is really an int array (say int[]) rather than an int? Why have both an if-statement and a ternary operator? (Actually, the whole statement/expression divide is annoying especially in how it influenced a whole bunch of other languages.) There are a ton of other little inconsistencies and annoyances (let's not even talk about the C preprocessor). Ultimately, the main thing C syntax has going for it is familiarity, but that seems to be more than enough. I certainly find the syntax strictly worse than a bunch of non-C-like languages, although it's difficult to compare them because they have vastly different semantics. The semantics are also a problem. As you mentioned, the overabundance of undefined behavior is certainly not good. This certainly causes very real difficulties for even experienced programmers. Then there are a whole bunch of classic C errors that cause rampant security problems and hard-to-debug behavior. Now, some of these are inevitable due to C's providing low-level access for memory management, but others could probably be avoided with different design decisions. Now, C is obviously a practical and widely-used language. But, as ever, a language's popularity is far more a social issue than a function of its design. The main reasons it seems simple and clear is because it's been around forever, it's influenced the syntax of most popular languages and everyone has either learned C or a very C-like language.
- tedunangst 14y ago
  Declaration matches usage.
- mjcohenw 14y ago
  "Why have both an if-statement and a ternary operator?" Because one is for control of statement execution and one is an expression that returns a value. Two similar-in-purpose but different-in-meaning constructs. In my experience, if the ?-: operator is written in the same way as the if-else (condition, true, and false parts each on their own line), nested expressions are quite clear and understandable.
prodigal_erik 14y ago
Ideally less? We should have adopted zero tolerance years ago. Letting end users' machines be pwned to save 1 ns not checking for a buffer overrun is absurdly bad engineering.
- zxcdw 14y ago
  We can afford it in 2012(in most areas of computing at least). We couldn't in 70's. Imagine scanning through an array with thousands of elements and trying to make it happen real-time with weak hardware. Suddenly that 1 ns grows to 1 second. No can do. Lots of infrastructure is built atop of C, which would need to be rebuilt with something new, supposedly better. Who is up to the task, with what motivation and agenda? What would be the desired language we have today to replace C with? C++? D? Go? Rust? Quite frankly I would place my bet for Rust, and even it(right now) relies on LLVM. It is horribly hard task to provide truly stable and reliable abstractions. C is one of those which has succeeded, despite the problems with it. It is even harder to try to replace such a well-established layer of abstraction.
  - tinco 14y ago
    Right you are. I am not at all arguing for using any of those languages. I too think automatic buffer overrun checking is the sort of thing a true C replacement should not have. Nor should it have _even more_ idiosyncrasies like C++ or automatic memory management or even a runtime (so no rust). You bring to light the painful question, who is going to do it? Language designers are far too keen on fancy features. All C replacements that have been suggested in the past decade, Java, Go, Rust, Vala, rely on runtimes that take away true control in trade for features like typesafety, memory management and security. The person who is going to be the creator of the next C has to be a hero in an epic tale, first he should grow up with clean comfortable languages like C#, Ruby or Haskell, but then dark times will force uncomfortable languages like C and C++ on him. But the rough times will make him stronger, and in the end he will slay the dragon with a tool that unifies his love of comfort with the cold pragmatic of bare metal code. Someone should make a movie out of it ;)
    - 14y ago
gsg 14y ago
Some of C's syntax is distinctly kooky, particularly declarations. By way of illustration, my two favourite C declarations: const struct strange typedef volatile; typedef evil; Or the following, in which the struct tag is a forward declaration, but only within the declaration, and only if the struct has not already been declared: void func(struct odd); There's no good reason for the declaration syntax to have so many meaningless edge cases. It simply was not designed very well. Then there's the other odd bits of C syntax: & and | have the wrong precedence, variables are bound inside their own initialisation forms, labels can appear in bizarre places but can't appear at the end of a compound statement, case statements can be interleaved with other control structures, etc. And there's the preprocessor. None of this stuff has done much damage to C's success, but let's not pretend that the language is free from quirks and corner cases.

Executor 14y ago

If C had only one source file (i.e. headerless C), then I'd agree that C was great. Otherwise, its a verbose piece of shit language.

jspthrowaway2 14y ago
Something Hacker News has taught me is that no matter what, someone's opinion will surprise me.

tikhonj 14y ago

The syntax may be familiar, but I've always thought it's rather arbitrary. There's relatively little over-arching design: it's like they just stuck together features until they had something relatively big. The exact selection of syntactical forms only seems reasonable because it's been around so long and influenced so many popular languages, not because it's particularly neat or simple. Some syntactic forms are rather annoying. For example, you have different ways to write pointer types: int* foo vs int * foo. (Hmm, I am no good at escaping asterisks in HN comments.) This just causes confusion; conceptually, the * is part of the type, but syntactically it isn't! The array syntax is also rather arbitrary. Why can you do foo[0] or 0[foo] when every other similar operation is an infix operator? Why do you write int foo[] when the type of foo is really an int array (say int[]) rather than an int? Why have both an if-statement and a ternary operator? (Actually, the whole statement/expression divide is annoying especially in how it influenced a whole bunch of other languages.) There are a ton of other little inconsistencies and annoyances (let's not even talk about the C preprocessor). Ultimately, the main thing C syntax has going for it is familiarity, but that seems to be more than enough. I certainly find the syntax strictly worse than a bunch of non-C-like languages, although it's difficult to compare them because they have vastly different semantics. The semantics are also a problem. As you mentioned, the overabundance of undefined behavior is certainly not good. This certainly causes very real difficulties for even experienced programmers. Then there are a whole bunch of classic C errors that cause rampant security problems and hard-to-debug behavior. Now, some of these are inevitable due to C's providing low-level access for memory management, but others could probably be avoided with different design decisions. Now, C is obviously a practical and widely-used language. But, as ever, a language's popularity is far more a social issue than a function of its design. The main reasons it seems simple and clear is because it's been around forever, it's influenced the syntax of most popular languages and everyone has either learned C or a very C-like language.

tedunangst 14y ago
Declaration matches usage.
mjcohenw 14y ago
"Why have both an if-statement and a ternary operator?" Because one is for control of statement execution and one is an expression that returns a value. Two similar-in-purpose but different-in-meaning constructs. In my experience, if the ?-: operator is written in the same way as the if-else (condition, true, and false parts each on their own line), nested expressions are quite clear and understandable.

prodigal_erik 14y ago

Ideally less? We should have adopted zero tolerance years ago. Letting end users' machines be pwned to save 1 ns not checking for a buffer overrun is absurdly bad engineering.

zxcdw 14y ago
We can afford it in 2012(in most areas of computing at least). We couldn't in 70's. Imagine scanning through an array with thousands of elements and trying to make it happen real-time with weak hardware. Suddenly that 1 ns grows to 1 second. No can do. Lots of infrastructure is built atop of C, which would need to be rebuilt with something new, supposedly better. Who is up to the task, with what motivation and agenda? What would be the desired language we have today to replace C with? C++? D? Go? Rust? Quite frankly I would place my bet for Rust, and even it(right now) relies on LLVM. It is horribly hard task to provide truly stable and reliable abstractions. C is one of those which has succeeded, despite the problems with it. It is even harder to try to replace such a well-established layer of abstraction.
- tinco 14y ago
  Right you are. I am not at all arguing for using any of those languages. I too think automatic buffer overrun checking is the sort of thing a true C replacement should not have. Nor should it have _even more_ idiosyncrasies like C++ or automatic memory management or even a runtime (so no rust). You bring to light the painful question, who is going to do it? Language designers are far too keen on fancy features. All C replacements that have been suggested in the past decade, Java, Go, Rust, Vala, rely on runtimes that take away true control in trade for features like typesafety, memory management and security. The person who is going to be the creator of the next C has to be a hero in an epic tale, first he should grow up with clean comfortable languages like C#, Ruby or Haskell, but then dark times will force uncomfortable languages like C and C++ on him. But the rough times will make him stronger, and in the end he will slay the dragon with a tool that unifies his love of comfort with the cold pragmatic of bare metal code. Someone should make a movie out of it ;)
  - 14y ago

gsg 14y ago

Some of C's syntax is distinctly kooky, particularly declarations. By way of illustration, my two favourite C declarations: const struct strange typedef volatile; typedef evil; Or the following, in which the struct tag is a forward declaration, but only within the declaration, and only if the struct has not already been declared: void func(struct odd); There's no good reason for the declaration syntax to have so many meaningless edge cases. It simply was not designed very well. Then there's the other odd bits of C syntax: & and | have the wrong precedence, variables are bound inside their own initialisation forms, labels can appear in bizarre places but can't appear at the end of a compound statement, case statements can be interleaved with other control structures, etc. And there's the preprocessor. None of this stuff has done much damage to C's success, but let's not pretend that the language is free from quirks and corner cases.