5 ms·

Subtyping isn't just for the benefit of Java compatibility. What makes you think that? Such arguments are in general hand-wavy and born out of folklore or pers

Subtyping isn't just for the benefit of Java compatibility. What makes you think that? Such arguments are in general hand-wavy and born out of folklore or personal biases and I hate to appeal to the popularity argument, but in the presence of overwhelming popularity of languages that do have type-systems with subtyping, you do need at least some sort of proof that subtyping is bad in one way or another. Even GHC has extensions for subtyping, without being burdened with Java compatibility. And what are you comparing Scala with exactly? If you're comparing it with Clojure or other LISPs, well that's like comparing apples to oranges, because there's a world of difference between techniques used in static languages like Haskell/ML and Scala on one hand and LISPs on the other. "flatMap" in particular is not something that you see often in Clojure. You don't quite see many instances of monadic types in languages like Clojure either. Scala's Option[T] or Haskell's Maybe are impractical in Clojure so you'll never see it in Clojure unless you're looking at code that was written by a Haskell developer. Etc... Compared to Haskell, Scala does have some disadvantages, however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem ... you've got everything, including capable IDEs like IntelliJ IDEA and people that complain about SBT never tried Cabal, plus with the JVM you can always use Maven or just plain Jars manually copied in a directory.

papsosouid 14y ago
>Subtyping isn't just for the benefit of Java compatibility. What makes you think that? No objects = no subtyping. >you do need at least some sort of proof that subtyping is bad in one way or another. Why do I need proof of something I didn't say? >Even GHC has extensions for subtyping, What? >however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem The ecosystem matters the least when learning for learning sake. The complexity and difficulty of the language matter, and scala is a poor choice for that reason. You can't just learn FP with scala, you also have to learn all the hairy OO/FP integration and the ensuing problems around it.
- bad_user 14y ago
  > No objects = no subtyping. You are confusing OOP with subtyping. On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell. > The ecosystem matters the least when learning for learning sake. Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular, because as soon as you read a couple of chapters from a book, it's usually easy to let your imagination loose and build something. In comparison to learning math where proofs are like puzzles, in software engineering the real joy comes from building stuff.
  - recursive 14y ago
    I get plenty of joy out of solving Project Euler problems.
  - sold 14y ago
    > On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell. The point of subtyping is implicit coercions: using a type T1 when T2 is expected, without extra conversion. Dynamic and existentials are not subtypes (you need fromDyn or the data constructor introducing the existential). OOHaskell is as far as I know a failed and abandoned experiment. Who uses it? I don't know HList enough to comment, but it's based on GHC's constraint system and very much unlike subtyping in Scala. I agree with you that OOP is not the same as subtyping. Here's how variance complicates stuff in Scala: http://www.reddit.com/r/haskell/comments/zxcks/haskell_vs_f_vs_scala_a_highlevel_language/c68ybn1 http://www.reddit.com/r/haskell/comments/zxcks/haskell_vs_f_... >> The ecosystem matters the least when learning for learning sake. > Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular [...] No, the comparison with Python is not fair. Python is a polar opposite of Haskell. People learn Python as a scripting language. You can learn the basics of the language extremely fast. There's little didactic value in Python the language once you know imperative programming. Then real work comes by learning libraries, frameworks, APIs etc. People learn Haskell as a way to broaden horizons, see a different paradigm. GHC, with standard library only (covering a lot less than Python's batteries) gives enough material to experiment for months if not years. It takes a while to understand GADTs, type classes, kinds, higher-order types, type families etc. Learning Haskell is much closer to learning proofs/doing puzzles than software engineering. The fact that you made your program compile after two hours is rewarding like solving a puzzle. I have seen people attempting to build a concurrent web server in Haskell in first week, not knowing how laziness or class instances work and blaming Haskell for making things weird and unintuitive. The practical mindset of Python does not pay off in Haskell. So I agree with OP - the ecosystem is least concern when learning FP for learning sake.
- nbouscal 14y ago
  > No objects = no subtyping. That statement is patently false.
  - papsosouid 14y ago
    Only if you try to interpret it out of context. The only subtyping in scala is on objects. Without objects, scala would not have subtyping.

papsosouid 14y ago

>Subtyping isn't just for the benefit of Java compatibility. What makes you think that? No objects = no subtyping. >you do need at least some sort of proof that subtyping is bad in one way or another. Why do I need proof of something I didn't say? >Even GHC has extensions for subtyping, What? >however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem The ecosystem matters the least when learning for learning sake. The complexity and difficulty of the language matter, and scala is a poor choice for that reason. You can't just learn FP with scala, you also have to learn all the hairy OO/FP integration and the ensuing problems around it.

bad_user 14y ago
> No objects = no subtyping. You are confusing OOP with subtyping. On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell. > The ecosystem matters the least when learning for learning sake. Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular, because as soon as you read a couple of chapters from a book, it's usually easy to let your imagination loose and build something. In comparison to learning math where proofs are like puzzles, in software engineering the real joy comes from building stuff.
- recursive 14y ago
  I get plenty of joy out of solving Project Euler problems.
- sold 14y ago
  > On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell. The point of subtyping is implicit coercions: using a type T1 when T2 is expected, without extra conversion. Dynamic and existentials are not subtypes (you need fromDyn or the data constructor introducing the existential). OOHaskell is as far as I know a failed and abandoned experiment. Who uses it? I don't know HList enough to comment, but it's based on GHC's constraint system and very much unlike subtyping in Scala. I agree with you that OOP is not the same as subtyping. Here's how variance complicates stuff in Scala: http://www.reddit.com/r/haskell/comments/zxcks/haskell_vs_f_vs_scala_a_highlevel_language/c68ybn1 http://www.reddit.com/r/haskell/comments/zxcks/haskell_vs_f_... >> The ecosystem matters the least when learning for learning sake. > Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular [...] No, the comparison with Python is not fair. Python is a polar opposite of Haskell. People learn Python as a scripting language. You can learn the basics of the language extremely fast. There's little didactic value in Python the language once you know imperative programming. Then real work comes by learning libraries, frameworks, APIs etc. People learn Haskell as a way to broaden horizons, see a different paradigm. GHC, with standard library only (covering a lot less than Python's batteries) gives enough material to experiment for months if not years. It takes a while to understand GADTs, type classes, kinds, higher-order types, type families etc. Learning Haskell is much closer to learning proofs/doing puzzles than software engineering. The fact that you made your program compile after two hours is rewarding like solving a puzzle. I have seen people attempting to build a concurrent web server in Haskell in first week, not knowing how laziness or class instances work and blaming Haskell for making things weird and unintuitive. The practical mindset of Python does not pay off in Haskell. So I agree with OP - the ecosystem is least concern when learning FP for learning sake.
nbouscal 14y ago
> No objects = no subtyping. That statement is patently false.
- papsosouid 14y ago
  Only if you try to interpret it out of context. The only subtyping in scala is on objects. Without objects, scala would not have subtyping.