8 ms·

It seems there's a weird fetish in C++ land where non-letter characters seem more "pure" than words. I remember suffering from it myself, implementing atrocitie

It seems there's a weird fetish in C++ land where non-letter characters seem more "pure" than words. I remember suffering from it myself, implementing atrocities like a subtraction opeartor on a path class which would give you the relative path between two paths. It made me feel very clever but I feel sorry for anyone who would have to look at my code now and try to figure out what the hell was going on.

Sharlin 8y ago
Often the reason is not wanting to introduce new keywords for backwards compatibility reasons. And when keywords are introduced, often they have to be awkward (like `co_await`) to minimize conflicts with existing code. Context-sensitive keywords are one solution but can make parsing even more complicated in places where arbitrary lookahead might be needed.
- stochastic_monk 8y ago
  That’s also why the sizeof... operator was chosen. It’s an abuse of notation, because it returns a count of elements rather than the sum of sizeof applied to each, but ... and sizeof were already reserved.
deleted 8y ago
[deleted]
pjmlp 8y ago
C++ land is actually quite conservative. You should try Lisp, ML, Haskell Julia lands regarding that matter. Developers with math background on languages with symbols as identifiers can get quite creative.
- lallysingh 8y ago
  At least with Haskell (I can't speak for the others), you don't redefine existing operators, you add new ones. Which is less confusing in some ways
  - pjmlp 8y ago
    Is it really less confusing that + for numbers has another meaning that + for a newtype that implements Num?
    - hood_syntax 8y ago
      I think so, since you can also count on that type to implement the other required methods of Num.
      - pjmlp 8y ago
        There is no way to enforce that + actually implements the concept of adding two values.
        hood_syntax 8y ago
        With dependent types you can. I'm not aware of whether that proof is possible in Haskell, however. Besides, that's not what I was saying. What I was saying it that + in Haskell means more than an overloaded operator. It means the type has access to additional methods. This gives you more information.
        pjmlp 8y ago
        In that case you get the same information on any usable C++ IDE.
      - nybble41 8y ago
        Right, the fact that functions and operators must be part of a typeclass to be overloaded makes a huge difference. Sure, you can define your Num instance however you want—but that doesn't change the fact that by providing a Num instance you're asserting that the type is "number-like". The typeclass also enforces certain restrictions, such as the fact that the arguments and return value of (+) must all be the same type, which helps curtail the more egregious abuses like the repurposing of the C++ bit-shift operator for stream I/O. And since the set of possible operators is so much larger (almost any sequence of Unicode symbols) there isn't a great deal of pressure to abuse the existing notation. In C++ you can only override the limited set of built-in operators, even if the concept you're trying to express isn't closely related to any of them. It helps that Haskell operators are namespaced just like functions, so you can choose which operators to bring into scope from other modules.
pcwalton 8y ago
It's because defining "customization points" as operators make it easier to write templates, essentially. See "C++ doesn’t know how to do customization points that aren’t operators": https://quuxplusone.github.io/blog/2018/08/23/customization-point-or-named-function-pick-one/ https://quuxplusone.github.io/blog/2018/08/23/customization-... This is one of the downsides of not having typeclasses that is often forgotten about.
- cheez 8y ago
  That's why I cannot wait for concepts
- aaaaaaaaaab 8y ago
  Wouldn’t uniform call syntax (like in D) solve most of the issues outlined above? I.e. it always boils down to “primitive types can’t have methods”; but uniform call syntax would let us call any function like a method on its first argument...
  - pcwalton 8y ago
    Or just allow methods to be defined on primitive types, like Rust.
    - aaaaaaaaaab 8y ago
      Uniform call syntax is a superset of that, since you can’t have virtual methods on primitive types.
Aardwolf 8y ago
It's weird how opposite the core language and the std library of C++ are, and even more so in the recent revisions! The core language seems to go for being as code-golfy as possible, while the std library goes for super-verbose without any convenient shortcuts The core language adds ascii character notations optimized for brevity. The library instead makes things that should require 1 argument take 2 or 3 arguments (which ranges will hopefully fix), makes value to string conversions as verbose as possible, etc...
- bluGill 8y ago
  The core language is much harder to work with than the library, thus the difference. The library can be posted as code and thus we can test it thoroughly, and discuss it based on a real implementation. Contrast that to the language. It isn't code, it is standardize. It is written by and for lawyers in the negative sense of the word lawyers. Anything you do in the core language is hard because there are too many ways to accidentally (or intentionally) slip something evil past everybody. C++ takes backward compatibility seriously. If I didn't have a 20 year old code base of working code to deal with I'd be working in Rust, D, Go, Java, C#, or whatever the language of the day is. (Note that because of the amount of users and time C++ often has better optimization, but if that fraction of a percent better matters you can invest in optimizer work for your chosen language and solve the problem)
Waterluvian 8y ago
That's pretty idiomatic in Python and often is fine. But surely can be abused. Pathlib let's you use / to append paths. You're not dividing anything but it's still quite intuitive. And python sets let you subtract to get a difference, similar to your clever trick. I think it helps when these things are core to the language and broadly known. Otherwise you're scratching your head at what - will do.

Sharlin 8y ago

Often the reason is not wanting to introduce new keywords for backwards compatibility reasons. And when keywords are introduced, often they have to be awkward (like `co_await`) to minimize conflicts with existing code. Context-sensitive keywords are one solution but can make parsing even more complicated in places where arbitrary lookahead might be needed.

stochastic_monk 8y ago
That’s also why the sizeof... operator was chosen. It’s an abuse of notation, because it returns a count of elements rather than the sum of sizeof applied to each, but ... and sizeof were already reserved.

deleted 8y ago

[deleted]

pjmlp 8y ago

C++ land is actually quite conservative. You should try Lisp, ML, Haskell Julia lands regarding that matter. Developers with math background on languages with symbols as identifiers can get quite creative.

lallysingh 8y ago
At least with Haskell (I can't speak for the others), you don't redefine existing operators, you add new ones. Which is less confusing in some ways
- pjmlp 8y ago
  Is it really less confusing that + for numbers has another meaning that + for a newtype that implements Num?
  - hood_syntax 8y ago
    I think so, since you can also count on that type to implement the other required methods of Num.
    - pjmlp 8y ago
      There is no way to enforce that + actually implements the concept of adding two values.
      - hood_syntax 8y ago
        With dependent types you can. I'm not aware of whether that proof is possible in Haskell, however. Besides, that's not what I was saying. What I was saying it that + in Haskell means more than an overloaded operator. It means the type has access to additional methods. This gives you more information.
        pjmlp 8y ago
        In that case you get the same information on any usable C++ IDE.
    - nybble41 8y ago
      Right, the fact that functions and operators must be part of a typeclass to be overloaded makes a huge difference. Sure, you can define your Num instance however you want—but that doesn't change the fact that by providing a Num instance you're asserting that the type is "number-like". The typeclass also enforces certain restrictions, such as the fact that the arguments and return value of (+) must all be the same type, which helps curtail the more egregious abuses like the repurposing of the C++ bit-shift operator for stream I/O. And since the set of possible operators is so much larger (almost any sequence of Unicode symbols) there isn't a great deal of pressure to abuse the existing notation. In C++ you can only override the limited set of built-in operators, even if the concept you're trying to express isn't closely related to any of them. It helps that Haskell operators are namespaced just like functions, so you can choose which operators to bring into scope from other modules.

pcwalton 8y ago

It's because defining "customization points" as operators make it easier to write templates, essentially. See "C++ doesn’t know how to do customization points that aren’t operators": https://quuxplusone.github.io/blog/2018/08/23/customization-point-or-named-function-pick-one/ https://quuxplusone.github.io/blog/2018/08/23/customization-... This is one of the downsides of not having typeclasses that is often forgotten about.

cheez 8y ago
That's why I cannot wait for concepts
aaaaaaaaaab 8y ago
Wouldn’t uniform call syntax (like in D) solve most of the issues outlined above? I.e. it always boils down to “primitive types can’t have methods”; but uniform call syntax would let us call any function like a method on its first argument...
- pcwalton 8y ago
  Or just allow methods to be defined on primitive types, like Rust.
  - aaaaaaaaaab 8y ago
    Uniform call syntax is a superset of that, since you can’t have virtual methods on primitive types.

Aardwolf 8y ago

It's weird how opposite the core language and the std library of C++ are, and even more so in the recent revisions! The core language seems to go for being as code-golfy as possible, while the std library goes for super-verbose without any convenient shortcuts The core language adds ascii character notations optimized for brevity. The library instead makes things that should require 1 argument take 2 or 3 arguments (which ranges will hopefully fix), makes value to string conversions as verbose as possible, etc...

bluGill 8y ago
The core language is much harder to work with than the library, thus the difference. The library can be posted as code and thus we can test it thoroughly, and discuss it based on a real implementation. Contrast that to the language. It isn't code, it is standardize. It is written by and for lawyers in the negative sense of the word lawyers. Anything you do in the core language is hard because there are too many ways to accidentally (or intentionally) slip something evil past everybody. C++ takes backward compatibility seriously. If I didn't have a 20 year old code base of working code to deal with I'd be working in Rust, D, Go, Java, C#, or whatever the language of the day is. (Note that because of the amount of users and time C++ often has better optimization, but if that fraction of a percent better matters you can invest in optimizer work for your chosen language and solve the problem)

Waterluvian 8y ago

That's pretty idiomatic in Python and often is fine. But surely can be abused. Pathlib let's you use / to append paths. You're not dividing anything but it's still quite intuitive. And python sets let you subtract to get a difference, similar to your clever trick. I think it helps when these things are core to the language and broadly known. Otherwise you're scratching your head at what - will do.