3 ms·

This can be a problem, but it is entirely a matter of library design. In most cases, I haven't found this to be a problem. It helps to follow certain convention

by tikhonj 14y ago

This can be a problem, but it is entirely a matter of library design. In most cases, I haven't found this to be a problem. It helps to follow certain conventions--for example, a name like <|> can be read as "a different version of |" (which represents alternation). I think it's still better than what you get with C++ and Python. I would much rather have a relatively inscrutable <+> operator that does something vaguely like addition than having + do multiple completely different things on different types. Also, for many of these operators, the clarity of having an infix version trumps the fact that you'd have to look it up. Take >>> as an example. Even if it was called something like next, you'd still have to read the Arrow documentation to understand exactly what it did (it's fairly abstract). And compare how the code would look: actionA >>> some complicated action >>> actionB next actionA (next (some complicated action) actionB) Ultimately, it is impossible to design a language that does not allow any bad code. I think having custom operators is better than the main alternatives (C++ and Java styles).

tehwalrus 14y ago
If compilers supported proper unicode as code not just in strings (like, I believe, Go does) then you could use A ⊗ B for outer products and A ⋅ B for inner products. (a quick google implies that Haskell supports this (http://www.haskell.org/haskellwiki/Unicode-symbols http://www.haskell.org/haskellwiki/Unicode-symbols). Good!)
- mercurial 14y ago
  You mean, Unicode symbols. Quite a few languages, including Java, support Unicode letters as identifiers. But frankly, I'd rather stay with cryptic :+: (see the answer to this question [1] for why) 1: http://stackoverflow.com/questions/2793792/is-it-a-good-idea-to-use-unicode-symbols-as-java-identifiers http://stackoverflow.com/questions/2793792/is-it-a-good-idea...
  - tehwalrus 14y ago
    Go has unicode symbols, but I meant just for operators. The reasons listed are important some of the time, but for example when you're a bunch of Chinese developers working on a project it seems sensible to use chinese identifiers in the code (especially if you all only have basic english.) In this situation, everyone is going to have a computer set up to use the character set, so the �� + �� situation shouldn't arise. In terms of confusing things at linking / runtime stage, I didn't think of that - maybe you're right! Go gets away with it by being completely compiled down to binary (and requiring the source of all the libraries locally, IIRC.)
    - mercurial 14y ago
      As a non-native English speaker, I can tell you it's a very bad idea to mix up a language with English keywords but identifiers in a different language. The disconnect between the two is awfully annoying, and the "native language identifiers" end up being a mix of English and native language anyway (I don't know how it is with Chinese but many language don't have useful equivalents to many IT terms, or they are so terrible that nobody wants to use them).
      - tehwalrus 14y ago
        Indeed - I can imagine, with so many english keywords everywhere. The code I've seen from developers who speak other languages tends to be in english, with comments in their language - frequent use of google translate to understand what's going on! :)
mercurial 14y ago
> I think it's still better than what you get with C++ and Python. I would much rather have a relatively inscrutable <+> operator that does something vaguely like addition than having + do multiple completely different things on different types. I can live with + as a concatenation operator for strings, but in general, if you're starting to implement custom operators for +, you should only do this for things which are numbers, and which can also support -, / and *. Wrt to Arrow, you could still have your custom operator but with a human-readable name: actionA >next> some complicated action >next> actionB or alternatively: actionA `next` some complicated action `next` actionB Sure, it's a bit more verbose, but it makes for more readable code (IMO). I think it's not so much the notion of custom operators I object to than the "let's get wild with non-AZERTY characters" philosophy. Of course, it doesn't mean that human-readable names are always better... I'm looking at you, "return".
lmm 14y ago
I'm wondering about a scala-like language that supports infix operators (i.e. allows one to write "object1 method object2" where Java would require "object1.method(object2)"), but requires all methods to be purely alphabetic, even e.g. "plus". I think writing BigInteger arithmetic as "(a plus b) times c" would still be fairly readable, and current scala goes too far in the other direction (e.g. the main scala HTTP library requires a "periodic table" to tell you which random two-special-character combination does what).

by tikhonj 14y ago

tehwalrus 14y ago

If compilers supported proper unicode as code not just in strings (like, I believe, Go does) then you could use A ⊗ B for outer products and A ⋅ B for inner products. (a quick google implies that Haskell supports this (http://www.haskell.org/haskellwiki/Unicode-symbols http://www.haskell.org/haskellwiki/Unicode-symbols). Good!)

mercurial 14y ago
You mean, Unicode symbols. Quite a few languages, including Java, support Unicode letters as identifiers. But frankly, I'd rather stay with cryptic :+: (see the answer to this question [1] for why) 1: http://stackoverflow.com/questions/2793792/is-it-a-good-idea-to-use-unicode-symbols-as-java-identifiers http://stackoverflow.com/questions/2793792/is-it-a-good-idea...
- tehwalrus 14y ago
  Go has unicode symbols, but I meant just for operators. The reasons listed are important some of the time, but for example when you're a bunch of Chinese developers working on a project it seems sensible to use chinese identifiers in the code (especially if you all only have basic english.) In this situation, everyone is going to have a computer set up to use the character set, so the �� + �� situation shouldn't arise. In terms of confusing things at linking / runtime stage, I didn't think of that - maybe you're right! Go gets away with it by being completely compiled down to binary (and requiring the source of all the libraries locally, IIRC.)
  - mercurial 14y ago
    As a non-native English speaker, I can tell you it's a very bad idea to mix up a language with English keywords but identifiers in a different language. The disconnect between the two is awfully annoying, and the "native language identifiers" end up being a mix of English and native language anyway (I don't know how it is with Chinese but many language don't have useful equivalents to many IT terms, or they are so terrible that nobody wants to use them).
    - tehwalrus 14y ago
      Indeed - I can imagine, with so many english keywords everywhere. The code I've seen from developers who speak other languages tends to be in english, with comments in their language - frequent use of google translate to understand what's going on! :)

mercurial 14y ago

> I think it's still better than what you get with C++ and Python. I would much rather have a relatively inscrutable <+> operator that does something vaguely like addition than having + do multiple completely different things on different types. I can live with + as a concatenation operator for strings, but in general, if you're starting to implement custom operators for +, you should only do this for things which are numbers, and which can also support -, / and *. Wrt to Arrow, you could still have your custom operator but with a human-readable name: actionA >next> some complicated action >next> actionB or alternatively: actionA `next` some complicated action `next` actionB Sure, it's a bit more verbose, but it makes for more readable code (IMO). I think it's not so much the notion of custom operators I object to than the "let's get wild with non-AZERTY characters" philosophy. Of course, it doesn't mean that human-readable names are always better... I'm looking at you, "return".

lmm 14y ago

I'm wondering about a scala-like language that supports infix operators (i.e. allows one to write "object1 method object2" where Java would require "object1.method(object2)"), but requires all methods to be purely alphabetic, even e.g. "plus". I think writing BigInteger arithmetic as "(a plus b) times c" would still be fairly readable, and current scala goes too far in the other direction (e.g. the main scala HTTP library requires a "periodic table" to tell you which random two-special-character combination does what).