Library Change Request

Is there any reason to adhere to an English dictionary as the authority
on "consistency"?

One of the advantages of functional programming is the ability to assign
your own "building block" without affecting your program.

Type annotations aside:
def makeString = _.mkString

Ken Egervari 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

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.

On Wed, Jul 22, 2009 at 10:55 PM, Paul Phillips 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.

Maybe in a couple days he'll come back and ask you if you think the
change he's proposing (with quite a plausible argument, I would say)
is more or less gratuitous than the recent renaming of elements to
iterator.

Cheers,

Miles

On Wed, Jul 22, 2009 at 5:55 PM, Paul Phillips 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.

Can you pull from the vault of your experience to explain why he's wrong?

David Saff

On Wednesday July 22 2009, David Saff wrote:
> On Wed, Jul 22, 2009 at 5:55 PM, Paul Phillips
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.
>
> Can you pull from the vault of your experience to explain why he's
> wrong?

Well, "make" has some unpleasant connotations... I think it should be:

synthesizeTextualRepresentation()

Don't you?

> David Saff

RRS

On Jul 22, 2009, at 6:38 PM, Randall R Schulz wrote:
> Well, "make" has some unpleasant connotations... I think it should be:
>
> synthesizeTextualRepresentation()
>
> Don't you?

It's not very descriptive. Perhaps

concatenateSerializableAndDeserializableStringifiedImageTextThing //
can drop () for brevity

It's not a question that "make" is a poor choice in wording... although perhaps "buildString" is perhaps a bit more direct and effective because of the conceptual associate with classes like StringBuilder.

Really, it's a question of consistency. "mkString" suggests a convention that we drop the vowels from the first word of a method name, but we should keep the vowels for the second, third, * parts of a method name. If you want to follow this style, then the other method names should be fltMap() and rvrs().

That's all I'm saying. That's the real confusing part. That's why I think my point has some validity. If you want to call it buildString or makeString, be my guest. My concern is the naming convention and how it doesn't follow the other method names in List, or most other conventions set by Scala and Java. It sticks out like a sore thumb.

Of course, I now realize that I need to belong to the list for many more months for the same argument to be correct. I get it. No biggie.

Ken

On Wed, Jul 22, 2009 at 6:38 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Wednesday July 22 2009, David Saff wrote:
> On Wed, Jul 22, 2009 at 5:55 PM, Paul Phillips<paulp@improving.org>
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.
>
> Can you pull from the vault of your experience to explain why he's
> wrong?

Well, "make" has some unpleasant connotations... I think it should be:

 synthesizeTextualRepresentation()

Don't you?


>    David Saff


RRS

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

> It's not a question that "make" is a poor choice in wording...
> although perhaps "buildString" is perhaps a bit more direct and
> effective because of the conceptual associate with classes like
> StringBuilder.
>
> Really, it's a question of consistency. "mkString" suggests a
> convention that we drop the vowels from the first word of a method
> name, but we should keep the vowels for the second, third, * parts
> of a method name. If you want to follow this style, then the other
> method names should be fltMap() and rvrs().
>
> That's all I'm saying. That's the real confusing part. That's why I
> think my point has some validity. If you want to call it buildString
> or makeString, be my guest. My concern is the naming convention and
> how it doesn't follow the other method names in List, or most other
> conventions set by Scala and Java. It sticks out like a sore thumb.

FWIW, I think you make a very valid point.

> Of course, I now realize that I need to belong to the list for many
> more months for the same argument to be correct. I get it. No biggie.

Indeed ... I think it's a bit of an unfortunate first-ish impression
to have received from the scala community.

-steve

Hi Ken,

On Wed, 2009-07-22 at 19:30 -0400, Ken Egervari wrote:
> My concern is the naming convention and how it doesn't follow the
> other method names in List, or most other conventions set by Scala and
> Java. It sticks out like a sore thumb.

This is not the only example. There are others where consistency is
lacking. An example is foreach (should be forEach, right?). But this is
not my main point.

> Of course, I now realize that I need to belong to the list for many
> more months for the same argument to be correct. I get it. No biggie.

I think most of the responses in this thread were not particularly
constructive, but your argument would contain the same flaws a few
months from now. In fact, probably more.

As a seasoned developer (as you described yourself in the original
message), you surely understand that changes like these have a cost. If
we want to avoid breaking compatibility, we may deprecate mkString and
add makeString. Suddenly lots of people have to change their code. Is it
really worth it? An alternative is to simply have both, but that may
cause even more confusion. And so on.

The truth is that there are many other items of higher priority that
need to be tackled before this one. In my understanding, Paul was just
saying that it may help to get a bit more familiar with Scala (and where
it needs improvement the most) before proposing such wide-ranging
changes. I also think he could have expressed it better, but then again
I am not the one fixing all the bugs so that 2.8.0 has a chance of being
released sometime this year. If I were, maybe I'd have reacted the same
way. :)

Best,
Ismael

On Wednesday July 22 2009, Ken Egervari wrote:
> It's not a question that "make" is a poor choice in wording... ...
>
> Really, it's a question of consistency. ...
>
> That's all I'm saying. That's the real confusing part. That's why I
> think my point has some validity. If you want to call it buildString
> or makeString, be my guest.

I venture to guess that most of us (and, I daresay, 100% of those in a
position to make the change you request) want not to change the name of
that method or of any similarly named method.

> My concern is the naming convention and how it doesn't follow the
> other method names in List, or most other conventions set by Scala and
> Java. It sticks out like a sore thumb.

Perhaps this "convention" you speak of is of your own imagining?

Anyway, learning a new language and its attendant standard libraries
always involves learning both general patterns and specific facts. You
cannot reduce the specific facts part to zero. It's just that when you
first start out, you'd like to just learn general patterns and not be
bothered with that stuff that's essentially arbitrary (and I do mean
_essentially_ arbitrary, not incidentally arbitrary). If you just tough
it out, you'll wonder why these things bothered you so much at all.

> Of course, I now realize that I need to belong to the list for many
> more months for the same argument to be correct. I get it. No biggie.

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.

Nonetheless, I surely hope you don't think that it is even remotely
feasible to make the change you suggest at this point, with literally
millions of lines of Scala code already written.

Lastly, the only large systems in which the kind of consistency you
advocate exists are those designed by committee. They tend to have
other problems.

> Ken

Randall Schulz

Hi Ismael!

Yes, I really do believe that it's worth making a breaking change at this point. As far as I know, there has been breaking changes made to Scala in the recent past, so I don't see why there shouldn't be breaking changes in the near future.

The cost right now to make these changes are relatively cheap. Imagine Scala becoming as popular as Java one day... and THEN we present the same argument to change mkString then? Really imagine that. At that time, it really will be impossible.

I say make the change now when very few people are using the language in production code. Like Martin said in his keynote... there has only been 50,000 downloads of Scala. 50,000! Why not make those changes now before we get 500,000 downloads? 5,000,000 downloads?

There's also a bigger lesson here. People have been absolutely begging to dump archaic language features and libraries out of Java for some time now. And people have been requesting new language features, like closures, as well. Unfortunately, Sun has took a very, very firm position that their language and core library should be "backwards compatible".

In some ways, I can see their point - especially now that the language has been around for over a decade. On the flip side, I don't see a problem with older apps being forced to use older VMs while newer VMs carry over the breaking changes. To each their own. This is not all that important.

What is important is that Scala is new. Scala is such a breath of fresh air. It gives us that second chance to iron out these details before it has mass adoption, and to learn from what has came before. Why not take advantage of that and make it the best we can make it in every fashion possible?

To accept the same argument so early when very few production applications have been built in Scala will be somewhat detrimental in the long term. If we set this precedent so soon, I fear will have similar problems that we already have with Java now. Why not change the policy for the better?

Lastly, we really are in a world where code and ideas are changing. Applications change every day. Servers go up and down in the cloud by the minute. It's not the same world that Java was originally created in. We are in a new world now. Are we courageous enough to be apart of it? 

Being stubborn, rejecting ideas and restrictive isn't going to help us.

I guess time will tell though, won't it?

Ken

On Wed, Jul 22, 2009 at 7:43 PM, Ismael Juma <mlists@juma.me.uk> wrote:

Hi Ken,

On Wed, 2009-07-22 at 19:30 -0400, Ken Egervari wrote:
> My concern is the naming convention and how it doesn't follow the
> other method names in List, or most other conventions set by Scala and
> Java. It sticks out like a sore thumb.

This is not the only example. There are others where consistency is
lacking. An example is foreach (should be forEach, right?). But this is
not my main point.

> Of course, I now realize that I need to belong to the list for many
> more months for the same argument to be correct. I get it. No biggie.

I think most of the responses in this thread were not particularly
constructive, but your argument would contain the same flaws a few
months from now. In fact, probably more.

As a seasoned developer (as you described yourself in the original
message), you surely understand that changes like these have a cost. If
we want to avoid breaking compatibility, we may deprecate mkString and
add makeString. Suddenly lots of people have to change their code. Is it
really worth it? An alternative is to simply have both, but that may
cause even more confusion. And so on.

The truth is that there are many other items of higher priority that
need to be tackled before this one. In my understanding, Paul was just
saying that it may help to get a bit more familiar with Scala (and where
it needs improvement the most) before proposing such wide-ranging
changes. I also think he could have expressed it better, but then again
I am not the one fixing all the bugs so that 2.8.0 has a chance of being
released sometime this year. If I were, maybe I'd have reacted the same
way. :)

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

Hi,

On Wed, 2009-07-22 at 16:48 -0700, Randall R Schulz wrote:
> I venture to guess that most of us (and, I daresay, 100% of those in a
> position to make the change you request) want not to change the name of
> that method or of any similarly named method.

I would guess your guess is wrong if we were starting from a blank
slate. :)

> Nonetheless, I surely hope you don't think that it is even remotely
> feasible to make the change you suggest at this point, with literally
> millions of lines of Scala code already written.

Sorry, I could not resist. What about that change from elements to
iterator that Miles pointed out? As I said in the other message, I don't
think it's worth making this change now (or maybe ever), but this
argument is weak in the face of the many renames and deprecations that
have happened in the new collections. And many of those were done in the
name of consistency too.

Best,
Ismael

Personally, I share your skepticism of small abbreviations like "mk" for
"make".

- For me, programming long ago stopped being about how fast I can type
(fortunately).
- Most code is read more than written. To me, makeString() reads a
little easier than mkString().

Ultimately though, IMO its not a big issue and you get used to it. And
truly, its not going to change!

While the importance of your personal preferences to the Scala community
is naturally a function of your length of involvement and contribution,
the validity of your arguments should ideally be examined independently
of that.

-Ben

Ken Egervari 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
>
>

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.

Hi Ken,

Instead of replying to your post point by point, I will just say that
you ignored the most important part of my message. I said that there
were many more issues of higher priority that need to be fixed. Unless
you're volunteering to fix them, your proposed change will have to
wait. :)

Ismael

I think a fine precedent in the art of choosing names is the laborious
work people do over to google collections, along with Bloch and
others. They are obsessed with getting the names absolutely right,
using feedback from literally hundreds of developers, and experiment
for years and still they haven't completely froze their api. The point
being - the thing is going to be used millions of times, and just a
minor annoyance here or there can make a huge difference overall.

In the mkString case, I guess that someone carelessly picked a short
name he liked, most probably with no or insignificant feedback from
anyone else, which is understandable (probably several years ago). I
wish such issues were somehow evolvable (this is still a relatively
small community and the impact is not unmanageable), but for this one
it's probably too late to change.

Dimitris

2009/7/23 Ken Egervari :
> Hi Ismael!
>
> Yes, I really do believe that it's worth making a breaking change at this
> point. As far as I know, there has been breaking changes made to Scala in
> the recent past, so I don't see why there shouldn't be breaking changes in
> the near future.
>
> The cost right now to make these changes are relatively cheap. Imagine Scala
> becoming as popular as Java one day... and THEN we present the same argument
> to change mkString then? Really imagine that. At that time, it really will
> be impossible.
>
> I say make the change now when very few people are using the language in
> production code. Like Martin said in his keynote... there has only been
> 50,000 downloads of Scala. 50,000! Why not make those changes now before we
> get 500,000 downloads? 5,000,000 downloads?
>
> There's also a bigger lesson here. People have been absolutely begging to
> dump archaic language features and libraries out of Java for some time now.
> And people have been requesting new language features, like closures, as
> well. Unfortunately, Sun has took a very, very firm position that their
> language and core library should be "backwards compatible".
>
> In some ways, I can see their point - especially now that the language has
> been around for over a decade. On the flip side, I don't see a problem with
> older apps being forced to use older VMs while newer VMs carry over the
> breaking changes. To each their own. This is not all that important.
>
> What is important is that Scala is new. Scala is such a breath of fresh air.
> It gives us that second chance to iron out these details before it has mass
> adoption, and to learn from what has came before. Why not take advantage of
> that and make it the best we can make it in every fashion possible?
>
> To accept the same argument so early when very few production applications
> have been built in Scala will be somewhat detrimental in the long term. If
> we set this precedent so soon, I fear will have similar problems that we
> already have with Java now. Why not change the policy for the better?
>
> Lastly, we really are in a world where code and ideas are changing.
> Applications change every day. Servers go up and down in the cloud by the
> minute. It's not the same world that Java was originally created in. We are
> in a new world now. Are we courageous enough to be apart of it?
>
> Being stubborn, rejecting ideas and restrictive isn't going to help us.
>
> I guess time will tell though, won't it?
>
> Ken
>
> On Wed, Jul 22, 2009 at 7:43 PM, Ismael Juma wrote:
>>
>> Hi Ken,
>>
>> On Wed, 2009-07-22 at 19:30 -0400, Ken Egervari wrote:
>> > My concern is the naming convention and how it doesn't follow the
>> > other method names in List, or most other conventions set by Scala and
>> > Java. It sticks out like a sore thumb.
>>
>> This is not the only example. There are others where consistency is
>> lacking. An example is foreach (should be forEach, right?). But this is
>> not my main point.
>>
>> > Of course, I now realize that I need to belong to the list for many
>> > more months for the same argument to be correct. I get it. No biggie.
>>
>> I think most of the responses in this thread were not particularly
>> constructive, but your argument would contain the same flaws a few
>> months from now. In fact, probably more.
>>
>> As a seasoned developer (as you described yourself in the original
>> message), you surely understand that changes like these have a cost. If
>> we want to avoid breaking compatibility, we may deprecate mkString and
>> add makeString. Suddenly lots of people have to change their code. Is it
>> really worth it? An alternative is to simply have both, but that may
>> cause even more confusion. And so on.
>>
>> The truth is that there are many other items of higher priority that
>> need to be tackled before this one. In my understanding, Paul was just
>> saying that it may help to get a bit more familiar with Scala (and where
>> it needs improvement the most) before proposing such wide-ranging
>> changes. I also think he could have expressed it better, but then again
>> I am not the one fixing all the bugs so that 2.8.0 has a chance of being
>> released sometime this year. If I were, maybe I'd have reacted the same
>> way. :)
>>
>> 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=7162...
>

I totally agree with both of these statements.

Thank you.

On Wed, Jul 22, 2009 at 8:16 PM, Robert James <srobertjames@gmail.com> 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.

--
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 Wednesday July 22 2009, Ismael Juma wrote:
> Hi,
>
> On Wed, 2009-07-22 at 16:48 -0700, Randall R Schulz wrote:
> > I venture to guess that most of us (and, I daresay, 100% of those
> > in a position to make the change you request) want not to change
> > the name of that method or of any similarly named method.
>
> I would guess your guess is wrong if we were starting from a blank
> slate. :)

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

> > Nonetheless, I surely hope you don't think that it is even remotely
> > feasible to make the change you suggest at this point, with
> > literally millions of lines of Scala code already written.
>
> Sorry, I could not resist. What about that change from elements to
> iterator that Miles pointed out? As I said in the other message, I
> don't think it's worth making this change now (or maybe ever), but
> this argument is weak in the face of the many renames and
> deprecations that have happened in the new collections. And many of
> those were done in the name of consistency too.

I still type "iterator" when writing Scala code, despite being rebuked
when compiling. Getting the names of things wrong when writing code
doesn't bother me much (even though at this point my IDE's in-editor
error checking doesn't flag undefined methods in Scala as it does in
Java). On the other hand, I would be less favorably disposed towards
having working code broken by a "fix" for inconsistent naming in the
standard library.

I've not followed the library changes for 2.8 very closely. I did note
(prompted by Martin's remarks about what he considers a very poor
implementation of mutable.Stack in 2.7) that there are breaking changes
in the 2.8 counterpart, and these are not name changes, these are
changes to the semantics of some of the methods.

Ultimately, names just aren't important enough to me to get me bothered.
As I said before, every large system that did not either spring
full-blown from the mind of Zeus or from some enlightened committee of
learned citizens has had a lot of this sort of idiosyncratic naming.

If the name was completely non-indicative of what the method did, it
would bear changing, but in my opinion not otherwise.

> Best,
> Ismael

Randall Schulz

Randall, the point of contention is not "just get used to it", as you've stated a few times. Sure, I can get used to it. In fact, I already am used to it.

The real problem is that Bill, Joe, Gerry, Mary, Sue, Leeann, and 5,000,000 more people have to deal with the same thing at some point.

And as already pointed out, it's not just mkString - this kind of problem happens with several other method names.

Again, if such breaking changes are already being made for Iterators, why not Lists? If the leads of the designers are setting this precedent, why not follow it through? Or are we going to apply it to some core parts of the language and not others?

While I don't suggest that we keep the core library in an unfrozen,beta state for 5 years, I am suggesting that freezing it immediately after it's been rolled into production is also a bit extreme. There has to be a middle-ground. And for the time being, fixing some things that have long been overdue isn't such a bad idea until a good policy is in place.

Ken

On Wed, Jul 22, 2009 at 8:36 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Wednesday July 22 2009, Ismael Juma wrote:
> Hi,
>
> On Wed, 2009-07-22 at 16:48 -0700, Randall R Schulz wrote:
> > I venture to guess that most of us (and, I daresay, 100% of those
> > in a position to make the change you request) want not to change
> > the name of that method or of any similarly named method.
>
> I would guess your guess is wrong if we were starting from a blank
> slate. :)

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


> > Nonetheless, I surely hope you don't think that it is even remotely
> > feasible to make the change you suggest at this point, with
> > literally millions of lines of Scala code already written.
>
> Sorry, I could not resist. What about that change from elements to
> iterator that Miles pointed out? As I said in the other message, I
> don't think it's worth making this change now (or maybe ever), but
> this argument is weak in the face of the many renames and
> deprecations that have happened in the new collections. And many of
> those were done in the name of consistency too.

I still type "iterator" when writing Scala code, despite being rebuked
when compiling. Getting the names of things wrong when writing code
doesn't bother me much (even though at this point my IDE's in-editor
error checking doesn't flag undefined methods in Scala as it does in
Java). On the other hand, I would be less favorably disposed towards
having working code broken by a "fix" for inconsistent naming in the
standard library.

I've not followed the library changes for 2.8 very closely. I did note
(prompted by Martin's remarks about what he considers a very poor
implementation of mutable.Stack in 2.7) that there are breaking changes
in the 2.8 counterpart, and these are not name changes, these are
changes to the semantics of some of the methods.

Ultimately, names just aren't important enough to me to get me bothered.
As I said before, every large system that did not either spring
full-blown from the mind of Zeus or from some enlightened committee of
learned citizens has had a lot of this sort of idiosyncratic naming.

If the name was completely non-indicative of what the method did, it
would bear changing, but in my opinion not otherwise.


> Best,
> Ismael


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 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). Particularly
when taking into account the "synthesizeTextualRepresentation" joke.

> I still type "iterator" when writing Scala code, despite being rebuked
> when compiling. Getting the names of things wrong when writing code
> doesn't bother me much (even though at this point my IDE's in-editor
> error checking doesn't flag undefined methods in Scala as it does in
> Java).

I'd rather type it correctly the first time (and generally do so), but
each to his own.

> I've not followed the library changes for 2.8 very closely. I did note
> (prompted by Martin's remarks about what he considers a very poor
> implementation of mutable.Stack in 2.7) that there are breaking changes
> in the 2.8 counterpart, and these are not name changes, these are
> changes to the semantics of some of the methods.

I don't know what point you're trying to make. I gave an example of a
name change (and there were many deprecations of methods like first,
make and others).

> Ultimately, names just aren't important enough to me to get me bothered.

But they are for some Scala committers if the new collections are any
indication.

> If the name was completely non-indicative of what the method did, it
> would bear changing, but in my opinion not otherwise.

I agree with the gist of this, but that is not how you had phrased it
initially.

Best,
Ismael

On 7/22/2009 7:36 PM, Randall R Schulz wrote:
>
> On the other hand, I would be less favorably disposed towards
> having working code broken by a "fix" for inconsistent naming in the
> standard library.
Hi, all,

This is how deprecations work, of course. I think that people have lost
faith in
them because of Java's inability to ever remove anything that has been
marked
as deprecated. Since Scala is still fresh and new, though, it has an
opportunity
to handle them more fastidiously. Maybe the compiler (or some tool?) can
perform special handling of code in which the only deprecated part is the
symbol name? Just IMHO.

Many thanks and appreciation to the developers who are sweating and
struggling
to get 2.8 out. I'm sure it is extremely frustrating for them to read
some of the posts
here when they are trying to staying focused on the huge amount of work
still to be done.
Having worked "crunch time" on projects many times in the past, I know that
their responses are purely from exhaustion, not being impolite to any
newcomers.
We owe them a lot.

bob
(ishmal on irc/xmpp)

Hi Bob,

I wholeheartedly agree with you.

It would be interesting to have a build system automatically not include depreciated methods after a certain version number. For example if a @depricated annotation had a field with (version="2.7.5"), the build system/compiler would automatically not include the method at version 2.9 (just as an example... I'm not suggesting a specific policy). That way an effort could be made to change all references from mkString to makeString... and it would give people a determinable amount of time to make their own updates. It would also be possible to automatically generate a list of things that will be rolled out in the next release to give people a clear "heads up". That would give a policy that people could trust and respect and abide by.

It's good to have a dream ;)

Ken

On Wed, Jul 22, 2009 at 8:52 PM, Bob Jamison <ishmalius@gmail.com> wrote:

 On 7/22/2009 7:36 PM, Randall R Schulz wrote:

On the other hand, I would be less favorably disposed towards
having working code broken by a "fix" for inconsistent naming in the
standard library.

Hi, all,


This is how deprecations work, of course.  I think that people have lost faith in
them because of Java's inability to ever remove anything that has been marked
as deprecated.  Since Scala is still fresh and new, though, it has an opportunity
to handle them more fastidiously.  Maybe the compiler (or some tool?) can
perform special handling of code in which the only deprecated part is the
symbol name?  Just IMHO.

Many thanks and appreciation to the developers who are sweating and struggling
to get 2.8 out.  I'm sure it is extremely frustrating for them to read some of the posts
here when they are trying to staying focused on the huge amount of work still to be done.
Having worked "crunch time" on projects many times in the past, I know that
their responses are purely from exhaustion, not being impolite to any newcomers.
We owe them a lot.



bob
(ishmal on irc/xmpp)

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

> ...
>
> > I've not followed the library changes for 2.8 very closely. I did
> > note (prompted by Martin's remarks about what he considers a very
> > poor implementation of mutable.Stack in 2.7) that there are
> > breaking changes in the 2.8 counterpart, and these are not name
> > changes, these are changes to the semantics of some of the methods.
>
> I don't know what point you're trying to make. I gave an example of a
> name change (and there were many deprecations of methods like first,
> make and others).

The point is that mere name changes are insignificant by comparison to
silent breaking changes. Those are far more worth discussing.

Are these changes enumerated somewhere?

Just to be clear, I support the changes in the semantics of Stack, but I
would have been blind-sided by them had it not been for an offhand
remark from Martin about his opinion of the 2.7 Stack code.

> ...
>
> > If the name was completely non-indicative of what the method did,
> > it would bear changing, but in my opinion not otherwise.
>
> I agree with the gist of this, but that is not how you had phrased it
> initially.

How I phrased what?

> Best,
> Ismael

Randall Schulz

I don't think that any significance can be salvaged from this thread
even by the wisest men. It's a sign of a mature language to argue
about such things -- a task for Ada Rapporteur Group! :) Heck, define
all library names as 'symbols in scalac build and let the user remap
them. Refer to them by the 'symbol1234number. Translate them into
Albanian and Zulu! Or cut the losses and move on, that's what mine
reply meant (after Randy's:...) -- mkNoMistake!

Cheers,
Alexy

On Wed, Jul 22, 2009 at 9:30 PM, 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.
>
>
>> ...
>>
>> > I've not followed the library changes for 2.8 very closely. I did
>> > note (prompted by Martin's remarks about what he considers a very
>> > poor implementation of mutable.Stack in 2.7) that there are
>> > breaking changes in the 2.8 counterpart, and these are not name
>> > changes, these are changes to the semantics of some of the methods.
>>
>> I don't know what point you're trying to make. I gave an example of a
>> name change (and there were many deprecations of methods like first,
>> make and others).
>
> The point is that mere name changes are insignificant by comparison to
> silent breaking changes. Those are far more worth discussing.
>
> Are these changes enumerated somewhere?
>
> Just to be clear, I support the changes in the semantics of Stack, but I
> would have been blind-sided by them had it not been for an offhand
> remark from Martin about his opinion of the 2.7 Stack code.
>
>
>> ...
>>
>> > If the name was completely non-indicative of what the method did,
>> > it would bear changing, but in my opinion not otherwise.
>>
>> I agree with the gist of this, but that is not how you had phrased it
>> initially.
>
> How I phrased what?

When you said "Yes, I understand how this might be, for some new Scala
developers, a somewhat jarring inconsistency, and given a time
machine, many might vote to choose a different name. However, I'm
sure you understand that there's a cost in all changes, including the
social cost of consensus, and if you stick around a little bit, you'll
see that this is a community that is spending that capital on
constructively tackling some bigger language problems. That said,
thanks for your valuable feedback!"

Or maybe one of the other early responders said that.

Or maybe I misread.

David Saff

>
>
>> Best,
>> Ismael
>
>
> Randall Schulz
>

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.

> The point is that mere name changes are insignificant by comparison to
> silent breaking changes. Those are far more worth discussing.

Certainly silent breaking changes are more significant, but I would not
phrase it like that.

> Are these changes enumerated somewhere?

I don't know.

> > > If the name was completely non-indicative of what the method did,
> > > it would bear changing, but in my opinion not otherwise.
> >
> > I agree with the gist of this, but that is not how you had phrased it
> > initially.
>
> How I phrased what?

Your whole message about why it was a bad idea.

Ismael

Errr, if you did the below, wouldn't that be Perl6?

DSL

-----Original Message-----
From: Alexy Khrabrov <3cdeliverable [at] gmail [dot] com%3e" rel="nofollow">deliverable@gmail.com>
To: Randall R Schulz <3crschulz [at] sonic [dot] net%3e" rel="nofollow">rschulz@sonic.net>
Cc: scala@listes.epfl.ch
Subject: Re: [scala] Library Change Request
Date: Wed, 22 Jul 2009 21:43:13 -0400

I don't think that any significance can be salvaged from this thread  
even by the wisest men.  It's a sign of a mature language to argue  
about such things -- a task for Ada Rapporteur Group! :) Heck, define  
all library names as 'symbols in scalac build and let the user remap  
them.  Refer to them by the 'symbol1234number.  Translate them into  
Albanian and Zulu!  Or cut the losses and move on, that's what mine  
reply meant (after Randy's:...) --  mkNoMistake!

Cheers,
Alexy

On Wednesday July 22 2009, David Saff wrote:
> On Wed, Jul 22, 2009 at 9:30 PM, Randall R Schulz
wrote:
> > On Wednesday July 22 2009, Ismael Juma wrote:
> >> ...
> >>
> >> > If the name was completely non-indicative of what the method
> >> > did, it would bear changing, but in my opinion not otherwise.
> >>
> >> I agree with the gist of this, but that is not how you had phrased
> >> it initially.
> >
> > How I phrased what?
>
> When you said "Yes, I understand how this might be, for some new
> Scala developers, a somewhat jarring inconsistency, and given a time
> machine, many might vote to choose a different name. However, I'm
> sure you understand that there's a cost in all changes, including the
> social cost of consensus, and if you stick around a little bit,
> you'll see that this is a community that is spending that capital on
> constructively tackling some bigger language problems. That said,
> thanks for your valuable feedback!"

You used quote marks, but I wrote no such words. Nor do I believe they
particularly well paraphrase anything I did write.

> Or maybe one of the other early responders said that.
>
> Or maybe I misread.
>
> David Saff

Randall Schulz

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?

> ...
>
> Ismael

Randall Schulz

On Wednesday July 22 2009, David Saff wrote:
> On Wed, Jul 22, 2009 at 9:30 PM, Randall R Schulz wrote:
> > On Wednesday July 22 2009, Ismael Juma wrote:
> >> ...
> >>
> >> > If the name was completely non-indicative of what the method
> >> > did, it would bear changing, but in my opinion not otherwise.
> >>
> >> I agree with the gist of this, but that is not how you had phrased
> >> it initially.
> >
> > How I phrased what?
>
> When you said "Yes, I understand how this might be, for some new
> Scala developers, a somewhat jarring inconsistency, and given a time
> machine, many might vote to choose a different name. However, I'm
> sure you understand that there's a cost in all changes, including the
> social cost of consensus, and if you stick around a little bit,
> you'll see that this is a community that is spending that capital on
> constructively tackling some bigger language problems. That said,
> thanks for your valuable feedback!"

Just for kicks, would you paraphrase the original post? It might make
for an interesting (or amusing) comparison.

> ...
>
> David Saff

RRS

On Wed, 2009-07-22 at 19:28 -0700, Randall R Schulz wrote:
> On Wednesday July 22 2009, David Saff wrote:
> > On Wed, Jul 22, 2009 at 9:30 PM, Randall R Schulz
> wrote:
> > > On Wednesday July 22 2009, Ismael Juma wrote:
> > >> ...
> > >>
> > >> > If the name was completely non-indicative of what the method
> > >> > did, it would bear changing, but in my opinion not otherwise.
> > >>
> > >> I agree with the gist of this, but that is not how you had phrased
> > >> it initially.
> > >
> > > How I phrased what?
> >
> > When you said "Yes, I understand how this might be, for some new
> > Scala developers, a somewhat jarring inconsistency, and given a time
> > machine, many might vote to choose a different name. However, I'm
> > sure you understand that there's a cost in all changes, including the
> > social cost of consensus, and if you stick around a little bit,
> > you'll see that this is a community that is spending that capital on
> > constructively tackling some bigger language problems. That said,
> > thanks for your valuable feedback!"
>
> You used quote marks, but I wrote no such words. Nor do I believe they
> particularly well paraphrase anything I did write.

You know, you were talking about humour earlier... ;)

Ismael

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

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

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.

Cheers,

Miles

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.

Ismael

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.
>
> Ismael
>
>
>
When I was working for IBM, I used a home-grown build tool called ODE.
It had a command called 'mk'. It was a disaster as per IBM.

I am so much using Makefiles these days that I have an

alias mk=make

If things keep going on in the same lines, I will probably

alias m=mk

But I think it is safe to assume that "mkString" will never make it to
"ms" or even "mstr" :)

Christos

On Jul 23, 2009, at 2:59 PM, Tony Morris wrote:

> 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.
>>
>> Ismael
>>
>>
>>
> When I was working for IBM, I used a home-grown build tool called ODE.
> It had a command called 'mk'. It was a disaster as per IBM.
>

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
>

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
>

So now we name things that look aligned when close to each other in a fixed-width font?

:/

On Thu, Jul 23, 2009 at 6:36 AM, Miles Sabin <miles@milessabin.com> wrote:

On Thu, Jul 23, 2009 at 9: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.

FWIW, I strongly suspect that mkString was named with one eye on
toString ... so it's not _entirely_ unmotivated.

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

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

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

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

Unfortunately, Sun has took a very, very firm position that their language and core library should be "backwards compatible".

Didn't they deprecate a lot of method names with lower case 'url' and replaced them with 'URL'?

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

2009/7/23 Randall R Schulz :

> This entire obsession with names is truly a frivolous and silly quest.
>
> Randall Schulz

I'm flabbergasted. You'll have to educate many people of the highest
level working on jdk and in google, since they obviously lose their
time and money on such silly quests. Inconsistent names mean loss of
time on a regular basis and frustration. Intuitive and consistent
names => much easier to remember, use and reason about. Unless of
course we talk for about just a handful of users, when all arguments
end in a "it doesn't matter". I'm sure you wish scala libraries to
attain many more users than that, so please don't judge library code
with the same lenses as run-of-the-mill application code, where
nothing (be it api design, names chosen, or performance) matter the
same, because any such judgement would be predictably biased towards
the "it doesn't matter" end of the stick.

Dimitris

Hi John,

On Thu, 2009-07-23 at 20:03 +0200, 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.

How do you define "leading figures in the community"? Just because some
people post a lot in the mailing list does not mean that they exercise
much influence on Scala's codebase. As far as I can gather, people who
actually do the work care about usability. This can be seen by their
actions and communication outside bikeshed threads. :)

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

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

Best,
Ismael

On Thu, Jul 23, 2009 at 8:42 PM, Ismael Juma wrote:
> How do you define "leading figures in the community"? Just because some
> people post a lot in the mailing list does not mean that they exercise
> much influence on Scala's codebase. As far as I can gather, people who
> actually do the work care about usability. This can be seen by their
> actions and communication outside bikeshed threads. :)

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

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

In either case, just writing this response to you I realize how much
of a "gut feeling" and how little "articulated thought" was behind my
problem description so can't really argue about it.

BR,
John

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

On Thu, Jul 23, 2009 at 2:54 PM, John Nilsson wrote:
> On Thu, Jul 23, 2009 at 8:42 PM, Ismael Juma wrote:
>> How do you define "leading figures in the community"? Just because some
>> people post a lot in the mailing list does not mean that they exercise
>> much influence on Scala's codebase. As far as I can gather, people who
>> actually do the work care about usability. This can be seen by their
>> actions and communication outside bikeshed threads. :)
>
> 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...
>
>>> 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.
>>
>> 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.
>
> In either case, just writing this response to you I realize how much
> of a "gut feeling" and how little "articulated thought" was behind my
> problem description so can't really argue about it.
>
> BR,
> John
>

For whatever it's worth, it is refreshing to see someone big enough to
admit he may have gotten it wrong. Kudos to you for that John. Would
that more people were willing to simply say "I may have gotten that
wrong".

I think this much time and energy spent debating a seemingly minor
usability issue is a good indication of a very passionate user base.
But I do agree with Ismael; this is a color of the bike shed
discussion and from my (admittedly very limited) exposure to Scala I
think there are more pressing issues to be addressed.

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.

2009/7/23 Ismael Juma :
> 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
>
>