5 ms·

Scala isn’t complicated; it’s clever

36 points by fogus 15y ago

jvictor 15y ago
Maybe I'm a numbskull.. I found Scala pretty complex :) Just could not get to complete the 6th chapter of the staircase book... I've kind of given up on Scala.
skrebbel 15y ago
I think it's a bit of a non-issue. It's really about time we get IDEs that allow us to hands-on manipulate the AST of a language, rather than edit text. In such an idea, displaying the <- operator like ← is just a GUI issue. That said, given that Scala doesn't have operators at all (just infix methods that are named with a series of symbol characters), isn't ← just implemented as an alias to <- ?
- trurl 15y ago
  No, in the case of 'for', <- and ← are syntax.
  - skrebbel 15y ago
    Argh, dah. Forgot that :)
- kruhft 15y ago
  > It's really about time we get IDEs that allow us to hands-on manipulate the AST of a language, rather than edit text. Sounds like Lisp to me.
gjm11 15y ago
I totally don't understand his argument. He doesn't object to allowing arbitrary Unicode characters in identifiers, because that's something programmers can opt in to. But he objects to allowing arbitrary Unicode characters as alternatives to notations like "<-" and ">=", because that's "for everyone". Huh? If you're writing your own code, you can use or not use these as you please (just as you can use or not use exotic characters in identifiers). If you're working with code someone else has written, you may have to put up with their use of exotic characters for operators like <- (just as you may have to put up with their use of exotic characters in identifiers). He says that "various potential problems [were] pointed out, and presumably ignored" in an issue-tracker ticket that suggested adding one of these things; but all the potential problems I see there apply equally to allowing arbitrary characters in identifiers, which he's happy with. What's the difference here? Perhaps I'm misunderstanding and the objection is simply "I don't like this; it's clever". But then the author owes us an explanation of why this is any more true for <- than for identifier names.
- daniel_solano 15y ago
  I think his argument is that if you wish to create a variable called ©, that's up to you. For some reason, he objects to the language/standard library allowing ← in addition to `<-`. I think I would definitely object to `<-` to be replaced by ←. It's inconvenient to type. On the other hand, as an alias, I am not sure what to make of it.
  - benblack 15y ago
    You've got it backwards: I haven't seen anyone, including Chas, argue for disallowing Unicode. As you say, replacing a simple, common, 2 character operator with the unusual Unicode version is an odd and inconvenient decision. At present, this is Akka-specific, though the line between Scala and Akka seems to be blurring like Erlang and OTP.
    - deleted 15y ago
      [deleted]
- acqq 15y ago
  As far as I can see, there's no problem at all, except if he wanted to make an identifier which contained ←. And now if you want to parse Scala code yourself you have to add these characters too and be Unicode-aware. I don't see that as a bad thing. And I like how such codes look when printed.
- cemerick 15y ago
  Author here. Even in languages that allow for them, Unicode chars in identifiers are rarely used. They carry some costs that may matter a great deal: they can make certain tools unusable with a given codebase, they can act as hurdles to contributors, and they can act as hurdles for users of libraries ("what the hell is ε?!", etc). However, if you know your audience, and know your contributors, and generally know what you're doing, have at it. All those same costs apply if you're using Unicode characters as part of your language's syntax, and the user confusion issue is exacerbated if the characters are entirely equivalents to other bits of syntax that approximate what the Unicode chars may encode precisely. For example: at least some parts of Akka switched over to using Unicode arrows instead of the ASCII approximations[1]. Will contributions to Akka that use ASCII arrows now be rejected? How many times will Akka leads have to point surprised potential new contributors to whatever part of the Scala spec allows for Unicode arrows? God help the poor soul that would like to do some Akka hacking on a Windows box. Etc. All this is worth the slight prettification? Presumably, the answer is "yes". As I said, we can all make our own judgments. [1] https://github.com/jboner/akka/commit/554bb3eb293fe083dcc4fd0fcb8e0b23bd566e5b#L5L82 https://github.com/jboner/akka/commit/554bb3eb293fe083dcc4fd...
draegtun 15y ago
Perl6 also has (some) operators with unicode aliases. One example I know is the Hyperoperator which along with using << or >> you can also use « or » Some refs: * http://perl6.wikia.com/wiki/Hyper_operator http://perl6.wikia.com/wiki/Hyper_operator * http://perl6advent.wordpress.com/2009/12/05/day-5-metaoperator/ http://perl6advent.wordpress.com/2009/12/05/day-5-metaoperat... * http://perl6advent.wordpress.com/2009/12/06/day-6-going-into-hyperspace/ http://perl6advent.wordpress.com/2009/12/06/day-6-going-into...
- chalst 15y ago
  Likewise, Fortress. 1. http://projectfortress.sun.com/Projects/Community/wiki/MathSyntaxInFortress http://projectfortress.sun.com/Projects/Community/wiki/MathS... 2. https://projectfortress.sun.com/svn/Community/trunk/.../ascii-to-unicode.tex https://projectfortress.sun.com/svn/Community/trunk/.../asci...
PaulHoule 15y ago
For one thing, you can't count on all programmer's editors (and other parts of your toolchain) to properly handle Unicode characters. Many languages and libraries (PG's arc, for instance) don't have formal support for Unicode, and if you're using a language that "supports" Unicode (Java, C#) odds are that often you'll have the wrong character encoding for input or output. If you're interested in having things "just work" (not have your source code wrecked when somebody else edits it) you're better off avoiding characters outside US-ASCII.
gtani 15y ago
The unicode "operators" were introduced a while back ([1] Dec 09) and (I believe) are almost never seen in code outside scalaz [2] [1] http://scala-programming-language.1934581.n4.nabble.com/More-unicode-alternatives-for-ASCII-operators-td2008146.html http://scala-programming-language.1934581.n4.nabble.com/More... [2] https://bitbucket.org/dnene/scalaz-guide/src/5fbe1cd253f3/unicode-mappings.rst https://bitbucket.org/dnene/scalaz-guide/src/5fbe1cd253f3/un...
neilk 15y ago
It's 2011. If your editor or coding tool doesn't read Unicode, it's broken.
narrator 15y ago
Scala designers: Please don't put unicode operators into the language. APL and every other language that tried that failed miserably. There's a point at which code compactness yields diminishing marginal returns.
MostAwesomeDude 15y ago
If I remember correctly, Haskell's argument for these was that it improved the accuracy of source code by letting the correct mathematical symbols be used for the concepts expressed in syntax; the list at http://www.haskell.org/ghc/docs/7.0.2/html/users_guide/syntax-extns.html http://www.haskell.org/ghc/docs/7.0.2/html/users_guide/synta... seems to back this up.
- cemerick 15y ago
  It's notable that (per the link you provided) Haskell doesn't allow for the Unicode alternatives without specifying an option (-XUnicodeSyntax). It's an interesting approach, and seems like a reasonable middle ground that probably limits the use of Unicode syntax to those few teams/libraries/domains where its tradeoffs are understood and accepted.

36 points by fogus 15y ago

Maybe I'm a numbskull.. I found Scala pretty complex :) Just could not get to complete the 6th chapter of the staircase book... I've kind of given up on Scala.

skrebbel 15y ago

I think it's a bit of a non-issue. It's really about time we get IDEs that allow us to hands-on manipulate the AST of a language, rather than edit text. In such an idea, displaying the <- operator like ← is just a GUI issue. That said, given that Scala doesn't have operators at all (just infix methods that are named with a series of symbol characters), isn't ← just implemented as an alias to <- ?

trurl 15y ago
No, in the case of 'for', <- and ← are syntax.
- skrebbel 15y ago
  Argh, dah. Forgot that :)
kruhft 15y ago
> It's really about time we get IDEs that allow us to hands-on manipulate the AST of a language, rather than edit text. Sounds like Lisp to me.

gjm11 15y ago

I totally don't understand his argument. He doesn't object to allowing arbitrary Unicode characters in identifiers, because that's something programmers can opt in to. But he objects to allowing arbitrary Unicode characters as alternatives to notations like "<-" and ">=", because that's "for everyone". Huh? If you're writing your own code, you can use or not use these as you please (just as you can use or not use exotic characters in identifiers). If you're working with code someone else has written, you may have to put up with their use of exotic characters for operators like <- (just as you may have to put up with their use of exotic characters in identifiers). He says that "various potential problems [were] pointed out, and presumably ignored" in an issue-tracker ticket that suggested adding one of these things; but all the potential problems I see there apply equally to allowing arbitrary characters in identifiers, which he's happy with. What's the difference here? Perhaps I'm misunderstanding and the objection is simply "I don't like this; it's clever". But then the author owes us an explanation of why this is any more true for <- than for identifier names.

daniel_solano 15y ago
I think his argument is that if you wish to create a variable called ©, that's up to you. For some reason, he objects to the language/standard library allowing ← in addition to `<-`. I think I would definitely object to `<-` to be replaced by ←. It's inconvenient to type. On the other hand, as an alias, I am not sure what to make of it.
- benblack 15y ago
  You've got it backwards: I haven't seen anyone, including Chas, argue for disallowing Unicode. As you say, replacing a simple, common, 2 character operator with the unusual Unicode version is an odd and inconvenient decision. At present, this is Akka-specific, though the line between Scala and Akka seems to be blurring like Erlang and OTP.
  - deleted 15y ago
    [deleted]
acqq 15y ago
As far as I can see, there's no problem at all, except if he wanted to make an identifier which contained ←. And now if you want to parse Scala code yourself you have to add these characters too and be Unicode-aware. I don't see that as a bad thing. And I like how such codes look when printed.
cemerick 15y ago
Author here. Even in languages that allow for them, Unicode chars in identifiers are rarely used. They carry some costs that may matter a great deal: they can make certain tools unusable with a given codebase, they can act as hurdles to contributors, and they can act as hurdles for users of libraries ("what the hell is ε?!", etc). However, if you know your audience, and know your contributors, and generally know what you're doing, have at it. All those same costs apply if you're using Unicode characters as part of your language's syntax, and the user confusion issue is exacerbated if the characters are entirely equivalents to other bits of syntax that approximate what the Unicode chars may encode precisely. For example: at least some parts of Akka switched over to using Unicode arrows instead of the ASCII approximations[1]. Will contributions to Akka that use ASCII arrows now be rejected? How many times will Akka leads have to point surprised potential new contributors to whatever part of the Scala spec allows for Unicode arrows? God help the poor soul that would like to do some Akka hacking on a Windows box. Etc. All this is worth the slight prettification? Presumably, the answer is "yes". As I said, we can all make our own judgments. [1] https://github.com/jboner/akka/commit/554bb3eb293fe083dcc4fd0fcb8e0b23bd566e5b#L5L82 https://github.com/jboner/akka/commit/554bb3eb293fe083dcc4fd...

draegtun 15y ago

Perl6 also has (some) operators with unicode aliases. One example I know is the Hyperoperator which along with using << or >> you can also use « or » Some refs: * http://perl6.wikia.com/wiki/Hyper_operator http://perl6.wikia.com/wiki/Hyper_operator * http://perl6advent.wordpress.com/2009/12/05/day-5-metaoperator/ http://perl6advent.wordpress.com/2009/12/05/day-5-metaoperat... * http://perl6advent.wordpress.com/2009/12/06/day-6-going-into-hyperspace/ http://perl6advent.wordpress.com/2009/12/06/day-6-going-into...

chalst 15y ago
Likewise, Fortress. 1. http://projectfortress.sun.com/Projects/Community/wiki/MathSyntaxInFortress http://projectfortress.sun.com/Projects/Community/wiki/MathS... 2. https://projectfortress.sun.com/svn/Community/trunk/.../ascii-to-unicode.tex https://projectfortress.sun.com/svn/Community/trunk/.../asci...

PaulHoule 15y ago

For one thing, you can't count on all programmer's editors (and other parts of your toolchain) to properly handle Unicode characters. Many languages and libraries (PG's arc, for instance) don't have formal support for Unicode, and if you're using a language that "supports" Unicode (Java, C#) odds are that often you'll have the wrong character encoding for input or output. If you're interested in having things "just work" (not have your source code wrecked when somebody else edits it) you're better off avoiding characters outside US-ASCII.

gtani 15y ago

The unicode "operators" were introduced a while back ([1] Dec 09) and (I believe) are almost never seen in code outside scalaz [2] [1] http://scala-programming-language.1934581.n4.nabble.com/More-unicode-alternatives-for-ASCII-operators-td2008146.html http://scala-programming-language.1934581.n4.nabble.com/More... [2] https://bitbucket.org/dnene/scalaz-guide/src/5fbe1cd253f3/unicode-mappings.rst https://bitbucket.org/dnene/scalaz-guide/src/5fbe1cd253f3/un...

neilk 15y ago

It's 2011. If your editor or coding tool doesn't read Unicode, it's broken.

narrator 15y ago

Scala designers: Please don't put unicode operators into the language. APL and every other language that tried that failed miserably. There's a point at which code compactness yields diminishing marginal returns.

MostAwesomeDude 15y ago

If I remember correctly, Haskell's argument for these was that it improved the accuracy of source code by letting the correct mathematical symbols be used for the concepts expressed in syntax; the list at http://www.haskell.org/ghc/docs/7.0.2/html/users_guide/syntax-extns.html http://www.haskell.org/ghc/docs/7.0.2/html/users_guide/synta... seems to back this up.

cemerick 15y ago
It's notable that (per the link you provided) Haskell doesn't allow for the Unicode alternatives without specifying an option (-XUnicodeSyntax). It's an interesting approach, and seems like a reasonable middle ground that probably limits the use of Unicode syntax to those few teams/libraries/domains where its tradeoffs are understood and accepted.