• bearophile <bearophileHUGS lycos.com> Dec 30 2010
• Adam Ruppe <destructionator gmail.com> Dec 30 2010
• bearophile <bearophileHUGS lycos.com> Dec 31 2010
• Walter Bright <newshound2 digitalmars.com> Dec 30 2010

bearophile <bearophileHUGS lycos.com> writes:

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

Adam Ruppe <destructionator gmail.com> writes:

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 <bearophileHUGS lycos.com> writes:

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

Walter Bright <newshound2 digitalmars.com> writes:

bearophile wrote:
 Adam Ruppe:
 
 bearophile wrote:
 writing "immutable" often is boring and makes code longer.




 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.