Scala isn’t complicated; it’s clever(cemerick.com)
cemerick.com
Scala isn’t complicated; it’s clever
http://cemerick.com/2011/07/14/scala-isnt-complicated-its-clever/
9 comments
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/554bb3eb293fe083dcc4fd...
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/554bb3eb293fe083dcc4fd...
I don't understand the concern about typing non-ASCII Unicode characters on a Windows box. I know of at least 3 easy ways: charmap, alt+numpad, and editor-specific support.
"Will contributions to Akka that use ASCII arrows now be rejected?"
I guess that this will be solved and has been solved in that commit with a formatting tool, but for me the answer to your last question is definitely "no", putting unicode arrow "aliases" in the language is a completely useless cosmetic feature.
How many programmer will type a unicode arrow manually? Is this really necessary? I'm generally against adding purely cosmetic feature like this one, if it does not improve the language in a clear and tangible way, just leave it out.
I guess that this will be solved and has been solved in that commit with a formatting tool, but for me the answer to your last question is definitely "no", putting unicode arrow "aliases" in the language is a completely useless cosmetic feature.
How many programmer will type a unicode arrow manually? Is this really necessary? I'm generally against adding purely cosmetic feature like this one, if it does not improve the language in a clear and tangible way, just leave it out.
Code redability is more importand that saving a keystroke, and code that looks less ugly is easier to read. You should view the ascii replacements like => like you view the trigraph replacements C allows you to write if you editor or terminal don't allow exotic characters like {.
Code that is difficult to write is difficult to rewrite. I'm not sure I know how I'd type a unicode back-arrow without menuing through a character map or copying and pasting it from somewhere.
The formatting tool in question defaults to _not_ doing this, specifically to comply with the Scala Style Guide which does _not_ do this. The tool had to be explicitly configured to make this unfortunate change.
I think you're getting caught up in the specific example he's chosen to illustrate his perspective. You're being too literal; perhaps even too "clever", in the way the article means it.
The frame, as I see it, for his post is the idea that Scala is too complicated. He sees things differently; that instead, "Scala is clever". The line out of Fight Club comes to mind: how's that working out for you - being clever?
The use of using technical Unicode characters for operators - technical characters that are unlikely to appear on any keyboard anywhere outside of very niche uses, e.g. APL-specific terminals - isn't terribly practical. But I imagine it gives someone somewhere a warm fuzzy feeling of correctness. This is the idea and meaning of cleverness that I think he's after.
This cleverness doesn't apply to things like e.g. Chinese characters for identifiers, because that does have extremely practical uses, not least because there are keyboard layouts and IMEs etc. in common use that permit it, and it may be culturally appropriate etc.
The frame, as I see it, for his post is the idea that Scala is too complicated. He sees things differently; that instead, "Scala is clever". The line out of Fight Club comes to mind: how's that working out for you - being clever?
The use of using technical Unicode characters for operators - technical characters that are unlikely to appear on any keyboard anywhere outside of very niche uses, e.g. APL-specific terminals - isn't terribly practical. But I imagine it gives someone somewhere a warm fuzzy feeling of correctness. This is the idea and meaning of cleverness that I think he's after.
This cleverness doesn't apply to things like e.g. Chinese characters for identifiers, because that does have extremely practical uses, not least because there are keyboard layouts and IMEs etc. in common use that permit it, and it may be culturally appropriate etc.
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.
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.
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]
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.
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 <- ?
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 <- ?
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://perl6advent.wordpress.com/2009/12/05/day-5-metaoperat...
* http://perl6advent.wordpress.com/2009/12/06/day-6-going-into...
Some refs:
* http://perl6.wikia.com/wiki/Hyper_operator
* http://perl6advent.wordpress.com/2009/12/05/day-5-metaoperat...
* http://perl6advent.wordpress.com/2009/12/06/day-6-going-into...
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.
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.
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.
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...
[2] https://bitbucket.org/dnene/scalaz-guide/src/5fbe1cd253f3/un...
[1] http://scala-programming-language.1934581.n4.nabble.com/More...
[2] https://bitbucket.org/dnene/scalaz-guide/src/5fbe1cd253f3/un...
It's 2011. If your editor or coding tool doesn't read Unicode, it's broken.
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.
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/synta... seems to back this up.
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.
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.