9 ms·

the core is sound I agree completely. It might be interesting to spell out what that this core is: it is the successful marriage of ML-style functional langu

by mafribe 11y ago

the core is sound I agree completely. It might be interesting to spell out what that this core is: it is the successful marriage of ML-style functional languages with class-based OO. 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.

lmm 11y ago
I actually find non-fatal exceptions to be a poor fit in Scala - much better to have errors be values. I predict successors will not bother with exceptions at all. Even for Java interop, in a language with union types all you'd need is a special marker type Thrown(t: Throwable). I'm kind of surprised Ceylon didn't take this route.
- mafribe 11y ago
  Exceptions are probably the least canonical part of (the sequential part of) the ML-Scala continuum. Maybe it will fall by the wayside. With HKTs monadic error handling becomes relatively painless. I have no strong opinion on this matter. 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.
willtim 11y ago
Much of Scalas complexity comes from trying to encode ML features using subtyping and class-based OO. So I think the jury is still out on whether Scala represents a successful marriage. There are other ways to add first-class modules (objects) to ML, the most interesting is probably the new "1ML" paper. Personally I would rather have OOP encoded in a functional language and not the other way around. This would avoid many of Scala's warts such as a nominal core (e.g. Function1-22), methods not first-class, pattern matches that runtime cast etc.
- mafribe 11y ago
  Depends on the criteria of success. Maybe OO and typed FP can be merged successfully in more than one way. 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 http://infoscience.epfl.ch/record/215280/files/paper.pdf
  - willtim 11y ago
    The criteria of success for me is simplicity and generality. The part of OOP I am interested in is first-class modules, being able to package up types and functions acting on those types into records. Dotty is not the core of the current version of Scala. It does look interesting, but personally I would prefer an approach that does not use subtyping. My point is only that Scala does not represent the last word in FP+OOP.
    - acjohnson55 11y ago
      Interestingly though, Scala's model is basically Javascript, with a sound type system. As much as classes have been discredited as the fundamental structure of a system's architecture, they still prove their usefulness in Java and all the dynamic languages, and now a new crop of languages, like Swift, Rust, and Kotlin. So, I'd suggest that the Scala route may well be the path forward, especially post-DOT.
      - lmm 11y ago
        Huh? Scala has nothing remotely resembling Javascript's weird prototype thing.
        acjohnson55 11y ago
        True, there's nothing in Scala that's like the dynamic inheritance/delegation of JS. But I'd say that in practice, people use Javascript's prototype functionality to implement static class- or mixin-based OOP.

by mafribe 11y ago

lmm 11y ago

I actually find non-fatal exceptions to be a poor fit in Scala - much better to have errors be values. I predict successors will not bother with exceptions at all. Even for Java interop, in a language with union types all you'd need is a special marker type Thrown(t: Throwable). I'm kind of surprised Ceylon didn't take this route.

mafribe 11y ago
Exceptions are probably the least canonical part of (the sequential part of) the ML-Scala continuum. Maybe it will fall by the wayside. With HKTs monadic error handling becomes relatively painless. I have no strong opinion on this matter. 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.

willtim 11y ago

Much of Scalas complexity comes from trying to encode ML features using subtyping and class-based OO. So I think the jury is still out on whether Scala represents a successful marriage. There are other ways to add first-class modules (objects) to ML, the most interesting is probably the new "1ML" paper. Personally I would rather have OOP encoded in a functional language and not the other way around. This would avoid many of Scala's warts such as a nominal core (e.g. Function1-22), methods not first-class, pattern matches that runtime cast etc.

mafribe 11y ago
Depends on the criteria of success. Maybe OO and typed FP can be merged successfully in more than one way. 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 http://infoscience.epfl.ch/record/215280/files/paper.pdf
- willtim 11y ago
  The criteria of success for me is simplicity and generality. The part of OOP I am interested in is first-class modules, being able to package up types and functions acting on those types into records. Dotty is not the core of the current version of Scala. It does look interesting, but personally I would prefer an approach that does not use subtyping. My point is only that Scala does not represent the last word in FP+OOP.
  - acjohnson55 11y ago
    Interestingly though, Scala's model is basically Javascript, with a sound type system. As much as classes have been discredited as the fundamental structure of a system's architecture, they still prove their usefulness in Java and all the dynamic languages, and now a new crop of languages, like Swift, Rust, and Kotlin. So, I'd suggest that the Scala route may well be the path forward, especially post-DOT.
    - lmm 11y ago
      Huh? Scala has nothing remotely resembling Javascript's weird prototype thing.
      - acjohnson55 11y ago
        True, there's nothing in Scala that's like the dynamic inheritance/delegation of JS. But I'd say that in practice, people use Javascript's prototype functionality to implement static class- or mixin-based OOP.