6 ms·

Not a huge fan of Scala[1], but it must be said that Scala.js is AMAZING for what is does. We've been using it in production since 0.4 (I think?) and we've neve

Not a huge fan of Scala[1], but it must be said that Scala.js is AMAZING for what is does. We've been using it in production since 0.4 (I think?) and we've never had any problems that could be traced back to sjs. [1] Long story. "Trapped" programming Scala instead of Haskell by my own conservatism -- and now -- the need to support legacy systems. Still... it's way better than Java, so at least there's that. When thinking of Kotlin I always think of it as a sort of "what Java should have been", but when thinking of Scala I can't help but think "Well, it's not quite Haskell, is it?". (The poor type inference, the whole OOP thing, the lack of TCO means that any Monadic abstraction must be trampolined and that's just cruel.)

premium-concern 10y ago
> but when thinking of Scala I can't help but think "Well, it's not quite Haskell, is it?". (The poor type inference, the whole OOP thing, the lack of TCO means that any Monadic abstraction must be trampolined and that's just cruel. Some good news: - Better type inference at the place were it was sorely needed landed in 2.12 (use -Ypartial-unification to enable) or use it on 2.11 with a compiler plugin. - Even if you are not a fan of OO (I'm not), I still love that I get a great module system for free. Haskell's module system is a completely mess. - Scala-Native already supports all kinds of TCO, including mutually recursive ones.
- lomnakkus 10y ago
  Oh yeah, definitely looking forward to 2.12. Don't get me wrong Scala is still good, just not great. (Hence the scare quotes around "trapped") > - Better type inference at the place were it was sorely needed landed in 2.12 (use -Ypartial-unification to enable) or use it on 2.11 with a compiler plugin. I was actually thinking of things like local definitions not needing type signatures. It's really easy to underestimate how much more fluent this makes the language feel. (Think of functions defined in 'where' clauses and things like that. Entirely subjective, but there's this feeling of fluency when you don't need any type signatures for non-top-level things.) I don't think Scala is ever going to move away from requiring all functions to have an explicit type signature. > - Even if you are not a fan of OO (I'm not), I still love that I get a great module system for free. Haskell's module system is a completely mess. Not so much "mess", I think... more completely underpowered? It's really just a namespacing mechanism. Hopefully we'll get Backpack at some point... > - Scala-Native already supports all kinds of TCO, including mutually recursive ones. Really? This is surprising to me, but perhaps they've gone with the Pascal(?) calling convention so as to make it trivially supportable? It's still sad it can't be relied upon per language spec. :/
  - premium-concern 10y ago
    > It's still sad it can't be relied upon per language spec. :/ There is a @tailrec annotation which ensures that a method was optimized. It probably needs to be updated to understand Scala-Native's new abilities, but the infrastructure is there!
    - lomnakkus 10y ago
      Yes, but IIRC it doesn't work for mutually recursive methods or dynamic(!) tail calls.
      - premium-concern 10y ago
        Yes, because Scala-Native only exists for a month at this point in time.
        lomnakkus 10y ago
        Hm? Not sure why you're bringing up Scala-Native again... @tailrec has existed since 2.8(?). The limitations of @tailrec are obviously due to the JVM, but I was thinking (given your mention) that maybe Scala-Native had done away with the problem -- if you use the "Pascal" calling convention I believe it's mostly completely trivial to do TCO. (Just omit the "push/pop things onto/off stack" bit in the caller and use "goto".)
        premium-concern 10y ago
        > Not sure why you're bringing up Scala-Native again Weren't talking about that? > @tailrec has existed since 2.8 Yes? > I was thinking (given your mention) that maybe Scala-Native had done away with the problem It uses fastcc, and yes it does. I don't understand the issue.
bad_user 10y ago
I'm a Scala Dev now, and I also played with Haskell and various LISPs. I'm one of those that likes OOP and Scala's OOP is the best I've used thus far. And the great thing about Scala is that OOP is consistently used to express everything in it. Scala gets compared with Haskel, but let's compare it with Ocaml. This isn't like Ocaml where you have the HM type system and functors and ADTs and then you have OOP as a separate thing, effectively having two type systems in the same language, while at the same time providing no means for ad-hoc polymorphism, while higher kinds are sort of a hack. People also underestimate the importance of having the JVM as your runtime. At the very least it means you get a capable GC, which makes it feasible to use persistent data structures, and it also means you get multithreading and thus a memory model. Ocaml still doesn't have a memory model, while the GC needs improvement. But back to Haskell. Type-classes are great as a concept, but the implementation leaves something to be desired. First of all in Haskel they are anti modular, because you can't have two conflicting definitions in the same project (not scope, but project). The standard, Haskell 98, is actually unfit for real work, with people referring in fact to GHC and its extensions. Extensions that are often experimental and unstable. And then you've got a powerful type system, but guess what, virtually no IDE tooling is available. And while its laziness is cool, in practice it can get really hard to reason about performance or about the time and space complexity. On the poor type inference of Scala, well, it comes with subtyping. While I'm sure it can be improved, basically if you want OOP, you have to accept weaker type inference. As I said, I happen to like OOP, so I consider that to be a reasonable trade-off. On the lack of TCO, this only really matters for performance reasons. But guess what, the JVM usually beats Haskell in performance by a significant margin, even without TCO. And no, not all monadic abstraction need trampolines. Those are quite few actually, most commonly: Free, IO and Task. Then there's the tooling aspect. Scala has really capable IDEs (plural). And it has SBT and Scala.js. I mean, when I first started to play with Haskell I wondered if a language be that good as people say, when its build tool Cabal is such a piece of shit. You like Scala.js, yet you're not wondering why only a couple of people managed to build it and it's miles ahead of anything similar for Haskell or Ocaml or F#? Actually the only achievement similar to Scala.js would be ClojureScript. One last note: if you want Haskell, then use Haskell. But functional programming isn't necessarily about Haskell and its idioms and Scala is its own language. In other words, you can also say that Haskell isn't Scala and people expecting Scala would be disappointed.

premium-concern 10y ago

> but when thinking of Scala I can't help but think "Well, it's not quite Haskell, is it?". (The poor type inference, the whole OOP thing, the lack of TCO means that any Monadic abstraction must be trampolined and that's just cruel. Some good news: - Better type inference at the place were it was sorely needed landed in 2.12 (use -Ypartial-unification to enable) or use it on 2.11 with a compiler plugin. - Even if you are not a fan of OO (I'm not), I still love that I get a great module system for free. Haskell's module system is a completely mess. - Scala-Native already supports all kinds of TCO, including mutually recursive ones.

lomnakkus 10y ago
Oh yeah, definitely looking forward to 2.12. Don't get me wrong Scala is still good, just not great. (Hence the scare quotes around "trapped") > - Better type inference at the place were it was sorely needed landed in 2.12 (use -Ypartial-unification to enable) or use it on 2.11 with a compiler plugin. I was actually thinking of things like local definitions not needing type signatures. It's really easy to underestimate how much more fluent this makes the language feel. (Think of functions defined in 'where' clauses and things like that. Entirely subjective, but there's this feeling of fluency when you don't need any type signatures for non-top-level things.) I don't think Scala is ever going to move away from requiring all functions to have an explicit type signature. > - Even if you are not a fan of OO (I'm not), I still love that I get a great module system for free. Haskell's module system is a completely mess. Not so much "mess", I think... more completely underpowered? It's really just a namespacing mechanism. Hopefully we'll get Backpack at some point... > - Scala-Native already supports all kinds of TCO, including mutually recursive ones. Really? This is surprising to me, but perhaps they've gone with the Pascal(?) calling convention so as to make it trivially supportable? It's still sad it can't be relied upon per language spec. :/
- premium-concern 10y ago
  > It's still sad it can't be relied upon per language spec. :/ There is a @tailrec annotation which ensures that a method was optimized. It probably needs to be updated to understand Scala-Native's new abilities, but the infrastructure is there!
  - lomnakkus 10y ago
    Yes, but IIRC it doesn't work for mutually recursive methods or dynamic(!) tail calls.
    - premium-concern 10y ago
      Yes, because Scala-Native only exists for a month at this point in time.
      - lomnakkus 10y ago
        Hm? Not sure why you're bringing up Scala-Native again... @tailrec has existed since 2.8(?). The limitations of @tailrec are obviously due to the JVM, but I was thinking (given your mention) that maybe Scala-Native had done away with the problem -- if you use the "Pascal" calling convention I believe it's mostly completely trivial to do TCO. (Just omit the "push/pop things onto/off stack" bit in the caller and use "goto".)
        premium-concern 10y ago
        > Not sure why you're bringing up Scala-Native again Weren't talking about that? > @tailrec has existed since 2.8 Yes? > I was thinking (given your mention) that maybe Scala-Native had done away with the problem It uses fastcc, and yes it does. I don't understand the issue.

bad_user 10y ago

I'm a Scala Dev now, and I also played with Haskell and various LISPs. I'm one of those that likes OOP and Scala's OOP is the best I've used thus far. And the great thing about Scala is that OOP is consistently used to express everything in it. Scala gets compared with Haskel, but let's compare it with Ocaml. This isn't like Ocaml where you have the HM type system and functors and ADTs and then you have OOP as a separate thing, effectively having two type systems in the same language, while at the same time providing no means for ad-hoc polymorphism, while higher kinds are sort of a hack. People also underestimate the importance of having the JVM as your runtime. At the very least it means you get a capable GC, which makes it feasible to use persistent data structures, and it also means you get multithreading and thus a memory model. Ocaml still doesn't have a memory model, while the GC needs improvement. But back to Haskell. Type-classes are great as a concept, but the implementation leaves something to be desired. First of all in Haskel they are anti modular, because you can't have two conflicting definitions in the same project (not scope, but project). The standard, Haskell 98, is actually unfit for real work, with people referring in fact to GHC and its extensions. Extensions that are often experimental and unstable. And then you've got a powerful type system, but guess what, virtually no IDE tooling is available. And while its laziness is cool, in practice it can get really hard to reason about performance or about the time and space complexity. On the poor type inference of Scala, well, it comes with subtyping. While I'm sure it can be improved, basically if you want OOP, you have to accept weaker type inference. As I said, I happen to like OOP, so I consider that to be a reasonable trade-off. On the lack of TCO, this only really matters for performance reasons. But guess what, the JVM usually beats Haskell in performance by a significant margin, even without TCO. And no, not all monadic abstraction need trampolines. Those are quite few actually, most commonly: Free, IO and Task. Then there's the tooling aspect. Scala has really capable IDEs (plural). And it has SBT and Scala.js. I mean, when I first started to play with Haskell I wondered if a language be that good as people say, when its build tool Cabal is such a piece of shit. You like Scala.js, yet you're not wondering why only a couple of people managed to build it and it's miles ahead of anything similar for Haskell or Ocaml or F#? Actually the only achievement similar to Scala.js would be ClojureScript. One last note: if you want Haskell, then use Haskell. But functional programming isn't necessarily about Haskell and its idioms and Scala is its own language. In other words, you can also say that Haskell isn't Scala and people expecting Scala would be disappointed.