Skip to content
This repository has been archived by the owner. It is now read-only.

merge with paulp/policy #50

Closed
jdegoes opened this issue Sep 16, 2014 · 3 comments
Closed

merge with paulp/policy #50

jdegoes opened this issue Sep 16, 2014 · 3 comments

Comments

@jdegoes
Copy link

@jdegoes jdegoes commented Sep 16, 2014

A community-maintained fork of the Scala compiler will have substantially greater chances of success if the entire community of developers looking for a "better Scala" is united around a single compiler.

To that end, I suggest the rather obvious: that typelevel/scala and paulp/policy should be one and the same project. Both are already philosophically united around the idea of a "better, simpler Scala" and differ primarily in requirements for backward compatibility, and in my opinion, typelevel's requirements need revamping.

Moreover, the current community-driven process of development on typelevel/scala will run into issues wherever there are substantial disagreements in the proposed direction of the compiler. This is why most successful languages have a "BDFL". A community-maintained fork of the Scala compiler needs a BDFL and the person most qualified for that role is @paulp.

So there you have it, my 2 cents on uniting behind a single community-maintained fork of Scalac.

@paulp
Copy link

@paulp paulp commented Sep 16, 2014

I admit that I'd rather we were all working on the same thing, and @jdegoes astutely if only implicitly identifies the major reason we aren't. I would rather rule in hell than serve in heaven, as the saying goes. I served in heaven for quite a while and it wasn't that heavenly.

And if it doesn't seem like a good idea at this point (which I would completely understand) it might not take too long before it does, because I'm not sitting on my thumbs.

@propensive
Copy link

@propensive propensive commented Sep 16, 2014

We spent considerable time prior to the announcement looking at whether Typelevel Scala and Policy could work together, but Typelevel's goals are actually more aligned to Typesafe's than @paulp's, for now at least.

One problem we have is that we're inexperienced and unproven, and we're trying to produce something of a sufficiently high standard that people will rely on it enough to use it in production. The more ambitious we are, the less likely we are to achieve that goal. We've had to take the conservative route, because we believe it has the greater chance of success. Once we all become experts in Scalac development, we can reevaluate our ambitions and goals.

Regarding having a BDFL, we decided months ago that we didn't want that; not @paulp, not @milessabin, not anyone. That may be detrimental at times, but it's a community fork, and we really want to keep all discussion and decisions open and public, not within a committee, or within one person's head.

I'll keep the issue open for now, because I think it's a worthwhile debate to be having - thanks for raising it, @jdegoes!

@milessabin
Copy link
Member

@milessabin milessabin commented Sep 16, 2014

+1 to the debate ... this is the wrong place for it though ... it should be on the typelevel mailing list.

@milessabin milessabin closed this Sep 16, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants