Live data from Hacker News

Policy – A fork of the Scala compiler

github.com

101–110 of 119 posts

Re: Policy – A fork of the Scala compiler

#101
post #95
post #38

Earlier quoted context omitted.

After watching this talk I don't care what he comes up with in the future, I want to use it. Excellent talk.

Are you familiar with JetBrains MPS? http://www.jetbrains.com/mps/ It sounds very much like what he is describing.

I don't think an IDE is the answer to the problem.

I think making Scala more correct and more modular is the answer. Hygienic macros and syntactic extensions are more what I had in mind. Rust seems to be a solid contender here but it's much more of a systems language.

Re: Policy – A fork of the Scala compiler

#103
post #3

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.

Paul Phillips' 2013 rant/talk: https://www.youtube.com/watch?v=TS1lpKBMkgg

That guy is a maniac. Much of the stuff that he was ranting off about are textbook examples of why functional programming and imperative programming ought to be separated from each other

Re: Policy – A fork of the Scala compiler

#104
post #60

Earlier quoted context omitted.

It's not a question of whether they should exist at all but of whether they should infiltrate the collections hierarchy to the extent that someone has to maintain code which looks like this. And there's plenty of it: this is only an example. trait ParIterableViewLike[+T, +Coll

As a recovering former C++ programmer, that reminds me of the verbosity of C++ meta programming...

Which language have you moved to?

Re: Policy – A fork of the Scala compiler

#105
What is the goal of Paul Philips? He is obviously frustrated by his experiences at Typesafe, but what does he really want? Show us that he can do better? Create an alternative Scala? This seems not be realistic and he seems to be realistic enough to know it. All this sounds like emotional actions from a disappointed ex-lover.

Paul, if you read this: why don't you do something completely different? Leave Scala and your personal rage behind.

Re: Policy – A fork of the Scala compiler

#106
post #99

Earlier quoted context omitted.

It's not a question of whether they should exist at all but of whether they should infiltrate the collections hierarchy to the extent that someone has to maintain code which looks like this. And there's plenty of it: this is only an example. trait ParIterableViewLike[+T, +Coll

Well, that's a pretty good reason to fix something, I agree. But what are your thoughts about Dotty? I assume it's insufficient for you, but is Typesafe going in the right direction here, is it not relevant to what you are doing or will it make things harder?

Dotty is unlikely to attain relevance - for me or as a future version of scala - because there's no reason to expect it to be any less of an implementation nightmare than is scalac. It is being written by the same person, applying the same engineering standards and the same checks and balances, so starting with a less unsound type system isn't going to matter.

Re: Policy – A fork of the Scala compiler

#107
post #99

Earlier quoted context omitted.

Well, that's a pretty good reason to fix something, I agree. But what are your thoughts about Dotty? I assume it's insufficient for you, but is Typesafe going in the right direction here, is it not relevant to what you are doing or will it make things harder?

Dotty is unlikely to attain relevance - for me or as a future version of scala - because there's no reason to expect it to be any less of an implementation nightmare than is scalac. It is being written by the same person, applying the same engineering standards and the same checks and balances, so starting with a less unsound type system isn't going to matter.

I worked on scalac for two years, so I know most of the same warts and issues; I also have had my differences with Martin in the past. But you know what: he has been courageously innovative and has come up with code that works pretty well considering the risks taken for Scala. Most people would have thought what Scala was trying to do was impossible (combining FP and OO with type inference? But semi-unification is undecidable!). But he did it, and you know what, scalac isn't that bad either. Heck, I've done much worse, but the point is to just keep trying.

You want everything to be a nice well understood package because its "easier that way?" But sometimes it isn't easy and the code isn't pretty; not because the programmer is horrible, but because the problems are hard and not very well understood. Does that mean we should shy away from the problems and just do something safe and conservative like C#? If everyone thought like this, we would make no progress.

Kudos to Martin for being fearless, and let's hope he doesn't cave.

Re: Policy – A fork of the Scala compiler

#108

Earlier quoted context omitted.

Dotty is unlikely to attain relevance - for me or as a future version of scala - because there's no reason to expect it to be any less of an implementation nightmare than is scalac. It is being written by the same person, applying the same engineering standards and the same checks and balances, so starting with a less unsound type system isn't going to matter.

I worked on scalac for two years, so I know most of the same warts and issues; I also have had my differences with Martin in the past. But you know what: he has been courageously innovative and has come up with code that works pretty well considering the risks taken for Scala. Most people would have thought what Scala was trying to do was impossible (combining FP and OO with type inference? But semi-unification is un…

That's right, I'm the stodgy conservative one and martin is the fearless innovator. Where is this version of the movie playing? I'd enjoy seeing it.

Your second paragraph lands somewhere between completely wrong and "not even wrong" if it is supposed to have some bearing on the matter. You don't appear to know the first thing about what I've said, what I've done, or what is really going on here.

Reflexive loyalty of this kind, unhinged from any objective reality, is what has brought us today's scalac. You should reconsider whether your having worked on the scala 2.7 eclipse plugin nearly a decade ago qualifies you to take a position on this. Then to position martin as the scrappy underdog - "let's hope he doesn't cave" - just let us know when the novel is finished, and I hope it's better than the movie.

Re: Policy – A fork of the Scala compiler

#109

Earlier quoted context omitted.

I worked on scalac for two years, so I know most of the same warts and issues; I also have had my differences with Martin in the past. But you know what: he has been courageously innovative and has come up with code that works pretty well considering the risks taken for Scala. Most people would have thought what Scala was trying to do was impossible (combining FP and OO with type inference? But semi-unification is un…

That's right, I'm the stodgy conservative one and martin is the fearless innovator. Where is this version of the movie playing? I'd enjoy seeing it. Your second paragraph lands somewhere between completely wrong and "not even wrong" if it is supposed to have some bearing on the matter. You don't appear to know the first thing about what I've said, what I've done, or what is really going on here. Reflexive loyalty of…

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]), which was no easy feat (nor did it last, but it worked and became its own tech [1]). I've dug deeper into scalac front end code (Typers, namers, parsers) than most scalac devs have; I know Martin's style very well as a result.

[1] work on making scalac incremental eventually led to http://research.microsoft.com/en-us/people/smcdirm/managedti...

Re: Policy – A fork of the Scala compiler

#110

Earlier quoted context omitted.

That's right, I'm the stodgy conservative one and martin is the fearless innovator. Where is this version of the movie playing? I'd enjoy seeing it. Your second paragraph lands somewhere between completely wrong and "not even wrong" if it is supposed to have some bearing on the matter. You don't appear to know the first thing about what I've said, what I've done, or what is really going on here. Reflexive loyalty of…

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.
Post reply on HN