Adam Ruppe:

> bearophile wrote:
> > writing "immutable" often is boring and makes code longer.
> 
> im<tab>   ->  immutable

That doesn't shorten the code.


> btw you might say "an editor is no excuse for bad language design" but this isn't bad language design, it's just a preference on your part. So it should be fixed on your end.

I prefer something like "val", it's shorter to write, uses less space, it's clear enough, it's used in another language (Scala). (Is "immutable" just a preference on your part?). I agree that "immutable" is a bit more clear, but immutable is not a rare keyword, probably it's present every 3-10 lines of my code, so your eye doesn't need to read "val" every time, it becomes a gestalt. The high usage frequency of "immutable" suggests its shortening according to Zipf law (http://en.wikipedia.org/wiki/Zipf%27s_law )...

Lot of time ago I have even suggested to replace "string" with "str" as in Python, I find it better and good enough :-)


> And if those 6 extra characters when reading (which are significantly easier to spot than the difference between a 'r' and a 'l' in the middle of an otherwise identical line!)

In D there's no "var", so this isn't a problem for D, it's a Scala problem.


> cause length problems, your
> line is likely too long to begin with.

Very recently I have people saying me that using qualified import is bad because it makes lines longer :-) The difference is that "immutable" => "val" is not a semantic change, it's just a name change, while changing how default import work changes semantic a little.
In my opinion replacing "immutable" with something shorter will encourage some lazy typists in using that keyword more often :-)


> That looks awful. It seems Go programmers don't care about tidy code. Languages should avoid such special cases.

I agree that special cases are not good. Go designers seem to value code succinctness much more than you and me and Walter :-)

----------------------

Spir:

> (see also http://spir.wikidot.com/create-vs-change -- I would enjoy having Bearophile's critics on this article ;-)

I am able to accept to tell apart update from creation, but the :: syntax doesn't look natural enough to me, I am too much used in seeing an equal sign somewhere there.

Bye,
bearophile

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.

bearophile wrote:
> Adam Ruppe:
> 
>> bearophile wrote:
>>> writing "immutable" often is boring and makes code longer.
>> im<tab>   ->  immutable
> 
> That doesn't shorten the code.

You did say "writing" implying the act of typing it was the problem.


> I prefer something like "val", it's shorter to write, uses less space, it's
> clear enough, it's used in another language (Scala).

It isn't clear enough, as "value" doesn't have a clear meaning when the type is a data structure. And remember that Scala does not have immutable types.

Immutable was picked because every other method xxx required an explanation of the form "xxx means it's immutable". Calling it "immutable" solved that problem.

You could as well call it "const" or "enum", too.


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

There were several other major reasons given.


> I agree that special cases are not good. Go designers seem to value code
> succinctness much more than you and me and Walter :-)

May I suggest APL for you? APL is the reigning champ of succinctness.

Adam Ruppe:

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

You are right, Zipf's law is about something related but different. I was thinking about data compression laws then :-)

Bye,
bearophile