Sure that's nice and so is LINQ but there are thousands of programmers using LINQ without worrying about monads. It's like I said, I really don't have any issues with applying theory to enrich the practice of programming and the new crop of languages that are more fully grounded in theory is really a breath of fresh air. The problem I have with some people that enjoy these type level hacks is that they are not in it to build things that thousands of programmers can use to make their lives easier. They're usually in it to build monuments to their own egos. Forking the language is just another instance of that hubris. They're basically saying what Odersky and friends are doing is not good enough even though Odersky and friends have poured thousands of hours into making it something that in my opinion is actually something good.

If this was something that was driven by anything other than ego then they'd look at library popularity and contribute fixes to the most used and valuable libraries. Instead, they've decided to fork the language because 3 libraries, one of which is the author's own, don't have enough syntactic sugar to express certain type level constraints. Does that sound reasonable to you?

I think it is misguided to call this an act of ego, like Miles says in the announcement Typesafe has different goals, and milestones that don't necessarily serve the whole community. There are actually tons of nice small changes that haven't been implemented for various reasons, and I see this as an incubator where people can try out experimental extensions of the language and reasonably package them together, ideally porting them (if they are good) back to scalac itself. This isn't much different than people reimplementing Python or Ruby, or adding experimental extensions to Haskell (go look at how many different Haskell compilers there are). Personally I'm always interested to see what directions people can push software in when not motivated by money, or publications.

I think it is also important to remember that these people work on stuff for free in their free time because they enjoy it. They are free to pick designs and approaches they like, and have zero obligation to contribute to popular libraries, regardless of their supposed merit.

How many people write anything in Python or Ruby that is not compatible with CPython and MRI Ruby? The lowest common denominators in those communities are still the reference implementations and any production grade library conforms to that lowest common denominator. As for the Haskell compilers, I'd like to hear from someone that uses anything other than GHC in production.

I agree they can work on whatever they want but this is a bit less benign than writing another library that no one is going to care about. Language forks have never been successful. Please show me one example where a language fork has succeeded and I'll concede. This is a whole lot of drama that is going to turn more people away from Scala which in my opinion is one of the better languages that runs on the JVM.

Haskell's actually got a pretty great (if informal) standard which has been used to write a number of different compliant Haskell compilers. GHC is obviously the most popular open source one, but Standard Chartered Bank has its own Haskell compiler it uses a great deal of in production, for instance.

What is the point of a proprietary, in-house, custom compiler?

The Excel backend of course.

> How many people write anything in Python or Ruby that is not compatible with CPython and MRI Ruby? The lowest common denominators in those communities are still the reference implementations and any production grade library conforms to that lowest common denominator.

If the library is binary-compatible with that reference implementation (as the typelevel guys say they will be), why would you as a user care which compiler was used to compile it? A lot of typelevel code already uses macros or compiler plugins to generate source (I've even heard that at one point the Shapeless code was generated using Freemarker templates) - but as users we just depend on their released jars and don't have to worry about any of that.

Why all the hoopla then? Just go ahead and do it. Why make a public stand and generate so much drama?

We've tried to avoid creating a "drama"; that's not the intention at all. But we want to attract other developers to our experimental fork, so that if you want to use new and exciting features, or contribute your own, you don't have the entire burden of maintaining your own fork. The hope is that the Typelevel fork will gain enough critical mass to encourage people to develop new language features where they previously wouldn't have bothered, due to the high costs involved (in terms of maintenance) and limited returns. It really is meant to be a community effort.

a) It's a useful project for other library authors; of course they want to announce it.

b) I think the part tucked away at the end about a foundation is actually the most important part. Scala's currently owned by one university and also partially by typesafe, and while on the whole they've done a good job there are a lot of stakeholders who aren't really represented there. For a language that so many different organizations are depending on, I think it's time there was something a little more formal and dependable; many other languages have similar foundations.

Who cares how large their egos are if they're right?

Edit: to elaborate, you're mostly arguing about the personalities involved, which I consider irrelevant. Convince me that they're wrong based on the merits of their proposal.

Right about what? That their precious libraries don't have enough syntactic support in the current Scala toolchain? I mean sure I guess they're right in that sense.

My argument is not just about the personalities involved but I admit that is a large part of why this leaves a sour taste in my mouth. I think these libraries are a really nice way to bone up on theory and see how certain abstract concepts get expressed in something that is computable. None of that is the issue. The issue is that there is now going to be an unnecessary choice involved in what toolchain you are going to use even though the choice is going to be completely irrelevant. The enterprise guys are not going to use anything that is not backed by service/stability guarantees and the group that is going to use the alternate toolchain is potentially going to diverge more and more from the stable branch. It just feels like a whole bunch of wasted effort. There are many examples of this happening already. The biggest example being D and the fork of the standard library in the early days. The other examples are python2 vs python3 and perl5 vs perl6. Going by historical examples this is going to be a complete and utter failure.

Don't focus too much on the relevance of the Typelevel fork to the Typelevel libraries. The people involved (myself excepted) work on the Typelevel libraries, and consequently have particular interest in the features they benefit most from. But the fork, and the infrastructure around it, is for the benefit of the entire community, not just Typelevel. We'll happily entertain PRs for any useful language feature, provided it meets the compatibility requirements.

Counter examples Egcs xorg Oderskys Java compiler