5 ms·

Martin Odersky is a clever guy, there's no doubt about that. But, at the beginning of the talk he introduces the scala compiler as having 40 steps. And he say

Martin Odersky is a clever guy, there's no doubt about that. But, at the beginning of the talk he introduces the scala compiler as having 40 steps. And he says that translating from scala to the JVM is a translation from a complex input to a complex output. And now, Databases. So.. I just don't understand why he would even want to take on such a difficult task. It strikes me that bringing functional programming to the JVM can / has been done simpler: Clojure being the obvious one, but F# on the CLR is another good template. Third, Frege is a Haskell implementation for the JVM which to my mind is a much better long-term bet than Scala: it's already a tried-and-tested language, and the work involved in the translation has taken an order of magnitude less time. It's all very well having some new great language on the JVM, but simplicity is a huge virtue if you want people to build an ecosystem around it.

justthistime_ 11y ago
> It strikes me that bringing functional programming to the JVM can / has been done simpler: Clojure being the obvious one, but F# on the CLR is another good template. Scala's FP is more expressive than all of them, by a large margin. Additionally, Scala also supports an useful OO system, unlike for instance the stuff F#/OCaml/... ships. > It's all very well having some new great language on the JVM, but simplicity is a huge virtue if you want people to build an ecosystem around it. You realize that Scala has probably the largest, and most meaningful ecosystem of all (non-Java) JVM languages, and is driving a lot of the changes in the Java and JVM space? (Reactive streams, value types, specialied generics, ...)
- bobm_kite9 11y ago
  Really good points. I expect you're right about the expressiveness, although I don't really know exactly what you mean by this. The "buffet of abstractions" available in Scala actually put me off it. For me, there are too many options available to expect to have readable, maintainable code at the end of it all, especially if you work in a team which regularly creates almost wilfully hard-to-comprehend java. This video is 2 years old now, but I think it marked the point when I stopped investigating scala. https://www.youtube.com/watch?v=TS1lpKBMkgg&feature=youtube_gdata_player https://www.youtube.com/watch?v=TS1lpKBMkgg&feature=youtube_...
  - joostdevries 11y ago
    Before I clicked the link I knew which video it would be. For some reason it's largely the single fact that people on nyc seem remember about Scala. If you watch the presentation by Odersky you'll find that the new compiler addresses most if not all the things that Paul Philips mentioned. For instance the new compiler has 5 phases. Just like javac.
  - justthistime_ 11y ago
    While I agree with many points in the video, it feels kind of disheartening to me how many people just wave it around as if it could be used as an attack against the language and its community. (A general observation, what you say here is totally fair.) Of course the video is about Scala, but the problems mentioned are widespread throughout the industry. What most of those people miss is the fact that Scala is sometime light years ahead of figuring out hard problems. The things considered to be an issue in Scala is often stuff that hasn't even been considered elsewhere. The video is now 2 years old, and in terms of Scala, that's a lot of time. The strength of the language and the community is that it can adapt pretty fast, and many issues have been/are being addressed. There are plenty of libraries out there which experiment with different approaches to collections, there is a new, faster and cleaner backend, the new compiler is shaping up nicely, the new IR will solve a lot of binary compatibility/cross compilation/Scala<->Scala.js issues, and scala.meta seems to become one of the best metaprogramming abstractions in languages. Things are working really well in Scala, so if you have any question or concerns, feel free to voice them, and I'll give you my 2 cents about what's happening in that space! :-)
sklogic 11y ago
Number of compiler passes does not reflect its "complexity". Can in fact be the opposite - the more distinct passes there are, the simpler each of the passes is, together making the whole thing simpler. > Clojure being the obvious one Clojure, to be honest, is an example of a very convoluted, not very well thought out compiler design. Disclaimer: I know nothing about the actual Scala compiler passes, just commenting on the number of passes as a proxy for complexity.

justthistime_ 11y ago

> It strikes me that bringing functional programming to the JVM can / has been done simpler: Clojure being the obvious one, but F# on the CLR is another good template. Scala's FP is more expressive than all of them, by a large margin. Additionally, Scala also supports an useful OO system, unlike for instance the stuff F#/OCaml/... ships. > It's all very well having some new great language on the JVM, but simplicity is a huge virtue if you want people to build an ecosystem around it. You realize that Scala has probably the largest, and most meaningful ecosystem of all (non-Java) JVM languages, and is driving a lot of the changes in the Java and JVM space? (Reactive streams, value types, specialied generics, ...)

bobm_kite9 11y ago
Really good points. I expect you're right about the expressiveness, although I don't really know exactly what you mean by this. The "buffet of abstractions" available in Scala actually put me off it. For me, there are too many options available to expect to have readable, maintainable code at the end of it all, especially if you work in a team which regularly creates almost wilfully hard-to-comprehend java. This video is 2 years old now, but I think it marked the point when I stopped investigating scala. https://www.youtube.com/watch?v=TS1lpKBMkgg&feature=youtube_gdata_player https://www.youtube.com/watch?v=TS1lpKBMkgg&feature=youtube_...
- joostdevries 11y ago
  Before I clicked the link I knew which video it would be. For some reason it's largely the single fact that people on nyc seem remember about Scala. If you watch the presentation by Odersky you'll find that the new compiler addresses most if not all the things that Paul Philips mentioned. For instance the new compiler has 5 phases. Just like javac.
- justthistime_ 11y ago
  While I agree with many points in the video, it feels kind of disheartening to me how many people just wave it around as if it could be used as an attack against the language and its community. (A general observation, what you say here is totally fair.) Of course the video is about Scala, but the problems mentioned are widespread throughout the industry. What most of those people miss is the fact that Scala is sometime light years ahead of figuring out hard problems. The things considered to be an issue in Scala is often stuff that hasn't even been considered elsewhere. The video is now 2 years old, and in terms of Scala, that's a lot of time. The strength of the language and the community is that it can adapt pretty fast, and many issues have been/are being addressed. There are plenty of libraries out there which experiment with different approaches to collections, there is a new, faster and cleaner backend, the new compiler is shaping up nicely, the new IR will solve a lot of binary compatibility/cross compilation/Scala<->Scala.js issues, and scala.meta seems to become one of the best metaprogramming abstractions in languages. Things are working really well in Scala, so if you have any question or concerns, feel free to voice them, and I'll give you my 2 cents about what's happening in that space! :-)

sklogic 11y ago

Number of compiler passes does not reflect its "complexity". Can in fact be the opposite - the more distinct passes there are, the simpler each of the passes is, together making the whole thing simpler. > Clojure being the obvious one Clojure, to be honest, is an example of a very convoluted, not very well thought out compiler design. Disclaimer: I know nothing about the actual Scala compiler passes, just commenting on the number of passes as a proxy for complexity.