11 ms·

> 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 withou

by 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.
      - stkdump 4y ago
        See, framing it as a personal preference makes much more sense. Of course disallowing nontrivial work in operators will also mean you can't concatenate strings in them, so you will have few languages to choose from.
        scoutt 4y ago
        Sorry. I don't know if you are saying that you won't be able to concatenate strings without operators, or if you choose a language just because it allows you to use a "a = b + c" form with strings. For the first case, of course you can create something like: str1.append(str2); For the second... I don't know what to say. > framing it as a personal preference But follow my logic for a moment: if "str3 = str1 + str2" concatenates a string, what "str3 = str1 - str2" should do? (Yes I know there is no minus operator for std::string) And "str3 = str1 * str2"? And "str3 = str1 % str2"?

by smingo 4y ago

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.
    - stkdump 4y ago
      See, framing it as a personal preference makes much more sense. Of course disallowing nontrivial work in operators will also mean you can't concatenate strings in them, so you will have few languages to choose from.
      - scoutt 4y ago
        Sorry. I don't know if you are saying that you won't be able to concatenate strings without operators, or if you choose a language just because it allows you to use a "a = b + c" form with strings. For the first case, of course you can create something like: str1.append(str2); For the second... I don't know what to say. > framing it as a personal preference But follow my logic for a moment: if "str3 = str1 + str2" concatenates a string, what "str3 = str1 - str2" should do? (Yes I know there is no minus operator for std::string) And "str3 = str1 * str2"? And "str3 = str1 % str2"?