Something Go and Scala syntax

[Adam Ruppe]

bearophile wrote:
> That doesn't shorten the code.

Completely irrelevant. We're not playing code golf. What matters
is: a) Is it easy to change? and b) Is it clear to read?

immutable is easy to change. It's just one word. immutable is clear
to read, it says what it means.

> [val is] clear enough, it's used in another language (Scala).

How many times have you had to explain to someone "val means
immutable"? It'd go back to the same situation Walter gave
when he introduced immutable: he so often had to explain
"invariant means immutable" that he just renamed it. You'd be
reintroducing that.

> (Is "immutable" just a preference on your part?).

I usually stick to the status quo; I'm pretty conservative. You've
gotta give a big, objective benefit to justify a change.

Now, sometimes I end up liking a change after its enacted. I was
against dropping parens from to!(int) for example, but now I
like it a lot. But it isn't because it saves two characters.

> The high usage frequency of "immutable" suggests its shortening
> according to Zipf law (http://en.wikipedia.org/wiki/Zipf%27s_law )

I don't see anything in that article relating to number of letters
in a word.

> Very recently I have people saying me that using qualified import
> is bad because it makes lines longer :-)

There is one difference there: a function name happens more often
than a storage class.

immutable int a; // immutable only happened once

std.string.tolower(std.string.replace("abc", "def"));
  /* happened twice, and quite a bit more than 6 letters!
       (Importantly, it is 4 additional tokens. Tokens matter
        much more in shortness than characters because tokens
        are distinctive elements, both to brains and to
        autocompleters.)
  */


However, you might notice my arguments in that thread weren't about
length either, but rather focused on ease of changes and clarity.
On those issues, we have neutral and small minus. To justify a
change like this, one or both should be a big plus.


> In my opinion replacing "immutable" with something shorter will
> encourage some lazy typists in using that keyword more often :-)

It's possible, but to justify a change based on these grounds, you'd
need more than just an opinion.

Perhaps you should make a D preprocessor to try it for a while and
see if it actually makes a difference with you and anyone who joins
your test. (Alternatively you could patch a private copy of the
compiler, but a preprocessor might be easier to write and deploy.)
Then show some results and perhaps submit the necessary patches along
with it so others can confirm and implementing it is simple.