
Scala isn’t complicated; it’s clever - fogus
http://cemerick.com/2011/07/14/scala-isnt-complicated-its-clever/
======
gjm11
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.

~~~
cemerick
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...](https://github.com/jboner/akka/commit/554bb3eb293fe083dcc4fd0fcb8e0b23bd566e5b#L5L82)

~~~
drtse4
"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.

~~~
fhars
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 {.

~~~
regularfry
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.

------
skrebbel
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
No, in the case of 'for', <\- and ← are syntax.

~~~
skrebbel
Argh, dah. Forgot that :)

------
draegtun
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/05/day-5-metaoperator/)

* [http://perl6advent.wordpress.com/2009/12/06/day-6-going-into...](http://perl6advent.wordpress.com/2009/12/06/day-6-going-into-hyperspace/)

~~~
chalst
Likewise, Fortress.

1\.
[http://projectfortress.sun.com/Projects/Community/wiki/MathS...](http://projectfortress.sun.com/Projects/Community/wiki/MathSyntaxInFortress)

2\.
[https://projectfortress.sun.com/svn/Community/trunk/.../asci...](https://projectfortress.sun.com/svn/Community/trunk/.../ascii-
to-unicode.tex)

------
narrator
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.

------
PaulHoule
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
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...](http://scala-programming-
language.1934581.n4.nabble.com/More-unicode-alternatives-for-ASCII-operators-
td2008146.html)

[2] [https://bitbucket.org/dnene/scalaz-
guide/src/5fbe1cd253f3/un...](https://bitbucket.org/dnene/scalaz-
guide/src/5fbe1cd253f3/unicode-mappings.rst)

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

------
jvictor
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.

------
MostAwesomeDude
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...](http://www.haskell.org/ghc/docs/7.0.2/html/users_guide/syntax-
extns.html) seems to back this up.

~~~
cemerick
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.

