Comment by gjm11 | Hacker News Reader

Comment by gjm11 | Hacker News Reader

Parent Full thread

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.

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

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

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

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.

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.

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.

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.

Reply on news.ycombinator.com