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

111–119 of 119 posts

Re: Policy – A fork of the Scala compiler

#111

Post by frowaway001 »

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.

I like dynamic dispatch. Having code which suddenly changes the implementation based on type ascriptions is just not what I want in this case.

Apart from that, I think collections can be improved considerably even while keeping dynamic dispatch.

Re: Policy – A fork of the Scala compiler

#112

Post by [deleted] »

extempore wrote: post #110
seanmcdirmid wrote: post #109

Earlier quoted context omitted.

You are right, I don't know you beyond these online interactions. I was giving you the benefit of the doubt, but you sound very vindictive, and I get it, you know stuff. Building and designing things is a journey, it won't be perfect unless you set your expectations low. I didn't just work on the scala plugin, I changed scalac to be completely incremental at the AST level (better than everything being a Diff[T]), whi…

I am intimately familiar with your work on scalac, and that's all I can bring myself to say about that.

[deleted]

Re: Policy – A fork of the Scala compiler

#113

Post by seanmcdirmid »

extempore wrote: post #110
seanmcdirmid wrote: post #109

Earlier quoted context omitted.

You are right, I don't know you beyond these online interactions. I was giving you the benefit of the doubt, but you sound very vindictive, and I get it, you know stuff. Building and designing things is a journey, it won't be perfect unless you set your expectations low. I didn't just work on the scala plugin, I changed scalac to be completely incremental at the AST level (better than everything being a Diff[T]), whi…

I am intimately familiar with your work on scalac, and that's all I can bring myself to say about that.

You and miles must be best friends. Its fine. Phew, really glad to be out of the Scala community at this point, it just wasn't worth it to being around those people.

Re: Policy – A fork of the Scala compiler

#114

Post by milessabin »

seanmcdirmid wrote: post #113
extempore wrote: post #110

Earlier quoted context omitted.

I am intimately familiar with your work on scalac, and that's all I can bring myself to say about that.

You and miles must be best friends. Its fine. Phew, really glad to be out of the Scala community at this point, it just wasn't worth it to being around those people.

Paul and I don't see eye to eye on many things, but on this we're in complete agreement.

Re: Policy – A fork of the Scala compiler

#115

Post by runT1ME »

eeperson wrote: post #87
runT1ME wrote: post #83

Earlier quoted context omitted.

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?

I should have added that despite me not liking the std lib collections library, it's still stands above all other collection libs I've used in other languages.

The problem is that the std. lib collections tries to unify mutable/immutable and lazy/eager/finite/infinte datastructures into one class hierarchy. So you have methods like "size" or "add" on generic interfaces that mean different things depending on the implementation. So the entire abstraction ends up being leaky.

Scalaz has a few common implementations of immutable, eager data structures and ends up using a type class approach to modularity and code reuse that ends up not being leaky, it's a joy to use.

I don't think there's anything wrong with using the collections, just be aware that if you run into some edge cases, it's not the language, it's design choices made by the library writer and there may be better implementations.

Re: Policy – A fork of the Scala compiler

#116

Post by seanmcdirmid »

milessabin wrote: post #114
seanmcdirmid wrote: post #113

Earlier quoted context omitted.

You and miles must be best friends. Its fine. Phew, really glad to be out of the Scala community at this point, it just wasn't worth it to being around those people.

Paul and I don't see eye to eye on many things, but on this we're in complete agreement.

So is life. Its great to see that you fixed the plugin and it works very well now. Congrats!

I'm just glad to be out of it. The Scala community really was becoming toxic, sleeping was hard. Hopefully you guys have all resolved your differences now and things are more harmonious.

Re: Policy – A fork of the Scala compiler

#117

Post by sirinath »

zak_mc_kracken wrote: post #29
taeric wrote: post #21

Earlier quoted context omitted.

That thread doesn't exactly inspire confidence in choosing Scala as a platform, to be honest. With quotes such as "There's still plenty of very basic stuff in the compiler which doesn't work," I'm honestly not sure how anyone could look forward to a dive. Don't get me wrong. I know that it isn't necessarily the case that "basic" represents "affects plenty of people." But, especially when it was used in a "hits more p…

> That thread doesn't exactly inspire confidence in choosing Scala as a platform, to be honest. This is exactly the message that Paul Phillips has been spreading these past months. Personally, I hope he decides to just create his own language, I would be extremely interested to follow this.

I also would like to see how this goes though he does not seam to be taking this step.

Re: Policy – A fork of the Scala compiler

#118

Post by teacup50 »

seanmcdirmid wrote: post #19
teacup50 wrote: post #12

Earlier quoted context omitted.

I can assure you of two things: 1) Paul is not ignorant of the existence of Smalltalk 2) Smalltalk is not a replacement for the fruits of modern language research. In fact, the academic work around Smalltalk is nothing more than unsupported opinion, and it's not even remotely useful as a source of research.

Parent was out of line but there is still plenty of modern academic research occurring around Smalltalk. Not to mention Gilad's Newspeak (which may or may not be academic, you'd have to ask him).

Can you think of a single example that:

1) Posits new conjectures 2) Proves those conjectures 3) Those conjectures can be used to formulate new conjectures that conform to items 1-3?

I've read a great deal of smalltalk literature, and I can't recall any papers that would qualify. There's plenty of empirical exploration of ambiguous hypothesis, but nothing that actually provides anyone in the field anything on which they could actually build.

Re: Policy – A fork of the Scala compiler

#119

Post by 0x434D53 »

I don't get that outcry and panic inside the Scala community. We should give the 2 forks a chance and see what it leads to. There is still the chance then to reunite the community behind "one" scala. Also they could have great influence on Typesafe Scala. As far as i know the compiler (which is not very much): The 2 forks will anyway not move away from Typesafe scala at huge speed.

Let's come here again in 6 months and see where we stand.

Post reply on HN