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

91–100 of 119 posts

Re: Policy – A fork of the Scala compiler

#91

Post by charlieflowers »

I just watched the talk, and it is full of insight. Highly recommended even if you've never used Scala (as I have not).

Some samples (some are quotes, some are paraphrased):

* "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools." (emphasis mine)

* "I want to programmatically generate ASTs and feed them in"

* The AST (the tree) is fundamental, not the language. For example, if you have an AST you're working with, and you hate curly braces, theoretically you could see the same tree "rendered" as text without those curly braces.

* "True power is in restriction" & "unnecessary expressiveness is the enemy" -- whatever your language lets you "say", the "other side" (the compiler or interpreter) has to be able to understand. So unlimited language means horribly over-complicated compiler that cannot do nearly as much optimization as you'd like.

* The more free your code is of "over-precision", the more powerful that code is, because the compiler can do more with it. Example: the well known example of an imperative for-loop versus the functional "map".

* "If you want fast, start with comprehensible."

Re: Policy – A fork of the Scala compiler

#92

Post by charlieflowers »

charlieflowers wrote: post #91

I just watched the talk, and it is full of insight. Highly recommended even if you've never used Scala (as I have not). Some samples (some are quotes, some are paraphrased): * "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools ." (emphasis mine) * "I want to…

In fact, towards the end of the talk, I was thinking "Wow, he sounds almost as ambitious as Bret Victor." Then, the next slide was a picture and some quotes from Bret Victor. :)

Re: Policy – A fork of the Scala compiler

#93

Post by seanmcdirmid »

charlieflowers wrote: post #91

I just watched the talk, and it is full of insight. Highly recommended even if you've never used Scala (as I have not). Some samples (some are quotes, some are paraphrased): * "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools ." (emphasis mine) * "I want to…

> "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools." (emphasis mine)

We did something like this before with scalac back in 2007. But they eventually decided to use lazy rather than incremental evaluation after I left the project (I admit the tech was too crazy and under developed for the time).

But the approach wound up working very well, check out:

http://research.microsoft.com/en-us/people/smcdirm/managedti...

I'd imagine it would work well for Scala today (it took about 6 months to retrofit scalac in 2007, and most of this was just polishing positions for memoization + getting rid of object identities). However, TypeSafe's current approach to reactive programming seems to revolve around Rx and actors, which isn't very useful in a compiler or live interpreter.

> The AST (the tree) is fundamental, not the language. For example, if you have an AST you're working with, and you hate curly braces, theoretically you could see the same tree "rendered" as text without those curly braces.

Ya, but all of this can be done in the IDE. Also, projectional editing isn't quite their yet; I prefer hacks like "Little Braces" for Visual Studio that simply shrink brace-only lines to very small font sizes :) Of course, I think syntax is "language", and having multiple languages flying around isn't great for community building.

Re: Policy – A fork of the Scala compiler

#94

Post by gress »

Tuna-Fish wrote: post #79
stefantalpalaru wrote: post #65

Earlier quoted context omitted.

Unfortunately this SEO justified change has permeated the community and now people call the language "golang" instead of "Go".

s/Unfortunately/Fortunately/ Go is a terrible, terrible name.

Golang is a terrible name.

Re: Policy – A fork of the Scala compiler

#95

Post by mdaniel »

jpgvm wrote: post #38
cakoose wrote: post #3

Earlier quoted context omitted.

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

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.

Re: Policy – A fork of the Scala compiler

#96

Post by foolinux »

charlieflowers wrote: post #91

I just watched the talk, and it is full of insight. Highly recommended even if you've never used Scala (as I have not). Some samples (some are quotes, some are paraphrased): * "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools ." (emphasis mine) * "I want to…

"I want to programmatically generate ASTs and feed them in"

Going by the experience with preprocessors in Ocaml, not the best idea IMO.

Re: Policy – A fork of the Scala compiler

#97

Post by extempore »

mdaniel wrote: post #95
jpgvm wrote: 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.

Yes, MPS and "language workbenches" in general are chasing something similar. Ideas like these are entirely in the details though, and so far I haven't found anything which does it for me. I could easily be missing it, in part because systems like MPS have a high up-front investment, and I have regretted such investments more often than not.

Re: Policy – A fork of the Scala compiler

#98

Post by logicchains »

foolinux wrote: post #96
charlieflowers wrote: post #91

I just watched the talk, and it is full of insight. Highly recommended even if you've never used Scala (as I have not). Some samples (some are quotes, some are paraphrased): * "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools ." (emphasis mine) * "I want to…

"I want to programmatically generate ASTs and feed them in" Going by the experience with preprocessors in Ocaml, not the best idea IMO.

Doesn't Ocamlpp4 or whatever its called generate OCaml source code and pass that to the compiler, not OCaml AST? The new ppx extension in 4.02 allows direct manipulation of OCaml AST, but that hasn't been used enough yet to determine its effectiveness.

Re: Policy – A fork of the Scala compiler

#99

Post by tormeh »

extempore wrote: post #44
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…

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?

Re: Policy – A fork of the Scala compiler

#100

Post by zak_mc_kracken »

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?

Agreed. There is a vocal minority of people (academics mostly) yelling at how subtype polymorphism is broken and unusable. It certainly has broken aspects (with respect to equality) but by and large, it's extremely usable, intuitive and it enables powerful abstractions. The corner cases where it falls apart seem to be irrelevant for most uses.
Post reply on HN