7 ms·

There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies. I'd like to share a different persp

There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies. I'd like to share a different perspective based on my own work with OOP-centric and FP-centric languages. If you take OOP to its logical conclusion, OOP is a slippery slope that eventually leads to Gang-Of-Four centric designs. If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs. Both are equally valid ways to design complex applications, so it all comes down to individual taste. Personally I have a taste for mathematical abstractions, so Scala is better suited for my way of thinking. It's obvious that Scala was specifically designed to be a solid foundation on which one can implement the concepts of a little known branch of mathematics called the category theory, and almost every design choice in the language flows from there. If we use this as the basis for comparison to other languages, it's very easy to understand that Scala has carved out a very powerful niche for itself and is here to stay.

jowiar 8y ago
I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured community.
- nextos 8y ago
  Designing good multi-paradigm languages is very hard. I'm a big fan of Mozart-Oz and Common Lisp, and I think Odersky did a really good job with Scala. In fact, given that Common Lisp is languishing and Mozart was never a serious real world contender, Scala fills in a niche where there are not many competitors. C++, just for some use cases, Julia for others, and .NET. The fact that many organizations working on massive datasets have embraced Scala proves there are not many alternatives around, sadly.
  - auvi 8y ago
    > Common Lisp is languishing can you elaborate more on that?
    - nextos 8y ago
      I don't think CL is attracting a lot of new developers or there's a lot of new libraries getting developed. But I would be glad to be proven wrong. Perhaps Racket will eventually become a CL replacement, now it's adopting a lot of Chez low-level stuff and it's multiparadigm efforts keep growing.
      - joshlemer 8y ago
        Do you have any ideas why Racket has not had the commercial success of Clojure for example?
        didibus 8y ago
        My guess would be the JVM. Racket is an academic language, designed for academia. At least it markets itself as such. Made to explore the design space of programming languages. Clojure was designed and marketed for the enterprise. Builds on the JVM, full Java interop, emphasis on pragmatism.
- YorkshireSeason 8y ago
  Haskell is category theory as a language. I disagree with this. Haskell's creation [1, 2] predates the realisation (by the FP community at large) of the close connection between parts of category theory and parts of pure functional programming, which happened in the 1990s, perhaps driven by Moggi's realisation that monads are a fundamental abstraction in computation that can reconcile effects with pure functional computation. More importantly, there is no category "Hask" of Haskell programs, and there isn't even a candidate category that's even close. One of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world, although this is not the only motive (tight integration of OO and FP being another). Haskell's key innovation over its predecessors (Miranda and ML) was the addition of higher-kinded types, which in turn made ad-hoc polymorphism digestable in a typed world (in the form of type-classes). The combination of HKTs and type-classes enables the monadic abstractions that contemporary Haskell programming is widely known for today. Note that Scala has HKTs and type classes (via implicits), so Haskell programs can typically transliterated into idiomatic Scala without major complications. [1] P. Hudak, J. Hughes, S. Peyton Jones, P. Wadler, A History of Haskell: Being Lazy With Class. http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor... [2] Interview with Simon Peyton-Jones. http://www.cs.cmu.edu/~popl-interviews/peytonjones.html http://www.cs.cmu.edu/~popl-interviews/peytonjones.html [3] E. Moggi, Notions of Computation and Monads. https://core.ac.uk/download/pdf/21173011.pdf https://core.ac.uk/download/pdf/21173011.pdf
  - jowiar 8y ago
    Would love to see a citation re: Odersky (or if he'd chime in here). My general assumption is that if Scala was intended to be category theory, implemented, something along the lines of scalaz or cats would have been built into the language -- the philosophy of the language does not include a JS-esque philosophy of small stdlib, big library ecosystem.
    - yawaramin 8y ago
      See this talk https://youtu.be/P8jrvyxHodU https://youtu.be/P8jrvyxHodU He mentions module systems fairly early on.
- tathougies 8y ago
  > I disagree with that. Haskell is category theory as a language No it is really not. Haskell only really has one category of any import, typically denoted 'Hask'. There is no builtin way to embed or express arbitrary categories in Haskell. It's not even clear what this would mean, given that Haskell only has one conception of arrow (the function type '->'). In fact, Haskell is so far removed from true category theory that we have to use a compiler plugin (CCC by Conal Elliot) to get anything approaching compilation to arbitrary categories. Haskell is based on the polymorphically typed lambda calculus. Some decades after its design, some people realized they could use some abstract algebra concepts to help structure programs. You can use these concepts in any language with a sufficiently expressive type system. It is not specific to Haskell
endgame 8y ago
> If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs. I don't understand what you mean by this, and I write production haskell for a living. We don't have teetering towers of transformers, and the best advice I've seen is often "put away the shiny tools and just use functions", https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ https://lukepalmer.wordpress.com/2010/01/24/haskell-antipatt... . Similarly in http://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html http://www.parsonsmatt.org/2018/03/22/three_layer_haskell_ca... , which is like one real transformer layer and a way of claiming only the capabilities you need in your impure code. His "invert your mocks" article talks about this, too. Ed Kmett's comments on Scala make me worry that the "solid foundation" isn't as solid as it could be: https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu/ https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the... . How much of this is true in more recent Scala versions?
- lmm 8y ago
  > Ed Kmett's comments on Scala make me worry that the "solid foundation" isn't as solid as it could be: https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the.. https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the.... . How much of this is true in more recent Scala versions? Some are fixed (Either, inference for many of the type lambda cases), some are being fixed in the next version (container overloads, CanBuildFrom), some are not really issues at all (free theorems are fine, an extra map on a monad is not a problem and sometimes more efficient, specific compiler bugs have been fixed but never said anything about the language in general, Haskell as used in the wild (with orphan instances) doesn't guarantee typeclass coherence either), some are real but exaggerated issues (subtyping and implicits, type inference for tricky recursion), a few are genuine issues that remain and probably always will (having to trampoline your monads, no kind system).
- coldtea 8y ago
  >I don't understand what you mean by this, and I write production haskell for a living. Well, "It is difficult to get a man to understand something when his salary depends upon his not understanding it" - Upton Sinclair
lmm 8y ago
> It's obvious that Scala was specifically designed to be a solid foundation on which one can implement the concepts of a little known branch of mathematics called the category theory, and almost every design choice in the language flows from there. Nonsense. Scala was designed to make programming easier and safer than Java - XML literals and pattern matching certainly have nothing to do with category theory. Scala's for/yield has surprising behaviour when e.g. mixing lists and sets, precisely because it doesn't have a categorical grounding and was implemented in terms of what working programmers wanted to do with it rather than enforcing that you've formed a valid semigroupoid in the category of endofunctors. Over time it's emerged that some categorical constructs provide useful ways of thinking about code and solving programming problems, but you're putting the cart before the horse if you think the language was designed for category theory.
- bad_user 8y ago
  > Scala's for/yield has surprising behaviour ... because it doesn't have a categorical grounding Not sure what you're talking about, but for/yield is syntactic sugar for map/flatMap, just like the "do notation" is in Haskell. Of course it has theoretical grounding, because it wouldn't work without flatMap being the monadic bind. > mixing lists and sets Again, not entirely sure what you're talking about, but if true, it's entirely unrelated to for/yield.
  - JD557 8y ago
    I believe that he's referring to the fact that Scala's Set is not a monad, so it "shouldn't" have a .flatMap operation. Scala has other containers that have a .flatMap operation that are not real monads, such as Future and Try. That can lead to surprising behavior on for/yeld loops. Disclaimer: I do work in Scala and enjoy the language.
  - lmm 8y ago
    I mean if you write something like: (for { x <- List(1, 1, 1) y <- Set(x) z <- List(y, y) } yield z).length the answer will be rather surprising, because in Scala for/yield is not necessarily monadic.

jowiar 8y ago

I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured community.

nextos 8y ago
Designing good multi-paradigm languages is very hard. I'm a big fan of Mozart-Oz and Common Lisp, and I think Odersky did a really good job with Scala. In fact, given that Common Lisp is languishing and Mozart was never a serious real world contender, Scala fills in a niche where there are not many competitors. C++, just for some use cases, Julia for others, and .NET. The fact that many organizations working on massive datasets have embraced Scala proves there are not many alternatives around, sadly.
- auvi 8y ago
  > Common Lisp is languishing can you elaborate more on that?
  - nextos 8y ago
    I don't think CL is attracting a lot of new developers or there's a lot of new libraries getting developed. But I would be glad to be proven wrong. Perhaps Racket will eventually become a CL replacement, now it's adopting a lot of Chez low-level stuff and it's multiparadigm efforts keep growing.
    - joshlemer 8y ago
      Do you have any ideas why Racket has not had the commercial success of Clojure for example?
      - didibus 8y ago
        My guess would be the JVM. Racket is an academic language, designed for academia. At least it markets itself as such. Made to explore the design space of programming languages. Clojure was designed and marketed for the enterprise. Builds on the JVM, full Java interop, emphasis on pragmatism.
YorkshireSeason 8y ago
Haskell is category theory as a language. I disagree with this. Haskell's creation [1, 2] predates the realisation (by the FP community at large) of the close connection between parts of category theory and parts of pure functional programming, which happened in the 1990s, perhaps driven by Moggi's realisation that monads are a fundamental abstraction in computation that can reconcile effects with pure functional computation. More importantly, there is no category "Hask" of Haskell programs, and there isn't even a candidate category that's even close. One of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world, although this is not the only motive (tight integration of OO and FP being another). Haskell's key innovation over its predecessors (Miranda and ML) was the addition of higher-kinded types, which in turn made ad-hoc polymorphism digestable in a typed world (in the form of type-classes). The combination of HKTs and type-classes enables the monadic abstractions that contemporary Haskell programming is widely known for today. Note that Scala has HKTs and type classes (via implicits), so Haskell programs can typically transliterated into idiomatic Scala without major complications. [1] P. Hudak, J. Hughes, S. Peyton Jones, P. Wadler, A History of Haskell: Being Lazy With Class. http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor... [2] Interview with Simon Peyton-Jones. http://www.cs.cmu.edu/~popl-interviews/peytonjones.html http://www.cs.cmu.edu/~popl-interviews/peytonjones.html [3] E. Moggi, Notions of Computation and Monads. https://core.ac.uk/download/pdf/21173011.pdf https://core.ac.uk/download/pdf/21173011.pdf
- jowiar 8y ago
  Would love to see a citation re: Odersky (or if he'd chime in here). My general assumption is that if Scala was intended to be category theory, implemented, something along the lines of scalaz or cats would have been built into the language -- the philosophy of the language does not include a JS-esque philosophy of small stdlib, big library ecosystem.
  - yawaramin 8y ago
    See this talk https://youtu.be/P8jrvyxHodU https://youtu.be/P8jrvyxHodU He mentions module systems fairly early on.
tathougies 8y ago
> I disagree with that. Haskell is category theory as a language No it is really not. Haskell only really has one category of any import, typically denoted 'Hask'. There is no builtin way to embed or express arbitrary categories in Haskell. It's not even clear what this would mean, given that Haskell only has one conception of arrow (the function type '->'). In fact, Haskell is so far removed from true category theory that we have to use a compiler plugin (CCC by Conal Elliot) to get anything approaching compilation to arbitrary categories. Haskell is based on the polymorphically typed lambda calculus. Some decades after its design, some people realized they could use some abstract algebra concepts to help structure programs. You can use these concepts in any language with a sufficiently expressive type system. It is not specific to Haskell

endgame 8y ago

> If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs. I don't understand what you mean by this, and I write production haskell for a living. We don't have teetering towers of transformers, and the best advice I've seen is often "put away the shiny tools and just use functions", https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ https://lukepalmer.wordpress.com/2010/01/24/haskell-antipatt... . Similarly in http://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html http://www.parsonsmatt.org/2018/03/22/three_layer_haskell_ca... , which is like one real transformer layer and a way of claiming only the capabilities you need in your impure code. His "invert your mocks" article talks about this, too. Ed Kmett's comments on Scala make me worry that the "solid foundation" isn't as solid as it could be: https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu/ https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the... . How much of this is true in more recent Scala versions?

lmm 8y ago
> Ed Kmett's comments on Scala make me worry that the "solid foundation" isn't as solid as it could be: https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the.. https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the.... . How much of this is true in more recent Scala versions? Some are fixed (Either, inference for many of the type lambda cases), some are being fixed in the next version (container overloads, CanBuildFrom), some are not really issues at all (free theorems are fine, an extra map on a monad is not a problem and sometimes more efficient, specific compiler bugs have been fixed but never said anything about the language in general, Haskell as used in the wild (with orphan instances) doesn't guarantee typeclass coherence either), some are real but exaggerated issues (subtyping and implicits, type inference for tricky recursion), a few are genuine issues that remain and probably always will (having to trampoline your monads, no kind system).
coldtea 8y ago
>I don't understand what you mean by this, and I write production haskell for a living. Well, "It is difficult to get a man to understand something when his salary depends upon his not understanding it" - Upton Sinclair

lmm 8y ago

> It's obvious that Scala was specifically designed to be a solid foundation on which one can implement the concepts of a little known branch of mathematics called the category theory, and almost every design choice in the language flows from there. Nonsense. Scala was designed to make programming easier and safer than Java - XML literals and pattern matching certainly have nothing to do with category theory. Scala's for/yield has surprising behaviour when e.g. mixing lists and sets, precisely because it doesn't have a categorical grounding and was implemented in terms of what working programmers wanted to do with it rather than enforcing that you've formed a valid semigroupoid in the category of endofunctors. Over time it's emerged that some categorical constructs provide useful ways of thinking about code and solving programming problems, but you're putting the cart before the horse if you think the language was designed for category theory.

bad_user 8y ago
> Scala's for/yield has surprising behaviour ... because it doesn't have a categorical grounding Not sure what you're talking about, but for/yield is syntactic sugar for map/flatMap, just like the "do notation" is in Haskell. Of course it has theoretical grounding, because it wouldn't work without flatMap being the monadic bind. > mixing lists and sets Again, not entirely sure what you're talking about, but if true, it's entirely unrelated to for/yield.
- JD557 8y ago
  I believe that he's referring to the fact that Scala's Set is not a monad, so it "shouldn't" have a .flatMap operation. Scala has other containers that have a .flatMap operation that are not real monads, such as Future and Try. That can lead to surprising behavior on for/yeld loops. Disclaimer: I do work in Scala and enjoy the language.
- lmm 8y ago
  I mean if you write something like: (for { x <- List(1, 1, 1) y <- Set(x) z <- List(y, y) } yield z).length the answer will be rather surprising, because in Scala for/yield is not necessarily monadic.