Re: [scala] The Language Designer's Dilemma

> In PL design, everyone seems to have different ideas about what the best,
> even perfect, design is. Fundamentalists can stick to a stone tablet of
> principles that they won't waver from even if they clearly won't work, while
> pragmatists can be as shifty as successful politicians on using whatever
> principle is convenient or popular. I think with experience, many designers
> drift toward the latter camp, especially if they want their languages to be
> used. And then there are those that remain fundamentalists because this is
> also an interesting and useful path.
>
> I'm seeing a lot of debate recently about how decisions made in the Scala
> library are crazy, ill thought out, etc. However, the flip side of this coin
> is that the criticism doesn't consider the consequences of their "obvious"
> change. Example:
>
> Should "cba" == "abc".reverse be true? Of course it should be! 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!). Given these concerns,
> changing reverse in RichString to return a String is no longer obviously the
> right thing to do! So the Scala team wasn't so stoned when they decided to
> have reverse return RichString rather than String. When you actually sit
> down and design/code these things, you realize how many bazillion trade offs
> there are to make.
>
> I've come to this conclusion: there are no good language/library design
> decisions, only bad design decisions. Whatever decision a language designer
> makes will necessarily be a bad one, because a trade off will be made that
> is obviously horrible to someone.  Some design decisions may be worse than
> others, but they are still bad. Accept that. And why would your bad design
> decision be any better or worse than someone else's? Self righteousness will
> only serve to aggravate others who don't hold your same principals. Anyone
> who suggest that they have found the perfect design solution is probably
> selling snake oil.
>
> All languages have their own set of bad design decisions that define them.
> C++ is religiously backwards compatible with C and its pervious versions,
> and as a result is the butt of many PL jokes. Is Bjarne an idiot for
> designing such a bad language? Well, C++ is hugely successful because many
> people and projects still prefer from C++'s bad decisions vs. say Java's.
> Bjarne is probably a genius, even if I personally don't like programming
> C++. Haskell is more idealistic and pure, not as popular, but is well
> designed and serves a purpose. Likewise, Ruby will do things behind your
> back, implicitly coerce things, re-direct your method calls...there is so
> much magic going on! Is Ruby a bad language? Of course (because they all
> are), but lots of people feel like this magic and feel like it servers a
> purpose. C# and Java on the other hand are more verbose and try not to do
> anything implicitly. Another bad decision, but many people benefit from that
> also. I'm actually growing to like C# at Microsoft; e.g., extension methods
> are less magical than implicits, but get the job done. The C# team were
> obviously not on meth when they designed C#, no matter how many times the
> thought crossed my mind when I was learning how to use C#!
>
> I like Scala's bad decisions more than the other languages'. In the library,
> a few of those bad decisions are mine (e.g., projections), and I've made
> many more bad decisions in the plugin (to quote comic shop guy: "the worst
> Scala plugin ever"). I've also disagreed with some of Martin's decisions
> (e.g., strong specification of protected that seems to reduce applicability,
> strictness in mutable collections where it seems to create a contradiction),
> but in the end his bad decisions often turn out to be less worse than mine
> (and of course, he out-ranks me :) ). Working with Martin was immensely
> educational and life changing.
>
> I was at first weary of implicits, but see that they serve a purpose and
> shouldn't be discounted as evil, well, no, they are evil but that means you
> shouldn't use them: they sere a purpose; e.g., through implicits and other
> constructs can do stuff with Scala that people thought were only possible in
> dynamic languages. Scala has the opportunity to can draw ultra-pragmatic
> programmers from Java who might otherwise go to Ruby or Python. Scala is
> also principled with a powerful type system that can draw in fundamentalists
> from languages like Haskell who are looking for a language their bosses will
> actually accept. And of course, many people lie in between. 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.
>