5 ms·

There are a lot of features thrown into this language that don't seem worth the learning costs they incur. What are the problems you're really trying to fix?

There are a lot of features thrown into this language that don't seem worth the learning costs they incur. What are the problems you're really trying to fix? Focus on the things that are really important and impactful, and solve them; don't waste time on quirky features that just make the syntax more alien to C programmers. * `if` / `case` / `choose` improvements look fine, though not that important. * Exception handling semantics aren't defined. * `with` is pointless and adds gratuitous complexity to the language. * `fallthrough` / `fallthru` / `break` / `continue` are all just aliases for `goto`. It's not obvious to me that we really need them. * Returnable tuples look very nice. * Alternative declaration syntax looks like a nightmare. If we were redesigning C from the ground up, a different declaration syntax might be better, but mixing two syntaxes is a terrible, terrible idea. * References. Why? They only add confusion. * Can't make head or tail of what `zero_t` and `one_t` are about, or why they would be useful. * Units (call with backquote): gratuitous syntax, unnecessary and confusing. * Exponentiation operator: gratuitous and unnecessary.

SolarNet 9y ago
> Can't make head or tail of what `zero_t` and `one_t` are about, or why they would be useful. I suspect it's the same problem C++ has/had (C++11 fixed it) with bools (see the safe bool idiom [0]). Basically treating a type like an integer (arithmetic object) and boolean (logical object) at the same time is problematic (especially for a "system" type meant for extending implicit system behavior). Because then I can do `if(BoolObject < 70)` when I only meant for `if(BoolObject)` to work (where "BoolObject" is some object evaluating to a bool, and by evaluating I mean coercing/casting). Here it looks like they approached it by making 0/1 (effectively C's false/true) different types and relying on their simpler/more-powerful type system (e.g. because they don't have to worry about C++'s insane object system). Not a terrible idea if they were otherwise actually sticking to their goal of "evolving" C (most of their features are radical departures from the language like exceptions). C++11 solved it by clarifying how implicit explicit casting [sic] of rvalues works in certain keywords (which I strongly doubt anyone can say was the simpler way of solving the problem). [0] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool
kragen 9y ago
Yeah, Ping, I agree. It reads like they missed the key lesson of C — in Dennis Ritchie's words, "A language that doesn't have everything is actually easier to program in than some that do." And some of the things they've added vitiate some of C's key advantages — exceptions complicate the control flow, constructors and destructors introduce the execution of hidden code (which can fail), and even static overloading makes it easy to make errors about what operations will be invoked by expressions like "x + y". An interesting exercise might be to figure out how to do the Golang feature set, or some useful subset of it, in a C-compatible or mostly-C-compatible syntax. I do like the returnable tuples, though, and the parametric polymorphism is pretty nice.
emilfihlman 9y ago
Exponentiation operator gratuitous and unnecessary? WHAT?
- kragen 9y ago
  It doesn't improve readability. Compare: discrim = b² - 4ac; // Standard notation float discrim = pow(b, 2) - 4*a*c; // C float discrim = b \ 2 - 4*a*c; // C∀ I would argue that these are presented here in descending order of readability. Also its typing rules are really complicated; apply it to two integers and magically you are thrown into the floating-point world where you can never be completely certain of anything, but if you use an unsigned exponent then you stay safely in integer-land.
  - dom96 9y ago
    The choice of operator seems very odd to me. Wouldn't `^` be significantly more readable?
    - userbinator 9y ago
      ^ is already used for bitwise xor.
      - earenndil 9y ago
        What about then, like some other languages?
        kbenson 9y ago
        > What about then, like some other languages? I assume there's a double asterisk there, and it's being eaten by the formatter?
        earenndil 9y ago
        Right yes. I forgot to escape, and now it's too late to.
dzdt 9y ago
I bike-shedded in this thread about exponentiation. But taking a step back the bigger issue is there are so many poorly justified features thrown in. I don't have the feeling that the authors appreciate the appeal of C as a simple language that maps closely to hardware features. This is a big random collections of extensions that piqued some implementor's fancy. There is seemingly no effort at narrowing down to the cleanest or most important ideas. It totally kills the clean, simple aesthetics of the the base C languge.

SolarNet 9y ago

> Can't make head or tail of what `zero_t` and `one_t` are about, or why they would be useful. I suspect it's the same problem C++ has/had (C++11 fixed it) with bools (see the safe bool idiom [0]). Basically treating a type like an integer (arithmetic object) and boolean (logical object) at the same time is problematic (especially for a "system" type meant for extending implicit system behavior). Because then I can do `if(BoolObject < 70)` when I only meant for `if(BoolObject)` to work (where "BoolObject" is some object evaluating to a bool, and by evaluating I mean coercing/casting). Here it looks like they approached it by making 0/1 (effectively C's false/true) different types and relying on their simpler/more-powerful type system (e.g. because they don't have to worry about C++'s insane object system). Not a terrible idea if they were otherwise actually sticking to their goal of "evolving" C (most of their features are radical departures from the language like exceptions). C++11 solved it by clarifying how implicit explicit casting [sic] of rvalues works in certain keywords (which I strongly doubt anyone can say was the simpler way of solving the problem). [0] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool

kragen 9y ago

Yeah, Ping, I agree. It reads like they missed the key lesson of C — in Dennis Ritchie's words, "A language that doesn't have everything is actually easier to program in than some that do." And some of the things they've added vitiate some of C's key advantages — exceptions complicate the control flow, constructors and destructors introduce the execution of hidden code (which can fail), and even static overloading makes it easy to make errors about what operations will be invoked by expressions like "x + y". An interesting exercise might be to figure out how to do the Golang feature set, or some useful subset of it, in a C-compatible or mostly-C-compatible syntax. I do like the returnable tuples, though, and the parametric polymorphism is pretty nice.

emilfihlman 9y ago

Exponentiation operator gratuitous and unnecessary? WHAT?

kragen 9y ago
It doesn't improve readability. Compare: discrim = b² - 4ac; // Standard notation float discrim = pow(b, 2) - 4*a*c; // C float discrim = b \ 2 - 4*a*c; // C∀ I would argue that these are presented here in descending order of readability. Also its typing rules are really complicated; apply it to two integers and magically you are thrown into the floating-point world where you can never be completely certain of anything, but if you use an unsigned exponent then you stay safely in integer-land.
- dom96 9y ago
  The choice of operator seems very odd to me. Wouldn't `^` be significantly more readable?
  - userbinator 9y ago
    ^ is already used for bitwise xor.
    - earenndil 9y ago
      What about then, like some other languages?
      - kbenson 9y ago
        > What about then, like some other languages? I assume there's a double asterisk there, and it's being eaten by the formatter?
        earenndil 9y ago
        Right yes. I forgot to escape, and now it's too late to.

dzdt 9y ago

I bike-shedded in this thread about exponentiation. But taking a step back the bigger issue is there are so many poorly justified features thrown in. I don't have the feeling that the authors appreciate the appeal of C as a simple language that maps closely to hardware features. This is a big random collections of extensions that piqued some implementor's fancy. There is seemingly no effort at narrowing down to the cleanest or most important ideas. It totally kills the clean, simple aesthetics of the the base C languge.