« Return to Thread: [scala] The Language Designer's Dilemma

[scala] Re: The Language Designer's Dilemma

by Jesper Nordenberg :: Rate this Message:

Reply to Author | View in Thread

Sean McDirmid wrote:
> Should "cba" == "abc".reverse be true? Of course it should be!

Agreed.

 > What was
> the Scala team smoking when they decided RichString.reverse should
> return anything other than String? Of course it should be changed to
> return String so equality works right! Oh wait...reverse is defined in
> Seq to return a Seq, and the LUB of String and Seq is...AnyRef. So if
> reverse in RichString returns a String, then either reverse has to be
> removed from Seq, or it has to be defined to return AnyRef, or some
> compiler magic has to make String a Seq (in much the same way that
> arrays are) introducing more boxing madness to Scala (and equality would
> still be broken!).

Actually not much compiler magic is needed, just make string literals be
of class scala.String (which would be a Seq) and provide implicit
conversions to and from java.lang.String.

> Essentially, Martin has created a "big tent" language
> that will attract users from all over the place. Although a big tent
> good thing, it leads to some tension that I'm feeling already. There are
> already many debates about implicits, Java compatibility, breaking
> binary compatibility, etc...everyone has a strong opinion, referring to
> other opinions as crazy or in one case "immature." This can easily get
> blood boiling, especially in the more passionate among us. I guess it is
> bound to happen in any language community, but more so in Scala given
> its big tent focus.

I don't think heated debates is a bad thing, it shows that there is a
lot of people who care about Scala. Scala is one of the best programming
languages around, and the Java interoperability is the killer feature.
The language is a bit too complex and there are some sub-optimal
constructs, but I understand why Martin put them in the language (most
of them are related to Java interoperability).

As for the standard library, it's not as important to get this right the
first time as the language, and with any non-trivial library I would say
it's almost impossible to get right the first time. A good module and
versioning system can help a lot here with regard to preserving or
breaking backwards compatibility. As long as the users knows when
backwards compatibility is broken AND have the option of either
migrating to the new version or continue using the old (still
maintained) version. This is the inevitable path of all libraries, you
might as well face it now. It would be unfortunate if the Scala library
turned into another JRE/JDK mess.

/Jesper Nordenberg

 « Return to Thread: [scala] The Language Designer's Dilemma