Library Change Request

On Jul 23, 2009, at 3:07 PM, Ricky Clarkson wrote:

> Randall Schulz's point seems to be "I don't care about names, so why
> the hell are you talking?". I hope the rest of you can see that he's
> not representative of the Scala community in this.

Randall's point is not that -- he simply puts thing into perspective.

When I started using Scala after having been using SML and OCaml, I
thought, too, I can just "guess" names. But that generally doesn't
work -- a community has its own set of names for things. Scala goes
back quite a bit to have its own.

Now it may have annoyed me for a day or two, but after you use some
names a bit, you get used to them. I don't even remember what annoyed
me and why -- just two months ago (http://la.scala.la/ documents my
adoption of Scala, these feelings are fleeting and are easily
forgotten, so that's one of that blog's purposes to remember them). I
vaguely remember being amused by mkString for a minute or two, but I
needed to get stuff done, the list printed, and it did the job, so the
2nd time I remembered it well.

Usually the wish 'why don't you name things as I might have guessed
them" stems from an unfamiliarity cured by experimentation. After
that, Scala is no more idiosyncratic than Java or Ruby.

What Randall is saying, in my interpretation, is "don't argue about
names too much instead of/before using them." Abd after you use them
for a while and see how they really fit, you can have a say in
changing them -- that's what Paul meant. It's like Zen -- you can't
argue about effectiveness until you practice it.

Cheers,
Alexy

On Thursday July 23 2009, Ricky Clarkson wrote:
> Randall Schulz's point seems to be "I don't care about names, so why
> the hell are you talking?". I hope the rest of you can see that he's
> not representative of the Scala community in this.

That is scarcely recognizable as my actual point, and I'd like to
believe you know that.

My point is simply that the names assigned to methods and classes is an
order of magnitude less important than the semantics they implement and
that the semantics of library classes and methods are themselves
considerably less important than that of the language itself. Finally,
these relationships reflect the constituents of the actual challenge of
going from newcomer to proficient programmer using the language in
question (and its standard library/ies).

So in proper perspective, the names of library methods really are a
matter of fairly little consequence.

Lastly, let me point out that the issue is not the comparison of methods
named, say, "a", "b", "c" ... "aa", "bb", "cc" ... etc. with names that
have some semblance of natural language significance, it is between two
names each of which have very similar connotative value.

When you put all this together, the matter truly is inconsequential.

Randall Schulz

Ismael,

The one thing I like about your posts is that you never have once said the point I'm raising is not valid. And I want to thank you for that. This point is obviously more valid than, "Get used to it." or "Who cares about names" and other retorts that we've heard here.

Yes, if there are more pressing issues, then by all means, I understand priorities. I am glad that you and others know that pressing priorities doesn't make my argument invalid, and more so, I would hope that the generalized principle learned here does in fact carry into the design of new methods and method changes once the higher priorities are taken care of.

Ken

On Thu, Jul 23, 2009 at 3:01 PM, Ismael Juma <mlists@juma.me.uk> wrote:

On Thu, 2009-07-23 at 20:54 +0200, John Nilsson wrote:
> You might be correct there. My definition is actually more based on
> visibility in mailing lists than anything else, and more than
> anything, gut feeling based on my limited exposure to said lists...

As with most open-source projects, there are a lot of very vocal users
who don't contribute much to the codebase. A much better indicator is
the Trac timeline.

> > I don't think so. Consider the huge amount of work that Paul Phillips is
> > doing to try to achieve some consistency on how equality works in Scala.
> > There is no glamour there, I assure you of that. This has been discussed
> > extensively in scala-internals and on IRC (#scala).
>
> While important it's not the kind of usability I was thinking of. I
> would put the equality issue closer to the feasability/formalism side
> of things that pure usability.

I am confused by your definition of usability then. I don't see the
connection to formalism, and it's not the sort of thing one can write a
paper about. Personally, I'd more worried about the usability aspect of
getting == to return false in some hard to understand corner cases than
mkString versus makeString.

Best,
Ismael

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

Ismael Juma wrote:
> On Thu, 2009-07-23 at 11:36 +0100, Miles Sabin wrote:
>> On Thu, Jul 23, 2009 at 9:23 AM, Ricky Clarkson wrote:
>>> mkString is a bad name, but not an excessively bad one. I'd say that
>>> yes, it should have been written correctly in the first place, but
>>> that it's not worth changing now.
>> FWIW, I strongly suspect that mkString was named with one eye on
>> toString ... so it's not _entirely_ unmotivated.
>
> My suspicion is that it was created by someone familiar with unix tools
> (mkdir, mkfs, mkinitrd, etc.) and adapted to camel-case.

The first appearance of mkString in the source tree that I could find is from
r220 at Feb 14, 2003 committed by Martin.

./sources/scala/$colon$colon.scala:10:
override def toString(): String = mkString("[", ",", "]");
./sources/scala/List.scala:264:
* [1, 2, 3].mkString("(", "; ", ")") = "(1; 2; 3)"
./sources/scala/List.scala:270:
def mkString(start: String, sep: String, end: String): String =
./sources/scala/List.scala:274:
else head.toString().concat(sep).concat(tail.mkString("", sep, end)));

r219 has no mkString searching using recursive grep in scala.

Blair

mkString always "felt" right to me, I've been trying to put my finger on the reason why that is ever since this thread started, and reckon I've just got it.
The shortened name suggests that this method is small and lightweight with little overhead, almost throwaway.  It's like the difference between a hand scrawled post-it note and a formal letter.  The longer, more correct name gives me an impression that the function may take longer, or consume more memory, so I'd think twice before using it heavily.

Of course, this is all subjective...

On Thu, Jul 23, 2009 at 8:44 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

Ismael,

The one thing I like about your posts is that you never have once said the point I'm raising is not valid. And I want to thank you for that. This point is obviously more valid than, "Get used to it." or "Who cares about names" and other retorts that we've heard here.

Yes, if there are more pressing issues, then by all means, I understand priorities. I am glad that you and others know that pressing priorities doesn't make my argument invalid, and more so, I would hope that the generalized principle learned here does in fact carry into the design of new methods and method changes once the higher priorities are taken care of.

Ken

On Thu, Jul 23, 2009 at 3:01 PM, Ismael Juma <mlists@juma.me.uk> wrote:

On Thu, 2009-07-23 at 20:54 +0200, John Nilsson wrote:
> You might be correct there. My definition is actually more based on
> visibility in mailing lists than anything else, and more than
> anything, gut feeling based on my limited exposure to said lists...

As with most open-source projects, there are a lot of very vocal users
who don't contribute much to the codebase. A much better indicator is
the Trac timeline.

> > I don't think so. Consider the huge amount of work that Paul Phillips is
> > doing to try to achieve some consistency on how equality works in Scala.
> > There is no glamour there, I assure you of that. This has been discussed
> > extensively in scala-internals and on IRC (#scala).
>
> While important it's not the kind of usability I was thinking of. I
> would put the equality issue closer to the feasability/formalism side
> of things that pure usability.

I am confused by your definition of usability then. I don't see the
connection to formalism, and it's not the sort of thing one can write a
paper about. Personally, I'd more worried about the usability aspect of
getting == to return false in some hard to understand corner cases than
mkString versus makeString.

Best,
Ismael

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

+1.

FWIW I really don't see what's the big deal with this naming. Does mkString really seams counter-intuitive? I'm not saying naming is not important but in many cases a name can not satisfy everyone's eye for aesthetics. For instance I'm totally ok with mkString, seems very intuitive to me, somehow reminds be of toString etc. ... some people are really bothered about that ... so this is just an endless debate.

Br's,
Marius

On Thu, Jul 23, 2009 at 8:46 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Thursday July 23 2009, Ken Egervari wrote:
> I would agree with this joining comment. "make" is not a terrible
> world. Perhaps "build" may have been a bit better. I think the
> conceptual association with string builders, and building a string to
> represent the collection conceptually makes sense.
>
> Regardless, this is not a matter of readability... not like the to_s
> method in Ruby (which is an absolute disaster - it means totally
> stupid IMO)
>
> The real concern is writability - having nomenclature that is
> intuitive and consistent so developers can intuitively guess what to
> write and be correct most of the time. Isn't it a great feeling when
> your first guess just works? No compile times? No runtime errors? No
> bugs? It just works.
>
> This, done across the entire platform, really does in fact lessen the
> learning curve. Sure, if mkString in isolation isn't *that* big of a
> deal. Done 50 or 100 times in major parts of the core library - it's
> a different story.
>
> I just think consistency can have very powerful effects on a language
> and how a human interacts with it.

I really disagree. With all of it.

Quality and productivity don't come from how effectively or quickly we
can enter programs at the keyboard. If it did, auto-completion would be
the last word in software development technology. And software goodness
most certainly does not come from being able to guess the name of a
method. Furthermore, what constitutes properly descriptive or intuitive
names is so subjective that every programmer would need his own lexicon
for interacting with the standard libraries, 'cause people just will
not agree on such matters.

And the argument about one or two of these supposedly poorly chosen
names being no big deal but hundreds of them creating a problem
suggests that you have a sufficiently capacious memory that you don't
need to consult the reference documention on a regular basis while
simultaneously implying you have trouble remembering that it's mkString
and not makeString.


This entire obsession with names is truly a frivolous and silly quest.
If you truly would have us to believe that mkString impairs your
productivity or the quality of your code by comparison to what they
would be if it were named makeString, then I think you're admitting to
being a rather inept programmer.


> Ken


Randall Schulz

I respectfully disagree.

With logic, either something is counter-intuitive, or it's not. I've already shown that it is - it doesn't follow conventions, so it makes sense that it's not 100% intuitive.

Sure, when reading it, it's fine for the most part. When writing it, especially for a new user of Scala, it is not intuitive. It fights against all the precedence placed before it.

And while some intuition may suggest an association between toString and mkString, it is far less intuitive than the argument for "makeString". If mkString is acceptable, then let's change toString into "tString" then. Why not? We drop vowels from one method name - why not the other? But I guess that would ruin the "fixed-width font" intuition" or "fight against toString() in java.lang.Object" intuition, or whatever other argument you'd like to raise.

The sad fact is that if the method name was named makeString from the very start, I doubt anyone would be fighting to name it to "mkString".

And while this discussion has been about a particular, there is a larger issue here that I and a few others have already commented on - the issue of policy to introduce language changes, the issues of the important of consistency and polish in a core library, and perhaps even a defining the policy for changes and how they get rotated out in a respectful, predictable way.

Ken

On Thu, Jul 23, 2009 at 4:20 PM, Marius Danciu <marius.danciu@gmail.com> wrote:

+1.

FWIW I really don't see what's the big deal with this naming. Does mkString really seams counter-intuitive? I'm not saying naming is not important but in many cases a name can not satisfy everyone's eye for aesthetics. For instance I'm totally ok with mkString, seems very intuitive to me, somehow reminds be of toString etc. ... some people are really bothered about that ... so this is just an endless debate.

Br's,
Marius

On Thu, Jul 23, 2009 at 8:46 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Thursday July 23 2009, Ken Egervari wrote:
> I would agree with this joining comment. "make" is not a terrible
> world. Perhaps "build" may have been a bit better. I think the
> conceptual association with string builders, and building a string to
> represent the collection conceptually makes sense.
>
> Regardless, this is not a matter of readability... not like the to_s
> method in Ruby (which is an absolute disaster - it means totally
> stupid IMO)
>
> The real concern is writability - having nomenclature that is
> intuitive and consistent so developers can intuitively guess what to
> write and be correct most of the time. Isn't it a great feeling when
> your first guess just works? No compile times? No runtime errors? No
> bugs? It just works.
>
> This, done across the entire platform, really does in fact lessen the
> learning curve. Sure, if mkString in isolation isn't *that* big of a
> deal. Done 50 or 100 times in major parts of the core library - it's
> a different story.
>
> I just think consistency can have very powerful effects on a language
> and how a human interacts with it.

I really disagree. With all of it.

Quality and productivity don't come from how effectively or quickly we
can enter programs at the keyboard. If it did, auto-completion would be
the last word in software development technology. And software goodness
most certainly does not come from being able to guess the name of a
method. Furthermore, what constitutes properly descriptive or intuitive
names is so subjective that every programmer would need his own lexicon
for interacting with the standard libraries, 'cause people just will
not agree on such matters.

And the argument about one or two of these supposedly poorly chosen
names being no big deal but hundreds of them creating a problem
suggests that you have a sufficiently capacious memory that you don't
need to consult the reference documention on a regular basis while
simultaneously implying you have trouble remembering that it's mkString
and not makeString.


This entire obsession with names is truly a frivolous and silly quest.
If you truly would have us to believe that mkString impairs your
productivity or the quality of your code by comparison to what they
would be if it were named makeString, then I think you're admitting to
being a rather inept programmer.


> Ken


Randall Schulz

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

Hi Randall

With all respect, but I do not agree.

The real power of a language and it's ecosystem comes from having a
good library and consistent, expressive and clear naming conventions.

I truly appreciate all the effort of the Scala community, but mkString
is a lesser name than makeString.

I was educated by excellent naming conventions used in the Smalltalk
class libraries and would like to build on previous experiences.

Naming is very important and lesser programmers do not understand the
importance of good naming in a system with respect to functions,
classes, package names, variables, domain concepts, etc.

Yours friendly

Rudi

On 23 Jul 2009, at 7:46 PM, Randall R Schulz wrote:

> On Thursday July 23 2009, Ken Egervari wrote:
>> I would agree with this joining comment. "make" is not a terrible
>> world. Perhaps "build" may have been a bit better. I think the
>> conceptual association with string builders, and building a string to
>> represent the collection conceptually makes sense.
>>
>> Regardless, this is not a matter of readability... not like the to_s
>> method in Ruby (which is an absolute disaster - it means totally
>> stupid IMO)
>>
>> The real concern is writability - having nomenclature that is
>> intuitive and consistent so developers can intuitively guess what to
>> write and be correct most of the time. Isn't it a great feeling when
>> your first guess just works? No compile times? No runtime errors? No
>> bugs? It just works.
>>
>> This, done across the entire platform, really does in fact lessen the
>> learning curve. Sure, if mkString in isolation isn't *that* big of a
>> deal. Done 50 or 100 times in major parts of the core library - it's
>> a different story.
>>
>> I just think consistency can have very powerful effects on a language
>> and how a human interacts with it.
>
> I really disagree. With all of it.
>
> Quality and productivity don't come from how effectively or quickly we
> can enter programs at the keyboard. If it did, auto-completion would
> be
> the last word in software development technology. And software
> goodness
> most certainly does not come from being able to guess the name of a
> method. Furthermore, what constitutes properly descriptive or
> intuitive
> names is so subjective that every programmer would need his own
> lexicon
> for interacting with the standard libraries, 'cause people just will
> not agree on such matters.
>
> And the argument about one or two of these supposedly poorly chosen
> names being no big deal but hundreds of them creating a problem
> suggests that you have a sufficiently capacious memory that you don't
> need to consult the reference documention on a regular basis while
> simultaneously implying you have trouble remembering that it's
> mkString
> and not makeString.
>
>
> This entire obsession with names is truly a frivolous and silly quest.
> If you truly would have us to believe that mkString impairs your
> productivity or the quality of your code by comparison to what they
> would be if it were named makeString, then I think you're admitting to
> being a rather inept programmer.
>
>
>> Ken
>
>
> Randall Schulz

Personally, I think it should stay mkString.  It goes nicely with all the mkToast, mkEggs and mkBacon methods that I use so often.


On Thu, Jul 23, 2009 at 4:40 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I respectfully disagree.

With logic, either something is counter-intuitive, or it's not. I've already shown that it is - it doesn't follow conventions, so it makes sense that it's not 100% intuitive.

Sure, when reading it, it's fine for the most part. When writing it, especially for a new user of Scala, it is not intuitive. It fights against all the precedence placed before it.

And while some intuition may suggest an association between toString and mkString, it is far less intuitive than the argument for "makeString". If mkString is acceptable, then let's change toString into "tString" then. Why not? We drop vowels from one method name - why not the other? But I guess that would ruin the "fixed-width font" intuition" or "fight against toString() in java.lang.Object" intuition, or whatever other argument you'd like to raise.

The sad fact is that if the method name was named makeString from the very start, I doubt anyone would be fighting to name it to "mkString".

And while this discussion has been about a particular, there is a larger issue here that I and a few others have already commented on - the issue of policy to introduce language changes, the issues of the important of consistency and polish in a core library, and perhaps even a defining the policy for changes and how they get rotated out in a respectful, predictable way.

Ken

On Thu, Jul 23, 2009 at 4:20 PM, Marius Danciu <marius.danciu@gmail.com> wrote:

+1.

FWIW I really don't see what's the big deal with this naming. Does mkString really seams counter-intuitive? I'm not saying naming is not important but in many cases a name can not satisfy everyone's eye for aesthetics. For instance I'm totally ok with mkString, seems very intuitive to me, somehow reminds be of toString etc. ... some people are really bothered about that ... so this is just an endless debate.

Br's,
Marius

On Thu, Jul 23, 2009 at 8:46 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Thursday July 23 2009, Ken Egervari wrote:
> I would agree with this joining comment. "make" is not a terrible
> world. Perhaps "build" may have been a bit better. I think the
> conceptual association with string builders, and building a string to
> represent the collection conceptually makes sense.
>
> Regardless, this is not a matter of readability... not like the to_s
> method in Ruby (which is an absolute disaster - it means totally
> stupid IMO)
>
> The real concern is writability - having nomenclature that is
> intuitive and consistent so developers can intuitively guess what to
> write and be correct most of the time. Isn't it a great feeling when
> your first guess just works? No compile times? No runtime errors? No
> bugs? It just works.
>
> This, done across the entire platform, really does in fact lessen the
> learning curve. Sure, if mkString in isolation isn't *that* big of a
> deal. Done 50 or 100 times in major parts of the core library - it's
> a different story.
>
> I just think consistency can have very powerful effects on a language
> and how a human interacts with it.

I really disagree. With all of it.

Quality and productivity don't come from how effectively or quickly we
can enter programs at the keyboard. If it did, auto-completion would be
the last word in software development technology. And software goodness
most certainly does not come from being able to guess the name of a
method. Furthermore, what constitutes properly descriptive or intuitive
names is so subjective that every programmer would need his own lexicon
for interacting with the standard libraries, 'cause people just will
not agree on such matters.

And the argument about one or two of these supposedly poorly chosen
names being no big deal but hundreds of them creating a problem
suggests that you have a sufficiently capacious memory that you don't
need to consult the reference documention on a regular basis while
simultaneously implying you have trouble remembering that it's mkString
and not makeString.


This entire obsession with names is truly a frivolous and silly quest.
If you truly would have us to believe that mkString impairs your
productivity or the quality of your code by comparison to what they
would be if it were named makeString, then I think you're admitting to
being a rather inept programmer.


> Ken


Randall Schulz

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

I think you have hit the nail on the head.

Up till the start of this thread I was very impressed by Scala (and
community).

It has been dented a bit - due to this thread.

Usability should be an important attribute of a good library - and
nothing prevents us from learning from the past of good libraries.

Rudi

On 23 Jul 2009, at 8:03 PM, John Nilsson wrote:

> I think that this thread is a perfect example of one of the problems
> that might be Scalas biggest problems going forward. At least I have
> the impression that usability is a topic easily dismissed by leading
> figures in the community. Not categorically ignored, just a noticable
> bias toward more academically challanging things related to formalism
> and math rather then the day to day experience of a working
> programmer.
>
> When usability is concidered it seems to be more valued in terms of
> feasablity of some use case rather than pure joy of it. It's like
> comparing some Apple products to their competition. The other products
> does the job just fine, but the last bit of polish that Apple manages
> to pour into it really does the difference.
>
> In this case I happen not to think the issue at hand is that big of a
> deal. But I do take the general attitude towards the general problem
> to a little to dismissive.
>
> F.ex. it has been pointed out that such a change is difficult because
> of how it will impact other peoples code. Maybe this problem should be
> taken seriously as something to be fixed? I really liked the
> suggestion to let the compiler know how to refactor code to conform to
> the new API. This is exactly how eclipse solves the problem for me to
> day.
>
> Another thing that came to my mind that might be beneficial, to add
> som balancing bias towards a focus on usability, is to create a HIG
> (Human Interface Guidlines). This would be the artefact to update when
> threads such as this reach a concensus, or papers about usability in
> API design is published. When the HIG has evolved for some time it
> will probably also identify problem areas in the language and it
> surroundings that needs to be addressed to enable usability
> improvements.
>
> BR,
> John
>
> On Thu, Jul 23, 2009 at 7:24 PM, Ken
> Egervari wrote:
>> I would agree with this joining comment. "make" is not a terrible
>> world.
>> Perhaps "build" may have been a bit better. I think the conceptual
>> association with string builders, and building a string to
>> represent the
>> collection conceptually makes sense.
>>
>> Regardless, this is not a matter of readability... not like the
>> to_s method
>> in Ruby (which is an absolute disaster - it means totally stupid IMO)
>>
>> The real concern is writability - having nomenclature that is
>> intuitive and
>> consistent so developers can intuitively guess what to write and be
>> correct
>> most of the time. Isn't it a great feeling when your first guess
>> just works?
>> No compile times? No runtime errors? No bugs? It just works.
>>
>> This, done across the entire platform, really does in fact lessen the
>> learning curve. Sure, if mkString in isolation isn't *that* big of
>> a deal.
>> Done 50 or 100 times in major parts of the core library - it's a
>> different
>> story.
>>
>> I just think consistency can have very powerful effects on a
>> language and
>> how a human interacts with it.
>>
>> Ken
>>
>> On Thu, Jul 23, 2009 at 12:09 PM, Kevin Wright
>> wrote:
>>>
>>> Under the principle of least surprise, it's probably not wise that
>>> "joining" a collection should return a string. I imagine that
>>> would cause a
>>> even longer and more fruitless email thread than this one...
>>>
>>>
>>> FWIW, I haven't yet met a single person who didn't instantly
>>> understand
>>> mkString to be an abbreviation for makeString. Compared some of
>>> the areas
>>> where Scala is boldly staking out new ground, this discussion is
>>> perhaps a
>>> little bit frivolous...
>>>
>>>
>>>
>>>
>>> On Thu, Jul 23, 2009 at 4:47 PM, Richard Wallace
>>> wrote:
>>>>
>>>> Just to add a bit more fuel to the fire, another voice to the
>>>> chorus,
>>>> etc. If it were to be renamed I'd hope it would be changed to
>>>> "join".
>>>> That seems to be what other libraries and languages use, mostly
>>>> because of the duality with String.split(). As another newb and
>>>> recent convert to Scala the first time I saw mkString I had to go
>>>> and
>>>> read the docs to figure out what it did. It wasn't entirely
>>>> obvious.
>>>> But now that I know it's not a big deal.
>>>>
>>>> Rich
>>>>
>>>> On Thu, Jul 23, 2009 at 1:23 AM, Ricky Clarkson>>> >
>>>> wrote:
>>>>> mkString is a bad name, but not an excessively bad one. I'd say
>>>>> that
>>>>> yes, it should have been written correctly in the first place, but
>>>>> that it's not worth changing now.
>>>>>
>>>>> I'd also suggest Randall breathes more deeply while typing.
>>>>>
>>>>> 2009/7/23 Ismael Juma :
>>>>>> On Wed, 2009-07-22 at 19:33 -0700, Randall R Schulz wrote:
>>>>>>> On Wednesday July 22 2009, Ismael Juma wrote:
>>>>>>>> Hey Randall,
>>>>>>>>
>>>>>>>> On Wed, 2009-07-22 at 18:30 -0700, Randall R Schulz wrote:
>>>>>>>>> On Wednesday July 22 2009, Ismael Juma wrote:
>>>>>>>>>> On Wed, 2009-07-22 at 17:36 -0700, Randall R Schulz wrote:
>>>>>>>>>>> Is this thread about Scala-II? I missed that part.
>>>>>>>>>>
>>>>>>>>>> No, but it sounded to me like you were saying that the name
>>>>>>>>>> change was not an improvement (compatibility/effort issues
>>>>>>>>>> aside).
>>>>>>>>>
>>>>>>>>> I don't know how you got that. I meant only that to change
>>>>>>>>> "mk"
>>>>>>>>> to "make" was a triviality, signified by my frivolous
>>>>>>>>> response.
>>>>>>>>
>>>>>>>> It may be more constructive and save people time if you just
>>>>>>>> say
>>>>>>>> that
>>>>>>>> instead then. I considered quoting the various bits, but
>>>>>>>> doesn't
>>>>>>>> seem
>>>>>>>> worth it.
>>>>>>>
>>>>>>> Was there any confusion that it was meant in jest? Is humor not
>>>>>>> allowed
>>>>>>> on this list?
>>>>>>
>>>>>> Only when it's funny. :)
>>>>>>
>>>>>> Ismael
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ricky Clarkson
>>>>> Java Programmer, AD Holdings
>>>>> +44 1565 770804
>>>>> Skype: ricky_clarkson
>>>>> Google Talk: ricky.clarkson@gmail.com
>>>>>
>>>
>>
>>
>>
>> --
>> Work In Progress - "Dreaming":
>> http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3
>>
>> My Original Music: http://www.soundclick.com/KenEgervari
>> My Humorous Speeches: http://www.youtube.com/user/egervari
>> My Facebook:
>> http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=7162...
>>

Wow! This thread has skyrocketed to the top - I think more than 60 replies.  It seems that by now, everything that can be said has been, and that the list would be best off with this thread ending with no more replies.
I'll sum up what I think is agreed and what is disputed:1. It seems most agree that "mkString" is neither clear nor consistent; alternatives proposed include "buildString", "makeString", and perhaps "join". 2. What is under great dispute is whether it's worth investing the effort to change it.  Some have argued that it's not worth the effort or resultant confusion, and that it would distract from higher priorities.  Others argue that Scala, as a young and growing language, would be served best by continual improvement. 3. Last, and perhaps most importantly, this discussion may have highlighted some areas where Scala and its community could improve: in usability and ease of entry, especially to newcomers.  (And perhaps in friendliness as well.)
On Thu, Jul 23, 2009 at 4:57 PM, Rudi Engelbrecht <rudisubs@gmail.com> wrote:

I think you have hit the nail on the head.

Up till the start of this thread I was very impressed by Scala (and community).

It has been dented a bit - due to this thread.

Usability should be an important attribute of a good library - and nothing prevents us from learning from the past of good libraries.

Rudi


On 23 Jul 2009, at 8:03 PM, John Nilsson <john@milsson.nu> wrote:

I think that this thread is a perfect example of one of the problems
that might be Scalas biggest problems going forward. At least I have
the impression that usability is a topic easily dismissed by leading
figures in the community. Not categorically ignored, just a noticable
bias toward more academically challanging things related to formalism
and math rather then the day to day experience of a working
programmer.

When usability is concidered it seems to be more valued in terms of
feasablity of some use case rather than pure joy of it. It's like
comparing some Apple products to their competition. The other products
does the job just fine, but the last bit of polish that Apple manages
to pour into it really does the difference.

In this case I happen not to think the issue at hand is that big of a
deal. But I do take the general attitude towards the general problem
to a little to dismissive.

F.ex. it has been pointed out that such a change is difficult because
of how it will impact other peoples code. Maybe this problem should be
taken seriously as something to be fixed? I really liked the
suggestion to let the compiler know how to refactor code to conform to
the new API. This is exactly how eclipse solves the problem for me to
day.

Another thing that came to my mind that might be beneficial, to add
som balancing bias towards a focus on usability, is to create a HIG
(Human Interface Guidlines). This would be the artefact to update when
threads such as this reach a concensus, or papers about usability in
API design is published. When the HIG has evolved for some time it
will probably also identify problem areas in the language and it
surroundings that needs to be addressed to enable usability
improvements.

BR,
John

On Thu, Jul 23, 2009 at 7:24 PM, Ken Egervari<ken.egervari@gmail.com> wrote:

I would agree with this joining comment. "make" is not a terrible world.
Perhaps "build" may have been a bit better. I think the conceptual
association with string builders, and building a string to represent the
collection conceptually makes sense.

Regardless, this is not a matter of readability... not like the to_s method
in Ruby (which is an absolute disaster - it means totally stupid IMO)

The real concern is writability - having nomenclature that is intuitive and
consistent so developers can intuitively guess what to write and be correct
most of the time. Isn't it a great feeling when your first guess just works?
No compile times? No runtime errors? No bugs? It just works.

This, done across the entire platform, really does in fact lessen the
learning curve. Sure, if mkString in isolation isn't *that* big of a deal.
Done 50 or 100 times in major parts of the core library - it's a different
story.

I just think consistency can have very powerful effects on a language and
how a human interacts with it.

Ken

On Thu, Jul 23, 2009 at 12:09 PM, Kevin Wright
<kev.lee.wright@googlemail.com> wrote:

Under the principle of least surprise, it's probably not wise that
"joining" a collection should return a string.  I imagine that would cause a
even longer and more fruitless email thread than this one...


FWIW, I haven't yet met a single person who didn't instantly understand
mkString to be an abbreviation for makeString.  Compared some of the areas
where Scala is boldly staking out new ground, this discussion is perhaps a
little bit frivolous...




On Thu, Jul 23, 2009 at 4:47 PM, Richard Wallace
<rwallace@thewallacepack.net> wrote:

Just to add a bit more fuel to the fire, another voice to the chorus,
etc.  If it were to be renamed I'd hope it would be changed to "join".
 That seems to be what other libraries and languages use, mostly
because of the duality with String.split().  As another newb and
recent convert to Scala the first time I saw mkString I had to go and
read the docs to figure out what it did.  It wasn't entirely obvious.
But now that I know it's not a big deal.

Rich

On Thu, Jul 23, 2009 at 1:23 AM, Ricky Clarkson<ricky.clarkson@gmail.com>
wrote:

mkString is a bad name, but not an excessively bad one.  I'd say that
yes, it should have been written correctly in the first place, but
that it's not worth changing now.

I'd also suggest Randall breathes more deeply while typing.

2009/7/23 Ismael Juma <mlists@juma.me.uk>:

On Wed, 2009-07-22 at 19:33 -0700, Randall R Schulz wrote:

On Wednesday July 22 2009, Ismael Juma wrote:

Hey Randall,

On Wed, 2009-07-22 at 18:30 -0700, Randall R Schulz wrote:

On Wednesday July 22 2009, Ismael Juma wrote:

On Wed, 2009-07-22 at 17:36 -0700, Randall R Schulz wrote:

Is this thread about Scala-II? I missed that part.

No, but it sounded to me like you were saying that the name
change was not an improvement (compatibility/effort issues
aside).

I don't know how you got that. I meant only that to change "mk"
to "make" was a triviality, signified by my frivolous response.

It may be more constructive and save people time if you just say
that
instead then. I considered quoting the various bits, but doesn't
seem
worth it.

Was there any confusion that it was meant in jest? Is humor not
allowed
on this list?

Only when it's funny. :)

Ismael

--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook:
http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

  1. It seems most agree that "mkString" is neither clear nor consistent; alternatives proposed include "buildString", "makeString", and perhaps "join".   

I don't think that is true at all.  Most people on the list haven't ventured an opinion.  It would be far more reasonable to assume that most people don't care enough to offer an opinion.  (Which should probably count as votes for 'This is trivial and frivolous.') 

  2. What is under great dispute is whether it's worth investing the effort to change it.  Some have argued that it's not worth the effort or resultant confusion, and that it would distract from higher priorities.  Others argue that Scala, as a young and growing language, would be served best by continual improvement. 3. Last, and perhaps most importantly, this discussion may have highlighted some areas where Scala and its community could improve: in usability and ease of entry, especially to newcomers.  (And perhaps in friendliness as well.)   

Usability and ease of entry are important, but I would hasten to say the two current and ongoing threads on the list from new users who are unable to get the compiler to work from the command line are far more deserving of attention in that regard than this argument.    As to friendliness, while Paul's answer was flip, it was hardly nasty and his point was well taken.   Finally in the words of Ralph Waldo Emerson: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day. — ‘Ah, so you shall be sure to be misunderstood.’ — Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood." (Self-Reliance)

PLEASE READ: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please delete it and all copies from your system, destroy any hard copies and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Nomura Holding America Inc., Nomura Securities International, Inc, and their respective subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state the views of such entity. Unless otherwise stated, any pricing information in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

So then we can all have our cake and eat it too by agreeing that there are 2 groups - those who care about naming and those who don't.
So then let's use makeString - since we care and those who do not care can use mkString - because it does not make as big a difference to them?

Rudi
PS. When typing this I checked it afterwards and found that I typed 'makeString' where I intended to type 'mkString' - but then I am new to Scala  ;-)



On 23 Jul 2009, at 10:20 PM, Marius Danciu <marius.danciu@gmail.com> wrote:

+1.

FWIW I really don't see what's the big deal with this naming. Does mkString really seams counter-intuitive? I'm not saying naming is not important but in many cases a name can not satisfy everyone's eye for aesthetics. For instance I'm totally ok with mkString, seems very intuitive to me, somehow reminds be of toString etc. ... some people are really bothered about that ... so this is just an endless debate.

Br's,
Marius

On Thu, Jul 23, 2009 at 8:46 PM, Randall R Schulz < (rschulz [at] sonic [dot] net> wrote:

On Thursday July 23 2009, Ken Egervari wrote:
> I would agree with this joining comment. "make" is not a terrible
> world. Perhaps "build" may have been a bit better. I think the
> conceptual association with string builders, and building a string to
> represent the collection conceptually makes sense.
>
> Regardless, this is not a matter of readability... not like the to_s
> method in Ruby (which is an absolute disaster - it means totally
> stupid IMO)
>
> The real concern is writability - having nomenclature that is
> intuitive and consistent so developers can intuitively guess what to
> write and be correct most of the time. Isn't it a great feeling when
> your first guess just works? No compile times? No runtime errors? No
> bugs? It just works.
>
> This, done across the entire platform, really does in fact lessen the
> learning curve. Sure, if mkString in isolation isn't *that* big of a
> deal. Done 50 or 100 times in major parts of the core library - it's
> a different story.
>
> I just think consistency can have very powerful effects on a language
> and how a human interacts with it.

I really disagree. With all of it.

Quality and productivity don't come from how effectively or quickly we
can enter programs at the keyboard. If it did, auto-completion would be
the last word in software development technology. And software goodness
most certainly does not come from being able to guess the name of a
method. Furthermore, what constitutes properly descriptive or intuitive
names is so subjective that every programmer would need his own lexicon
for interacting with the standard libraries, 'cause people just will
not agree on such matters.

And the argument about one or two of these supposedly poorly chosen
names being no big deal but hundreds of them creating a problem
suggests that you have a sufficiently capacious memory that you don't
need to consult the reference documention on a regular basis while
simultaneously implying you have trouble remembering that it's mkString
and not makeString.


This entire obsession with names is truly a frivolous and silly quest.
If you truly would have us to believe that mkString impairs your
productivity or the quality of your code by comparison to what they
would be if it were named makeString, then I think you're admitting to
being a rather inept programmer.


> Ken


Randall Schulz

I hate to say this, but I am not a person who can't get the scala compiler working. I already have projects with 30-40 classes and specs/tests working on them in a big test project.

Please don't diminish my argument by making up some "facts" about my learning progress to somehow support the idea that my argument shouldn't hold any weight because of some fallacy that I am stupid and new to the language, and therefore "could not possibly understand and comprehend the masterful counter arguments in this thread" and "not deserving of attention."

Regards,

Ken

On Thu, Jul 23, 2009 at 6:04 PM, Frohnhofer, James <james.frohnhofer@nomura.com> wrote:

  1. It seems most agree that "mkString" is neither clear nor consistent; alternatives proposed include "buildString", "makeString", and perhaps "join".   

I don't think that is true at all.  Most people on the list haven't ventured an opinion.  It would be far more reasonable to assume that most people don't care enough to offer an opinion.  (Which should probably count as votes for 'This is trivial and frivolous.') 

  2. What is under great dispute is whether it's worth investing the effort to change it.  Some have argued that it's not worth the effort or resultant confusion, and that it would distract from higher priorities.  Others argue that Scala, as a young and growing language, would be served best by continual improvement. 3. Last, and perhaps most importantly, this discussion may have highlighted some areas where Scala and its community could improve: in usability and ease of entry, especially to newcomers.  (And perhaps in friendliness as well.)   

Usability and ease of entry are important, but I would hasten to say the two current and ongoing threads on the list from new users who are unable to get the compiler to work from the command line are far more deserving of attention in that regard than this argument.    As to friendliness, while Paul's answer was flip, it was hardly nasty and his point was well taken.   Finally in the words of Ralph Waldo Emerson: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day. — ‘Ah, so you shall be sure to be misunderstood.’ — Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood." (Self-Reliance)

PLEASE READ: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please delete it and all copies from your system, destroy any hard copies and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Nomura Holding America Inc., Nomura Securities International, Inc, and their respective subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state the views of such entity. Unless otherwise stated, any pricing information in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

And I guess those are all methods in your mkMuffin package? Or should that be mcMuffin ;-)

Rudi
Cell: +27 82 551 0582
On 23 Jul 2009, at 10:48 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Personally, I think it should stay mkString.  It goes nicely with all the mkToast, mkEggs and mkBacon methods that I use so often.


On Thu, Jul 23, 2009 at 4:40 PM, Ken Egervari < (ken [dot] egervari [at] gmail [dot] com> wrote:

I respectfully disagree.

With logic, either something is counter-intuitive, or it's not. I've already shown that it is - it doesn't follow conventions, so it makes sense that it's not 100% intuitive.

Sure, when reading it, it's fine for the most part. When writing it, especially for a new user of Scala, it is not intuitive. It fights against all the precedence placed before it.

And while some intuition may suggest an association between toString and mkString, it is far less intuitive than the argument for "makeString". If mkString is acceptable, then let's change toString into "tString" then. Why not? We drop vowels from one method name - why not the other? But I guess that would ruin the "fixed-width font" intuition" or "fight against toString() in java.lang.Object" intuition, or whatever other argument you'd like to raise.

The sad fact is that if the method name was named makeString from the very start, I doubt anyone would be fighting to name it to "mkString".

And while this discussion has been about a particular, there is a larger issue here that I and a few others have already commented on - the issue of policy to introduce language changes, the issues of the important of consistency and polish in a core library, and perhaps even a defining the policy for changes and how they get rotated out in a respectful, predictable way.

Ken

On Thu, Jul 23, 2009 at 4:20 PM, Marius Danciu < (marius [dot] danciu [at] gmail [dot] com> wrote:

+1.

FWIW I really don't see what's the big deal with this naming. Does mkString really seams counter-intuitive? I'm not saying naming is not important but in many cases a name can not satisfy everyone's eye for aesthetics. For instance I'm totally ok with mkString, seems very intuitive to me, somehow reminds be of toString etc. ... some people are really bothered about that ... so this is just an endless debate.

Br's,
Marius

On Thu, Jul 23, 2009 at 8:46 PM, Randall R Schulz < (rschulz [at] sonic [dot] net> wrote:

On Thursday July 23 2009, Ken Egervari wrote:
> I would agree with this joining comment. "make" is not a terrible
> world. Perhaps "build" may have been a bit better. I think the
> conceptual association with string builders, and building a string to
> represent the collection conceptually makes sense.
>
> Regardless, this is not a matter of readability... not like the to_s
> method in Ruby (which is an absolute disaster - it means totally
> stupid IMO)
>
> The real concern is writability - having nomenclature that is
> intuitive and consistent so developers can intuitively guess what to
> write and be correct most of the time. Isn't it a great feeling when
> your first guess just works? No compile times? No runtime errors? No
> bugs? It just works.
>
> This, done across the entire platform, really does in fact lessen the
> learning curve. Sure, if mkString in isolation isn't *that* big of a
> deal. Done 50 or 100 times in major parts of the core library - it's
> a different story.
>
> I just think consistency can have very powerful effects on a language
> and how a human interacts with it.

I really disagree. With all of it.

Quality and productivity don't come from how effectively or quickly we
can enter programs at the keyboard. If it did, auto-completion would be
the last word in software development technology. And software goodness
most certainly does not come from being able to guess the name of a
method. Furthermore, what constitutes properly descriptive or intuitive
names is so subjective that every programmer would need his own lexicon
for interacting with the standard libraries, 'cause people just will
not agree on such matters.

And the argument about one or two of these supposedly poorly chosen
names being no big deal but hundreds of them creating a problem
suggests that you have a sufficiently capacious memory that you don't
need to consult the reference documention on a regular basis while
simultaneously implying you have trouble remembering that it's mkString
and not makeString.


This entire obsession with names is truly a frivolous and silly quest.
If you truly would have us to believe that mkString impairs your
productivity or the quality of your code by comparison to what they
would be if it were named makeString, then I think you're admitting to
being a rather inept programmer.


> Ken


Randall Schulz

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

On Thu, Jul 23, 2009 at 10:40 PM, Ken Egervari wrote:
> I respectfully disagree.
So do I.

> With logic, either something is counter-intuitive, or it's not. I've already
> shown that it is - it doesn't follow conventions, so it makes sense that
> it's not 100% intuitive.
IMO in this case intuition dwarfs logic. Intuition is what the neural
net in your brain with its myriads of interconnected cells can
extrapolate out of the all the context it gathered before. I have yet
to see the logic which allows me to accurately infer the name of the
method which connects all the Strings of a list without having used it
before. But then, when I've finally seen mkString the first time, I
was instantly pleased because this is a much needed and used function
and while seemingly having a somewhat awkward name I intuitively liked
mkString because it has the irregularity expected from a much used
verb in a language. This was actually intuitively quite consistent
with what I knew from natural languages. In the end it helped
remembering it.

Speaking of logic, what is needed is an index from signature to method
names to search for functionality. This would potentially be much less
ambigous than what 'educated' guesses can come up with.

Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Johannes Rudolph wrote:
> Speaking of logic, what is needed is an index from signature to method
> names to search for functionality. This would potentially be much less
> ambigous than what 'educated' guesses can come up with.
>
>
This has been discussed on many occasions. Inspired by
http://haskell.org/hoogle/

I have no problem ... disagreements are the heart of good debates.

mk notation is well known I believe (see. mkdir command). Personally I don't find your arguments very compelling besides the rigorous naming convention that you seem to be follow very thoroughly. I'm not saying it is a bad thing ... just that not everyone share this. To go a bit further what about the combinator parser functions like ~, ~>, ^^^ etc. You probably hate those but I love them as it allows to build concise and very expressive parsing code and I really don't need names here that are very expressive. I can;t imagine what woul be to replace

p ~ q with

p combineSequentiallyWith q

.. that would probably keep people away of it :)

Br's,
Marius

On Thu, Jul 23, 2009 at 11:40 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I respectfully disagree.

With logic, either something is counter-intuitive, or it's not. I've already shown that it is - it doesn't follow conventions, so it makes sense that it's not 100% intuitive.

Sure, when reading it, it's fine for the most part. When writing it, especially for a new user of Scala, it is not intuitive. It fights against all the precedence placed before it.

And while some intuition may suggest an association between toString and mkString, it is far less intuitive than the argument for "makeString". If mkString is acceptable, then let's change toString into "tString" then. Why not? We drop vowels from one method name - why not the other? But I guess that would ruin the "fixed-width font" intuition" or "fight against toString() in java.lang.Object" intuition, or whatever other argument you'd like to raise.

The sad fact is that if the method name was named makeString from the very start, I doubt anyone would be fighting to name it to "mkString".

And while this discussion has been about a particular, there is a larger issue here that I and a few others have already commented on - the issue of policy to introduce language changes, the issues of the important of consistency and polish in a core library, and perhaps even a defining the policy for changes and how they get rotated out in a respectful, predictable way.

Ken

On Thu, Jul 23, 2009 at 4:20 PM, Marius Danciu <marius.danciu@gmail.com> wrote:

+1.

FWIW I really don't see what's the big deal with this naming. Does mkString really seams counter-intuitive? I'm not saying naming is not important but in many cases a name can not satisfy everyone's eye for aesthetics. For instance I'm totally ok with mkString, seems very intuitive to me, somehow reminds be of toString etc. ... some people are really bothered about that ... so this is just an endless debate.

Br's,
Marius

On Thu, Jul 23, 2009 at 8:46 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Thursday July 23 2009, Ken Egervari wrote:
> I would agree with this joining comment. "make" is not a terrible
> world. Perhaps "build" may have been a bit better. I think the
> conceptual association with string builders, and building a string to
> represent the collection conceptually makes sense.
>
> Regardless, this is not a matter of readability... not like the to_s
> method in Ruby (which is an absolute disaster - it means totally
> stupid IMO)
>
> The real concern is writability - having nomenclature that is
> intuitive and consistent so developers can intuitively guess what to
> write and be correct most of the time. Isn't it a great feeling when
> your first guess just works? No compile times? No runtime errors? No
> bugs? It just works.
>
> This, done across the entire platform, really does in fact lessen the
> learning curve. Sure, if mkString in isolation isn't *that* big of a
> deal. Done 50 or 100 times in major parts of the core library - it's
> a different story.
>
> I just think consistency can have very powerful effects on a language
> and how a human interacts with it.

I really disagree. With all of it.

Quality and productivity don't come from how effectively or quickly we
can enter programs at the keyboard. If it did, auto-completion would be
the last word in software development technology. And software goodness
most certainly does not come from being able to guess the name of a
method. Furthermore, what constitutes properly descriptive or intuitive
names is so subjective that every programmer would need his own lexicon
for interacting with the standard libraries, 'cause people just will
not agree on such matters.

And the argument about one or two of these supposedly poorly chosen
names being no big deal but hundreds of them creating a problem
suggests that you have a sufficiently capacious memory that you don't
need to consult the reference documention on a regular basis while
simultaneously implying you have trouble remembering that it's mkString
and not makeString.


This entire obsession with names is truly a frivolous and silly quest.
If you truly would have us to believe that mkString impairs your
productivity or the quality of your code by comparison to what they
would be if it were named makeString, then I think you're admitting to
being a rather inept programmer.


> Ken


Randall Schulz

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

[YACT3 = Yet Another Contribution To This Thread]
After a little mkEasy researching at the very good blog http://suereth.blogspot.com/ (hint: Read the caption, which has the feeling of a strong promise) I suddenly realized that Josh doesn't give a damn about naming in Scala or whichever other language and cares only about the essense, or what's "inside".
mkToast or panFryMyToast it is still the toast I want,mkEggs or gimmieTheEggs it is still the egg that matters,mkBacon or brownTheSizzlingBacon it is still the delicious bacon I want to mix with the above
Josh, I gotcha!! (and pray for your sense of humour)
Now, Did we hit the 100 answers mark on this thread?
[Just being in a funny mood today, that's all, no worries...]
[Ken, welcome this this super-mixed, super-interesting (talking about the others mainly and not myself) brain gathering]
Christos.
On Jul 23, 2009, at 11:48 PM, Josh Suereth wrote:

Personally, I think it should stay mkString.  It goes nicely with all the mkToast, mkEggs and mkBacon methods that I use so often.


On Thu, Jul 23, 2009 at 4:40 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

I respectfully disagree.

With logic, either something is counter-intuitive, or it's not. I've already shown that it is - it doesn't follow conventions, so it makes sense that it's not 100% intuitive.

Sure, when reading it, it's fine for the most part. When writing it, especially for a new user of Scala, it is not intuitive. It fights against all the precedence placed before it.

And while some intuition may suggest an association between toString and mkString, it is far less intuitive than the argument for "makeString". If mkString is acceptable, then let's change toString into "tString" then. Why not? We drop vowels from one method name - why not the other? But I guess that would ruin the "fixed-width font" intuition" or "fight against toString() in java.lang.Object" intuition, or whatever other argument you'd like to raise.

The sad fact is that if the method name was named makeString from the very start, I doubt anyone would be fighting to name it to "mkString".

And while this discussion has been about a particular, there is a larger issue here that I and a few others have already commented on - the issue of policy to introduce language changes, the issues of the important of consistency and polish in a core library, and perhaps even a defining the policy for changes and how they get rotated out in a respectful, predictable way.

Ken

On Thu, Jul 23, 2009 at 4:20 PM, Marius Danciu <marius.danciu@gmail.com> wrote:

+1.

FWIW I really don't see what's the big deal with this naming. Does mkString really seams counter-intuitive? I'm not saying naming is not important but in many cases a name can not satisfy everyone's eye for aesthetics. For instance I'm totally ok with mkString, seems very intuitive to me, somehow reminds be of toString etc. ... some people are really bothered about that ... so this is just an endless debate.

Br's,
Marius

On Thu, Jul 23, 2009 at 8:46 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Thursday July 23 2009, Ken Egervari wrote:
> I would agree with this joining comment. "make" is not a terrible
> world. Perhaps "build" may have been a bit better. I think the
> conceptual association with string builders, and building a string to
> represent the collection conceptually makes sense.
>
> Regardless, this is not a matter of readability... not like the to_s
> method in Ruby (which is an absolute disaster - it means totally
> stupid IMO)
>
> The real concern is writability - having nomenclature that is
> intuitive and consistent so developers can intuitively guess what to
> write and be correct most of the time. Isn't it a great feeling when
> your first guess just works? No compile times? No runtime errors? No
> bugs? It just works.
>
> This, done across the entire platform, really does in fact lessen the
> learning curve. Sure, if mkString in isolation isn't *that* big of a
> deal. Done 50 or 100 times in major parts of the core library - it's
> a different story.
>
> I just think consistency can have very powerful effects on a language
> and how a human interacts with it.

I really disagree. With all of it.

Quality and productivity don't come from how effectively or quickly we
can enter programs at the keyboard. If it did, auto-completion would be
the last word in software development technology. And software goodness
most certainly does not come from being able to guess the name of a
method. Furthermore, what constitutes properly descriptive or intuitive
names is so subjective that every programmer would need his own lexicon
for interacting with the standard libraries, 'cause people just will
not agree on such matters.

And the argument about one or two of these supposedly poorly chosen
names being no big deal but hundreds of them creating a problem
suggests that you have a sufficiently capacious memory that you don't
need to consult the reference documention on a regular basis while
simultaneously implying you have trouble remembering that it's mkString
and not makeString.


This entire obsession with names is truly a frivolous and silly quest.
If you truly would have us to believe that mkString impairs your
productivity or the quality of your code by comparison to what they
would be if it were named makeString, then I think you're admitting to
being a rather inept programmer.


> Ken


Randall Schulz

--
Work In Progress - "Dreaming":
http://dl.getdropbox.com/u/443421/Ken_Egervari_-_Dreaming.mp3

My Original Music: http://www.soundclick.com/KenEgervari
My Humorous Speeches: http://www.youtube.com/user/egervari
My Facebook: http://www.new.facebook.com/profile.php?id=716270499/profile.php?id=716270499

-- 
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

On Jul 23, 2009, at 1:48 AM, Randall R Schulz wrote:
>
> Names are arbitrary, of course. It's is only for psychological reasons
> that they matter at all. Of course, since most programmers are people,
> that tends to make it a big deal.

You don't seem to think this is such a big deal. Some people think
otherwise:

http://www.zope.org/Members/shh/ChoosingGoodNames.pdf

S.

--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
New: join the Nuxeo Group on LinkedIn: http://www.linkedin.com/groups?gid=43314

On Jul 23, 2009, at 2:16 AM, Robert James wrote:

On Wed, Jul 22, 2009 at 5:55 PM, someone wrote:

On Wed, Jul 22, 2009 at 05:32:46PM -0400, Ken Egervari wrote:
> I have a comment about List.mkString... is there any reason why it's
> named "mkString" and not "makeString"?

I know four days seems like plenty of time to learn scala well enough to
start pushing for gratuitous sweeping changes in the standard library,
there's actually a six day minimum documented somewhere.

New to Scala, so my post will probably be rejected too, but...:
1. Ad hominem attacks like that build mistrust, arrogance, and isolation, while offering nothing constructive in return. 2. When evaluating usability of a language's nomenclature, it's precisely the opinion of people who've been using the language for 4 days that you want to solicit.  Veterans have been using it long enough that all its quirks and inconsistencies have become second nature.

+1.
  S.
--Stefane Fermigier, Founder and Chairman, NuxeoOpen Source, Java EE based, Enterprise Content Management (ECM)Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87New: follow me on Twitter: http://twitter.com/sfermigierNew: join the Nuxeo Group on LinkedIn: http://www.linkedin.com/groups?gid=43314

On Jul 23, 2009, at 10:57 PM, Rudi Engelbrecht wrote:

> I think you have hit the nail on the head.
>
> Up till the start of this thread I was very impressed by Scala (and
> community).

>
> It has been dented a bit - due to this thread.

Same for me.

It takes only one rotten apple to corrupt a bunch.

S.

--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
New: join the Nuxeo Group on LinkedIn: http://www.linkedin.com/groups?gid=43314

On Fri, Jul 24, 2009 at 01:57:01PM +0200, Stefane Fermigier wrote:
> It takes only one rotten apple to corrupt a bunch.

This I think is the final straw. Consider me on indefinite vacation
until/unless I can find a way to reconcile the shameless level of
ingratitude displayed in this thread with the amount of work left to be
done. Like everyone else, this thread has diminished my estimation of
the scala community, but we are not applying the same reasoning.

Ken,The "official" process for submitting improvements to Scala is a SID.
http://www.scala-lang.org/node/233
One thing you'll notice in the FAQ is that SIDs are not feature requests.  They are documentation for a change that you already for which you already have a solid understanding.  I think before submitting a SID it's best to have at least a partially functional implementation.
If you want you suggestion to be taken a little more seriously (or in some cases, a little less offense taken at it), you should fork  Paul's Scala repo on GitHub http://github.com/paulp/scala/tree/master, make your suggested changes, and then post your proposal to scala-internals along with a link to your repo.  That way the the discussion can center around the merits of the proposal without being clouded by the availability of implementation resources and relative priority of the change.  The fact that you took the time to make the change will show that you are serious and care enough to be personally vested.  If committers like it, someone can pull from your repo and apply the patch to the main subversion repository without too much effort.
-Erik
PS - I prefer mkString, but think it's entirely a matter of personal taste, and therefore regardless would err on the side of not breaking downstream code

On Wed, Jul 22, 2009 at 5:32 PM, Ken Egervari <ken.egervari@gmail.com> wrote:

Hi ;)

I have a comment about List.mkString... is there any reason why it's named "mkString" and not "makeString"?

One of the reasons I personally don't like languages such as PHP and Ruby is that there is often NO consistency to their library design. If there was a "make string"-like function, it could be implemented as mk_string, mkstring, mkString, MkString, make_string... or any other combination. It's impossible to "guess" intuitively what it is.

In Ruby, toString is actually to_s(). When I first saw this... I was like, "What the hell is that?" A seasoned developer like me actually had to resort to the APIs to find out what that could be. And that's supposed to be easy? I don't understand this approach to library design. IDEs type out the name, and most people who've been typing for awhile can easily type "toString" about as fast as "to_s".

Thankfully, Scala is not like this. I just use Ruby as an example.

However, as I use lists in Scala, I accidentally used "mkstring"... thinking it was correct because my brain only remembered that much of the name. Of course, I get a compile-time error. Sure, it's easily fixed. I just think Scala should be more consistent in its own apis, so this would never have happened in the first place.

For example, it's a lot easier to remember conventions of camel-case notation, and then just remember two concepts "make" and "string" to formalize the whole method name. This is much easier than remembering "mkString"... because even though it's shorter to type, there is actually more information to remember. If we multiply this effort across many method names, this can make a language harder to use/adopt.

And since we're using mkString, why did we not use fltMap instead of flatMap? Or rvrs instead of reverse? There is a consistency problem here.

So... I ask: is there any reason we are not using makeString? I think if we make this change, as well as any others like it, it would be a step in a positive direction.

All the best,
Ken

--
http://erikengbrecht.blogspot.com/

Dear Paul,

i noticed a long time ago that i only complain about things i genuinely admire and care about. Things that are really rotten i just ignore. i say -- without reservation -- the work on Scala is really amazing. Moreover, i have been grateful for the stimulating and fantastically responsive community.

i have a lot of complaints about Scala, but -- as someone who has shipped commercial code and knows that work that garners attention of the market is almost always met with a chorus of complaints and suggestions for "improvement" from people who have not invested years of their life to understand the domain -- these are loving complaints about something i have become increasingly invested in and plan to become even more invested in.

Best wishes,

--greg

On Fri, Jul 24, 2009 at 5:49 AM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Jul 24, 2009 at 01:57:01PM +0200, Stefane Fermigier wrote:
> It takes only one rotten apple to corrupt a bunch.

This I think is the final straw.  Consider me on indefinite vacation
until/unless I can find a way to reconcile the shameless level of
ingratitude displayed in this thread with the amount of work left to be
done.  Like everyone else, this thread has diminished my estimation of
the scala community, but we are not applying the same reasoning.

--
Paul Phillips      | Adultery is the application of democracy to love.
Moral Alien        |     -- H. L. Mencken
Empiricist         |
i'll ship a pulp   |----------* http://www.improving.org/paulp/ *----------

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com