15 ms·

> Identify a subset of Scala that can be compiled with reasonable speed I am afraid of Scala fragmentation. There is no way new compiler can be 100% compatible

> Identify a subset of Scala that can be compiled with reasonable speed I am afraid of Scala fragmentation. There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec. It would be nice to add a switch into old scalac, which downgrades its features, to make it compatible with new scalac. I believe Scala has too many features, and it will be very difficult to fix compilation speed. But there could be decend boost just by rewritting compiler from scratch. If anything we will get better error messages. Compilation speed was major reason why Jetbrains started Kotlin. Disclaimer: I worked with Scalac / IDE back in 2009. Kotlin fanatic.

skrebbel 9y ago
> Hopefully it will be tested on major projects Twitter has pretty big resources. It's probably feasible for them to spin up a build farm that runs their compiler against all active Scala projects on GitHub, measuring error count and compilation speed as they go along.
harpocrates 9y ago
> There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec. I, for one, think that an official language spec would do the language a lot of good. As it stands, it is sometimes difficult to separate bugs from features in scalac...
- dtech 9y ago
  I am not sure how complete/correct it is, but there is one for 2.9 [1] Martin Odersky & co have been focusing most of their effort the last few years on Dotty (aka Scala 3), which succeeded in giving in giving Scala a proven theoretical basis in exchange for a few esoteric typesystem features they couldn't prove. [2] [1]: http://www.scala-lang.org/old/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf http://www.scala-lang.org/old/sites/default/files/linuxsoft_... [2] http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.h...
  - simon_o 9y ago
    There are also specs for later versions, it's just that they are pretty outdated and unmaintained. (Like pretty much everything related to documentation.) I think Jetbrains has some experience using that spec to implement the IDE's Scala typechecker. Long story short: years later, it still doesn't work. I would be kind of concerned about the esoteric new features they added to Dotty, looks like the lesson has not been learned yet.
    - dtech 9y ago
      They removed the esoteric features because they could not be theoretically proven sound, not added them.
      - simon_o 9y ago
        Just off the top of my head, esoteric additions: - "Numeric harmonization" which makes some of the existing issues with implicit numeric conversions even worse. - Multiversal equality, which adds even more special rules to the implicit resolution algorithm, complicates the mental model of the language, is either extremely invasive or severely limited when applied to real-code, and falls apart when dealing with existing language features of Scala like variance. - Addition of inline, which has absolutely no reason to be a new keyword. - The tentative idea of adding T? for T|Null (as it appeared on some slides) which makes it obvious that no thought has been given to how the lessons of handling nulls apply to Scala. Then we have enums, which are just poorly designed and executed, repeat the mistakes made with both case classes and scala.Enumeration, do not address the problems it is supposed to solve, fail to address actually valid existing problems, all while introducing not one, but two additional syntactic constructs which are unlike anything we had before. On top of that we got incompatible additions in minor releases of 2.12: - Additional places where commas can be added, which ignores one of the most common complaints about Scala: Too many syntactic variations to express the same thing. - The addition of @showAsInfix which is a solution in search of a problem. But at least unsound type projections got restricted, I guess. (That's the only major thing I can think of that will have a larger impact...) Probably the removal of forSome and cleaning up existentials?

skrebbel 9y ago

> Hopefully it will be tested on major projects Twitter has pretty big resources. It's probably feasible for them to spin up a build farm that runs their compiler against all active Scala projects on GitHub, measuring error count and compilation speed as they go along.

harpocrates 9y ago

> There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec. I, for one, think that an official language spec would do the language a lot of good. As it stands, it is sometimes difficult to separate bugs from features in scalac...

dtech 9y ago
I am not sure how complete/correct it is, but there is one for 2.9 [1] Martin Odersky & co have been focusing most of their effort the last few years on Dotty (aka Scala 3), which succeeded in giving in giving Scala a proven theoretical basis in exchange for a few esoteric typesystem features they couldn't prove. [2] [1]: http://www.scala-lang.org/old/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf http://www.scala-lang.org/old/sites/default/files/linuxsoft_... [2] http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.h...
- simon_o 9y ago
  There are also specs for later versions, it's just that they are pretty outdated and unmaintained. (Like pretty much everything related to documentation.) I think Jetbrains has some experience using that spec to implement the IDE's Scala typechecker. Long story short: years later, it still doesn't work. I would be kind of concerned about the esoteric new features they added to Dotty, looks like the lesson has not been learned yet.
  - dtech 9y ago
    They removed the esoteric features because they could not be theoretically proven sound, not added them.
    - simon_o 9y ago
      Just off the top of my head, esoteric additions: - "Numeric harmonization" which makes some of the existing issues with implicit numeric conversions even worse. - Multiversal equality, which adds even more special rules to the implicit resolution algorithm, complicates the mental model of the language, is either extremely invasive or severely limited when applied to real-code, and falls apart when dealing with existing language features of Scala like variance. - Addition of inline, which has absolutely no reason to be a new keyword. - The tentative idea of adding T? for T|Null (as it appeared on some slides) which makes it obvious that no thought has been given to how the lessons of handling nulls apply to Scala. Then we have enums, which are just poorly designed and executed, repeat the mistakes made with both case classes and scala.Enumeration, do not address the problems it is supposed to solve, fail to address actually valid existing problems, all while introducing not one, but two additional syntactic constructs which are unlike anything we had before. On top of that we got incompatible additions in minor releases of 2.12: - Additional places where commas can be added, which ignores one of the most common complaints about Scala: Too many syntactic variations to express the same thing. - The addition of @showAsInfix which is a solution in search of a problem. But at least unsound type projections got restricted, I guess. (That's the only major thing I can think of that will have a larger impact...) Probably the removal of forSome and cleaning up existentials?