the core is sound
The core idea of ML is this: strongly typed with parametric polymorphism and full sum and product types, type-inference, first-class functions, first-class state, (almost) first-class modules. Exceptions as first-class non-local control mechanism.
The key innovation Scala have over its predecessors Ocaml and F# which also attempted this merger is that Scala recovers ML-style functional programming as a special case of OO programming, while the predecessors when the other way, which didn't work so well.
I agree that that 1ML is interesting. Some of the warts come from JVM/Java compatibility. In what sense would you argue that OOP can be successfully encoded on top of a typed lambda-calculus? Finally, the relative simplicity of DOT [1] indicates that Scala's core is not that complicated.
[1] N. Amin et al., The Essence of Dependent Object Types. http://infoscience.epfl.ch/record/215280/files/paper.pdf
I expect Scala to gravitate more towards DOT in the future, as early mistakes in Scala's design will be ironed out.
It might be interesting to see how the form of OOP that you are interested in can be expressed in DOT, for example by removing subtyping form D_{<:}. Have a go at it!
1ML is based on F-omega, which has higher kinds but not dependent sums or products, while D_{<:} has path-dependent products but no apparent higher kinds, if I understand the paper correctly.
- The existence of a reasonably well-funded organisation (Typesafe/Lightbend) stewarding Scala was well-received.
- Typesafe/Lightbend's independence also helped, in the sense that I cannot see a Scala-like language succeeded if it had come from e.g. Oracle.
- Scala's open-sourcing of everything helped.
- The well-executed and well-timed Scala-MOOC also helped a great deal.
- Odersky's fame and track-record helped too.
None of those might have driven your Scala adoption (or mine), but they might have helped others to shift their dev towards Scala.
The "new" 1ML paper is already old, and nothing ever happened. (Which is the core issue of ML: Cool papers, but nothing ever ships.)
Since then, DOT has been proven to be sound, dotc can bootstrap itself, and large subsets of "Scala 2" can already be compiled with dotc.
Dotc also sports a very interesting design with its mini-phases + phase-fusion approach, denotations, less desugaring, and a more immutable AST. The speed improvements have been very promising even though no performance tuning has happened so far.
TASTY is on track as a standard IR to express code as an entity that can be produced by different compilers and compiled to different targets like (JVM, JS, ...).
SBT recently gained a compiler interface to drive compilation with dotc, and dotc gained support for producing Scala.js IR.
What happened to 1ML since the paper was published?
Of course it's a lot harder than building one side and then claiming that the other side sucks because the whole paradigm sucks (but we still wanted some research grants (looking at you, OCaml)).
Scala's OO+FP approach allows me to appreciate both sides where they have their strengths. This is in contrast to languages like Haskell which can declare that FP is the best thing ever (because that's the only way to write programs in Haskell ("but, but, you can do these terrible contortions and write things that look like OOP in Haskell" – let's just skip that point, it doesn't add anything to the debate)).
it's just the only currently known way where
both modular and functional sides are actually
useful without introducing completely separate
sub-languages.
would get a lot more funding
In case people were wondering, the 1ML project can be found here: https://www.mpi-sws.org/~rossberg/1ml. The key idea here is that ML-style modules (which in the past were though to need a separate module language) can be coded up into System F-omega (the "workhorse of modern compilation").
I don't think any of the 3 main guys behind it (Russo, Dreyer, Rossberg) works on modules all that much right now. That may explain the relatively tardy speed of development.
I think sequential programming won't be the deciding factor. Error handling becomes more difficult when concurrency is involved. It's unclear whether the monadic approach scales to concurrency. The Erlang experience seems to suggest that more complicated approaches might be appropriate.
Maybe. Tooling is coming in leaps and bounds for dynamic languages. Codebases are also trending way down as companies move to "microservices". Both bode really well for dynamic languages.
I actually think the 10 year future is going to be dominated by languages where you don't need to think in terms of types at all but you get all the benefits behind the scenes.
Yeah, but it tends to involve reimplementing a type system - if anything this is a sign of how mature and easy type systems have become. I think we may see languages with optional/best-effort typing for a while longer, but there will be no more pure dynamic languages; every new language will at the very least have a python3-style language-level standard for how to record type annotations so that tools that work with types can interoperate. And once you have that, it seems stupid not to have the language check at least the simple cases.
> Codebases are also trending way down as companies move to "microservices". Both bode really well for dynamic languages.
I think that's effect rather than cause. If you're writing a big system in (say) Ruby, microservices become the only way to achieve the required level of isolation.
> I actually think the 10 year future is going to be dominated by languages where you don't need to think in terms of types at all but you get all the benefits behind the scenes.
I thought that for a while, but types a really useful tool for thinking with. In Scala I could write Python-like code that wouldn't need any explicit types (they'd all be inferred), but instead I use types to help express the design.
That said, the Scala community seems to be moving away from many of the dumber ideas (mostly along the lines of respecting readability over 'expressiveness').
I don't think it's even that. I mean the symbolic method names are an unfortunate piece of community history that can't die soon enough, but other than that a lot of warts are just failed experiments or things that we now have a better way of doing or even things where a compiler flag gets you the right behaviour but the default is the bad backward-compatible way of doing things - Scala grew organically to reach the point it's at now, and it shows.
If anything I think Typesafe/Lightbend listened to the critics too much and put too much effort into backward compatibility. The best thing for the language would be to remove a lot of old features, many of which are barely used in any case. On the plus side they've taken the positive step of modularizing the standard library and moving pieces out of the core.
To give an equally sincere response: dynamic languages are dead, and languages without higher-kinded types are dying - they're too useful to do without, and Scala shows they're practical. We're still discovering more things you can do with Scala.
I think the language we'll be using in ten or twenty years' time won't be Scala - or it will be a Scala that's changed unrecognizably from the Scala we know today. But I think that whatever language it is will have a strong type system with type inference and higher kinds and some kind of typeclass functionality and probably also traditional-OO subtyping (failing that at least Go-style delegation), will allow method calls without brackets and concise lambdas with something like "_", will have a culture of not using C libraries via FFI, and will be strictly evaluated. If you wrote a clean new version of Scala today there's a lot you'd leave out (you might end up with something that looked rather like Ceylon), but I think those things are here for good. Maybe it'll be Idris, maybe something else.