4 ms·

> C is sort of a dead end. There is very little innovation there. C is a small language. There are benefits to that. But it also has a handful of historical od

> C is sort of a dead end. There is very little innovation there. C is a small language. There are benefits to that. But it also has a handful of historical oddities. Innovation here means to keep C small while also getting rid of those quirks. C++ is enormous. Rust is headed in the direction of similar enormity.

stormbrew 4y ago
> C++ is enormous. Rust is headed in the direction of similar enormity I don't think this is a fair characterization of rust really. For the most part the things on the horizon still for rust seek to reduce complexity by filing down sharp edges that force you to write complicated code. Stuff like GATs seem complicated until you repeatedly slam your head into the lack of them trying to do things that "seem" natural. C++ on the other hand (after 2011) just never saw an idiom it didn't like enough to throw on the pile and there's little coherence to the way the language has grown in the last decade.
- smingo 4y ago
  > there's little coherence to the way the language has grown in the last decade. IMHO it's been incoherent from the earliest times. The lame exceptions without 'finally', and no consistency in exception types. Then the desperate attempts to make all resources into objects, except that practically no OS calls bothered with this. The overloading of the shift operators in the standard library. Indeed, operator overloading itself is just a recipe for abuse. You read 'a=b+c' and you literally have no clue what that means. Multiple inheritance with the brittle semantics. The awful STL, with its multi-kB error messages (the allocator of the trait of the string of the tree of map of king Caractacus doesn't match ...) There's no wonder the 'obfuscated C competition' never happened with C++ given the fact it's unreadable, right out of the box.
  - labrador 4y ago
    I was jokingly thinking C++ needs Douglas Crockford to write "C++: The Good Parts" but of course a quick search reveals there already is one https://www.amazon.com/C-Good-Parts-Gregory-Satir/dp/1449319696 https://www.amazon.com/C-Good-Parts-Gregory-Satir/dp/1449319...
  - stkdump 4y ago
    > You read 'a=b+c' and you literally have no clue what that means. I never understood that argument. Even in C operators do different things depending on what types you pass it. Two very simple examples: 1. Adding a number to a char* vs adding a number to an int* (or a pointer to any other larger type). The second automatically creates an invisible multiplication. This was confusing for me when I first learned C after already knowing the concept of a memory address (which is just a number). It was an unexpected abstraction for me. 2. This regularly bites novices to programming: Dividing two numbers. If at least one of them is floating point, you get the 'correct' result, overwise rounded towards zero. To 'fix' it, you have to explicitly cast at least one of them to float or double. Then the language imlpicitly casts the other for you. std::pow went the other way, which is less confusing. It always promotes integers to floating point numbers and returns a floating point result. As soon as your language has types and operators, you get operators that do different things based on the types of the values they are applied to. The only new thing that operator overloading adds is that it makes libraries first class citizens.
    - scoutt 4y ago
      The difference is that you know (or can know, or predict) the outcome. In C++ a=b+c could be a simple addition or an operation that takes an hour, allocates 1GB of RAM, opens a socket and requests a JSON document from a server in China. You can't know wihtout looking at the code.
      - mh7 4y ago
        You don't know what the function called "add" does either. There's no reason for the name "+" to be anymore special than "add" - especially in any language supporting unicode identifiers which allows even more crazy names.
        scoutt 4y ago
        But with "add" I'm explicitly calling a function. > There's no reason for the name "+" to be anymore special than "add" This is debatable. I want "+" to do just an addition. Also a function "add", depending on the context, can mean different things.
jonathankoren 4y ago
C++ is a monsterous cruel joke compared C, but if you’re just looking for some syntactic niceties, nothing stops you from writing C in C++.
- JonChesterfield 4y ago
  C++ -ffreestanding is remarkably usable without the standard library, provided compiler intrinsics are used to fill in some gaps. I'm slowly coming around to using that instead of C for language runtimes.
kaba0 4y ago
C is a small language which fails even at the most basic abstractions (you can’t really create a safe and ergonomic “zero-overhead” generic vector type). Due to the inherent complexity of low-level programming, expressive languages in this niche (C++, Rust) has to be reasonably complex just for this reason alone. Zig is an interesting “exception” due to its strong compile-time metaprogramming capabilites, resulting in a small, but quite expressive language. But all 3 has a future. C is here to stay, but I really wouldn’t start any new project in it.

stormbrew 4y ago

> C++ is enormous. Rust is headed in the direction of similar enormity I don't think this is a fair characterization of rust really. For the most part the things on the horizon still for rust seek to reduce complexity by filing down sharp edges that force you to write complicated code. Stuff like GATs seem complicated until you repeatedly slam your head into the lack of them trying to do things that "seem" natural. C++ on the other hand (after 2011) just never saw an idiom it didn't like enough to throw on the pile and there's little coherence to the way the language has grown in the last decade.

smingo 4y ago
> there's little coherence to the way the language has grown in the last decade. IMHO it's been incoherent from the earliest times. The lame exceptions without 'finally', and no consistency in exception types. Then the desperate attempts to make all resources into objects, except that practically no OS calls bothered with this. The overloading of the shift operators in the standard library. Indeed, operator overloading itself is just a recipe for abuse. You read 'a=b+c' and you literally have no clue what that means. Multiple inheritance with the brittle semantics. The awful STL, with its multi-kB error messages (the allocator of the trait of the string of the tree of map of king Caractacus doesn't match ...) There's no wonder the 'obfuscated C competition' never happened with C++ given the fact it's unreadable, right out of the box.
- labrador 4y ago
  I was jokingly thinking C++ needs Douglas Crockford to write "C++: The Good Parts" but of course a quick search reveals there already is one https://www.amazon.com/C-Good-Parts-Gregory-Satir/dp/1449319696 https://www.amazon.com/C-Good-Parts-Gregory-Satir/dp/1449319...
- stkdump 4y ago
  > You read 'a=b+c' and you literally have no clue what that means. I never understood that argument. Even in C operators do different things depending on what types you pass it. Two very simple examples: 1. Adding a number to a char* vs adding a number to an int* (or a pointer to any other larger type). The second automatically creates an invisible multiplication. This was confusing for me when I first learned C after already knowing the concept of a memory address (which is just a number). It was an unexpected abstraction for me. 2. This regularly bites novices to programming: Dividing two numbers. If at least one of them is floating point, you get the 'correct' result, overwise rounded towards zero. To 'fix' it, you have to explicitly cast at least one of them to float or double. Then the language imlpicitly casts the other for you. std::pow went the other way, which is less confusing. It always promotes integers to floating point numbers and returns a floating point result. As soon as your language has types and operators, you get operators that do different things based on the types of the values they are applied to. The only new thing that operator overloading adds is that it makes libraries first class citizens.
  - scoutt 4y ago
    The difference is that you know (or can know, or predict) the outcome. In C++ a=b+c could be a simple addition or an operation that takes an hour, allocates 1GB of RAM, opens a socket and requests a JSON document from a server in China. You can't know wihtout looking at the code.
    - mh7 4y ago
      You don't know what the function called "add" does either. There's no reason for the name "+" to be anymore special than "add" - especially in any language supporting unicode identifiers which allows even more crazy names.
      - scoutt 4y ago
        But with "add" I'm explicitly calling a function. > There's no reason for the name "+" to be anymore special than "add" This is debatable. I want "+" to do just an addition. Also a function "add", depending on the context, can mean different things.

jonathankoren 4y ago

C++ is a monsterous cruel joke compared C, but if you’re just looking for some syntactic niceties, nothing stops you from writing C in C++.

JonChesterfield 4y ago
C++ -ffreestanding is remarkably usable without the standard library, provided compiler intrinsics are used to fill in some gaps. I'm slowly coming around to using that instead of C for language runtimes.

kaba0 4y ago

C is a small language which fails even at the most basic abstractions (you can’t really create a safe and ergonomic “zero-overhead” generic vector type). Due to the inherent complexity of low-level programming, expressive languages in this niche (C++, Rust) has to be reasonably complex just for this reason alone. Zig is an interesting “exception” due to its strong compile-time metaprogramming capabilites, resulting in a small, but quite expressive language. But all 3 has a future. C is here to stay, but I really wouldn’t start any new project in it.