Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Policy – A fork of the Scala compiler

github.com

Post reply on HN
Print view View original

81–90 of 119 posts

Re: Policy – A fork of the Scala compiler

#81

Post by jendap »

I'm so happy to see this! Thank you Paul!

Paul may have been hurting perception of Scala community by his rants a bit lately. But the fork is a greatly welcomed! All the things Paul said make sense. The fork can prove the value of those ideas.

Simpler compiler => more compiler developers => more productive => better compiler => better for the whole community!

As for Typesafe. There are doing great job. Just two releases ago Scala was not compatible even between minor releases. Stability, documentation, training, driving the community, good roadmap for 2.12, etc. Great job! Plus they are build a great framework around akka and play which is gaining traction.

Policy is actually not really a fork. Forks are, imho, projects which diverge code base one day and there's really no sharing between them anymore. Paul is merging from scalac all the time. It really is just vastly simplified scalac with some wise decisions like modularizing some aspects (like parallel collections).

BTW: Anybody worried about a friction while trying to push a bold change in a team of more than one person? Have you ever worked in a team of more than one? :-) Just do it. Prove it. Dismiss the FUD.

Fist questions on my mind: 1) Future? Is this repo intended to pull from scalac or diverge more? 2) Dropping reflection? Does it means removal of macros as well? For the time being or for good? 3) How about leaf node invariance in collections (and other collection stuff you talked about)?

Re: Policy – A fork of the Scala compiler

#82

Post by dustingetz »

extempore wrote: post #48
zak_mc_kracken wrote: post #27

Earlier quoted context omitted.

He gives a few hints on the github page and in the many presentations he's been giving these past months since he left Typesafe. The short version is that he lost trust in the Typesafe team and he thinks they are not competent to carry Scala moving forward. Like he says, he tried to change things from the inside, he couldn't, so now he's trying from the outside.

Typesafe hasn't lost my confidence. Typesafe has been responsible for important progress which is already being taken for granted. People either have forgotten how low assurance was in the 2.8 days, or they weren't using scala yet. The problem is on the other side of the Atlantic. Scala is unfixable now no matter the abilities of the people working on it because of the bad decisions which have been made to this point…

Has martin publicly responded to this anywhere?

Re: Policy – A fork of the Scala compiler

#83

Post by runT1ME »

tormeh wrote: post #14

Why are parallel collections an "albatross"? I can understand it if he plans to replace the functionality you get by writing "list.par.map(func).seq" with "list.parmap(func)" or something, though. Parallel list functions are one of my favorite features in Scala, and I think it would be a serious loss if they disappeared. Also, I wonder what the two Scala forkers are thinking about Dotty (the next-gen Typesafe scala c…

The collections library itself is probably one of the worst things about scala.

I've ranted on the mailing list before, but it's overuse of inheritance rather than a type class based approach kills reasoning and modularity. Subtype polymorphic collections libraries are unquestionably a failed experiment.

Re: Policy – A fork of the Scala compiler

#84

Post by extempore »

jongraehl wrote: post #80

Paul, why do you say it's wrong that Float(Long.max - Int.max) is equal to Float(Long.max)? Float has less than 32 significant binary digits, and Long.max - Int.max has the same MSBs as Long.max. You would need to use Double to see the difference. I'm not sure what implicit conversions/promotions have to do with that - you want a warning or error when going from Long to Float? That would be reasonable. You can even l…

> Paul, why do you say it's wrong that Float(Long.max - Int.max) is equal to Float(Long.max)?

I don't. You have inserted coercions.

I'm aware of how many bits things have. It's hard to make it through five years on a compiler without gaining some awareness of such details. I consider the introduction of lossy type conversions into the global scope to be a kind of insanity. People should be recoiling from such practices, not looking for ways to justify them.

Re: Policy – A fork of the Scala compiler

#85

Post by extempore »

jendap wrote: post #81

I'm so happy to see this! Thank you Paul! Paul may have been hurting perception of Scala community by his rants a bit lately. But the fork is a greatly welcomed! All the things Paul said make sense. The fork can prove the value of those ideas. Simpler compiler => more compiler developers => more productive => better compiler => better for the whole community! As for Typesafe. There are doing great job. Just two relea…

I will continue to merge from scalac for as long as I can, because with no meaningful specification it is the only way to retain compatibility.

I didn't say I'm dropping reflection, I said I'm dropping the scala-reflect layer. It's a gigantic and useless abstraction penalty. I'll fold the pseudo-compiler into the compiler.

We'll see about collections. Here's where it stands: https://github.com/paulp/psp-std

Re: Policy – A fork of the Scala compiler

#86

Post by extempore »

dustingetz wrote: post #82
extempore wrote: post #48

Earlier quoted context omitted.

Typesafe hasn't lost my confidence. Typesafe has been responsible for important progress which is already being taken for granted. People either have forgotten how low assurance was in the 2.8 days, or they weren't using scala yet. The problem is on the other side of the Atlantic. Scala is unfixable now no matter the abilities of the people working on it because of the bad decisions which have been made to this point…

Has martin publicly responded to this anywhere?

Martin has been determinedly ignoring me for so long (at least two years, probably more) I've pretty well forgotten it was ever otherwise. He is undoubtedly correct that ignoring me achieves better damage control than any active response could.

Re: Policy – A fork of the Scala compiler

#87

Post by eeperson »

runT1ME wrote: post #83
tormeh wrote: post #14

Why are parallel collections an "albatross"? I can understand it if he plans to replace the functionality you get by writing "list.par.map(func).seq" with "list.parmap(func)" or something, though. Parallel list functions are one of my favorite features in Scala, and I think it would be a serious loss if they disappeared. Also, I wonder what the two Scala forkers are thinking about Dotty (the next-gen Typesafe scala c…

The collections library itself is probably one of the worst things about scala. I've ranted on the mailing list before, but it's overuse of inheritance rather than a type class based approach kills reasoning and modularity. Subtype polymorphic collections libraries are unquestionably a failed experiment.

Why do you feel that it is a failed experiment? As a user of the collections, it seems to me to work out. Is it more of a problem with the implementation of the collections?

Re: Policy – A fork of the Scala compiler

#88

Post by jibal »

nemothekid wrote: post #2

Can someone with some familiarity with Scala community explain why someone who seems to be the largest contributor to Scala felt the need to create a fork? It seems completely justified due to his credentials, but he doesn't give any specific reasons why he created this fork.

"he doesn't give any specific reasons why he created this fork"

This is somewhat like asking why Richard Dawkins just assumes the Theory of Evolution without justification in his tweets.

Googling Paul Phillips Scala brings up plenty of relevant discussion.

Re: Policy – A fork of the Scala compiler

#89

Post by jibal »

jfim wrote: post #10
[deleted] wrote: post #8

Earlier quoted context omitted.

[deleted]

It turns into a rant about how he'd wish the compiler and the editor and the source control should be all talking with one another. It's funny, because there's actually a language just like that: Smalltalk. The development environment is the same as the runtime environment, it has its own source control (Monticello), its own editor and a very regular language.

"It's funny, because there's actually a language just like that: Smalltalk."

I don't see how that's "funny" or relevant, as there are many other things about Scala that Smalltalk isn't just like.

Re: Policy – A fork of the Scala compiler

#90

Post by extempore »

eeperson wrote: post #77
zak_mc_kracken wrote: post #31

Earlier quoted context omitted.

> It appears to be a fork of the compiler not the language itself. They are the same thing. There is no spec for Scala (no recent one anyway) so the specification is the Scala compiler. And based on everything that Paul has been saying these past months, the compiler is very close to being unmaintainable.

There actually is a recent spec, although I'm not sure if it still needs some updating. http://www.scala-lang.org/files/archive/spec/2.11/

There is "a spec" yes. Now let's see someone implement a compatible implementation based on that. We're not talking about fiddling at the boundaries here. For instance type inference is completely unspecified. There is no aspect of scala compilation which is not heavily influenced by how type inference unfolds, yet there is nothing. And that is the tip of the iceberg.

If you're always hearing about how amazingly small scala's specification is, now you know why.

Post reply on HN