5 ms·

Otherwise known as "Haskell"?

by OhHeyItsE 10y ago

dsabanin 10y ago
Yeah, think of it as practical Haskell that you can actually use in your day to day work ;-)
- the_af 10y ago
  Haskell is a practical language, and one usual impediment for using it in your day to day work is "we must use the JVM". What happens if you remove that requirement? :)
  - dsabanin 10y ago
    Haskell seriously lacks mature tooling, like IDEs, and also libraries. It's still a niche language and it suffers from that. I think it's pretty clear it's not going anywhere close to mainstream any time soon.
    - the_af 10y ago
      That's debatable. Some tooling is needed, some (like IDEs) are mostly unnecessary; crutches we're used to because some languages are unbearable to use otherwise. IMO it's a niche language because, unlike Scala, it requires a clean break from the way the mainstream industry sees programming languages. But don't mistake that for lack of practicality!
      - dsabanin 10y ago
        I don't subscribe to the point that IDEs are crutches any more. I don't rely on IDEs to generate code for me, I use them to explore code and refactor it efficiently. Good refactoring support in IDE can save you a lot of time and errors, especially in the statically typed languages. It has nothing to do with language being unbearable, but a lot to do with the size and complexity of the code you have to work with. I have nothing against Haskell, and before sticking with Scala I've seriously considered it. However, having things like Akka in Scala, an actor/OTP framework that is the only one that is even remotely comparable to what Erlang has, was a huge benefit. Other tools like Play, Spark also made choosing Haskell an unpractical decision for me. Besides, after a couple years of excursion into pure FP-only approach to development, I've understood to myself that OOP is not in any way in opposition to FP, but can be a rather welcome addition. Especially when you work with big code bases and you plan to maintain them for many years to come. And that is an area where Scala really shines.
        cutler 10y ago
        Can you elaborate on this OOP for big code bases argument as I've seen it wheeled out in defence of Java and PHP5 many times but I just don't buy it. Often classes in OOP languages are used not for instantiating objects, which I would argue is their raison d'etre, but simply to encapsulate some data and a bunch of methods. What advantage does this have over simply using your language's namespacing properly? In Clojure and Python, for example, it's easy to place a bunch of functions in a single file, add a namespace and you can manage a codebase of any size. When PHP introduced namespaces in 5.3 I couldn't understand why its Java-esque OOP was still so idiomatic as they solved the main problem it was invented for.
        dsabanin 10y ago
        I'd just say that objects are more powerful constructs than structs, records and simple shapeless datastructure. They enforce structure on your data, and give you at least some clues what you can do with that data, among other things. After writing and maintaining a bunch of code in Clojure, Erlang and functional style Ruby, I feel like OOP+FP gives me greater flexibility in my design options and allows to architect better solutions to my problems.
  - Recurecur 10y ago
    Haskell doesn't seem to be a very good language for doing hard or soft realtime, or simulation (realtime games, flight simulation, robotics, industrial control etc.). On the other hand, given appropriate memory management which looks to be in the works, native Scala seems a pretty good fit. It seems to me Scala is potentially much more "general purpose" than Haskell. In other words, "more practical".
    - the_af 10y ago
      I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either), but Haskell can be used to write simulators and games. Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?
      - Recurecur 10y ago
        "I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either)," Hard and soft realtime both require deadlines to be met, the difference being that in soft realtime a missed deadline is not considered a fatal error, just highly undesirable. Examples: Soft realtime: A game where 60 FPS is desired for smooth animation. Lower frame rates degrade the experience but are tolerated. Hard realtime: Flight surface control software in a fly-by-wire aircraft. Missed deadlines potentially result in a crashed plane - a true "fatal error". Any ahead of time compiled language with deterministic memory performance may be used for hard realtime. Absolute performance isn't required, although it is desirable. As long as memory primitives are available for native Scala that permit pre-allocation, and the GC can be turned off (trivial), it should work fine even for hard realtime. As an aside, I expect for many things native Scala will equal C++ in performance. On the JVM is extremely close to Java in performance. "but Haskell can be used to write simulators and games." Realtime simulations and games? It seems hard to reconcile immutable state with time-based simulation in any efficient way. Then there are garbage collection cycles and laziness to deal with. "Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?" GC based languages in general aren't good choices for the types of systems discussed above. GC is also a problem on smaller hardware (embedded systems for instance) since there should be a much larger memory pool than actually used for good performance. Haskell also throws in laziness, which leads to non-determinism. Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system.
saosebastiao 10y ago
Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost. Any similarity to Haskell is incidental to Haskell/ML's shared background in strongly typed functional programming.
- OhHeyItsE 10y ago
  Incidental? It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), pattern matching, lots of standard lib classes (ex Maybe (Option)), many of the methods in the collections library (map, fold, take, etc) Anyway, I wasn't trying to disparage either of them (or this project). Just poking fun at the seemingly common "I want to use Haskell but I'm forced to deploy on the JVM" use case for Scala.
  - whateveracct 10y ago
    Not to mention that you can get similar power to typeclasses in the language.
  - saosebastiao 10y ago
    > It's pretty well known that Scala was heavily influenced by Haskell. Except that Martin Odersky himself has explicitly said that the primary influences were SML/OCaml and Java. > In particular, do notation (for comprehensions), I'll give you that one > pattern matching Which pre-date Haskell by nearly 2 decades in ML > lots of standard lib classes (ex Maybe (Option)), Also pre-date Haskell by nearly 2 decades, in addition to be named exactly the same as ML. > many of the methods in the collections library (map, fold, take, etc) Which pre-date Haskell by almost 4 decades with origins in LISP. > Just poking fun at the seemingly common "I want to use Haskell but I'm forced to deploy on the JVM" use case for Scala. Which is where the Scalaz folks come in. They want to piggy back off of something successful, as opposed to Frege, which is closer to what they actually want (avoiding success at all costs?). Who knows, maybe they actually like the strict-evaluation by default of Scala/ML, which is quite pragmatic, but definitely more in line with ML than Haskell.
    - 10y ago
rvense 10y ago
"Scala code is like Haskell fanfic."
- tormeh 10y ago
  Correction: Scalaz code is like Haskell fanfic.

Otherwise known as "Haskell"?

dsabanin 10y ago

Yeah, think of it as practical Haskell that you can actually use in your day to day work ;-)

the_af 10y ago
Haskell is a practical language, and one usual impediment for using it in your day to day work is "we must use the JVM". What happens if you remove that requirement? :)
- dsabanin 10y ago
  Haskell seriously lacks mature tooling, like IDEs, and also libraries. It's still a niche language and it suffers from that. I think it's pretty clear it's not going anywhere close to mainstream any time soon.
  - the_af 10y ago
    That's debatable. Some tooling is needed, some (like IDEs) are mostly unnecessary; crutches we're used to because some languages are unbearable to use otherwise. IMO it's a niche language because, unlike Scala, it requires a clean break from the way the mainstream industry sees programming languages. But don't mistake that for lack of practicality!
    - dsabanin 10y ago
      I don't subscribe to the point that IDEs are crutches any more. I don't rely on IDEs to generate code for me, I use them to explore code and refactor it efficiently. Good refactoring support in IDE can save you a lot of time and errors, especially in the statically typed languages. It has nothing to do with language being unbearable, but a lot to do with the size and complexity of the code you have to work with. I have nothing against Haskell, and before sticking with Scala I've seriously considered it. However, having things like Akka in Scala, an actor/OTP framework that is the only one that is even remotely comparable to what Erlang has, was a huge benefit. Other tools like Play, Spark also made choosing Haskell an unpractical decision for me. Besides, after a couple years of excursion into pure FP-only approach to development, I've understood to myself that OOP is not in any way in opposition to FP, but can be a rather welcome addition. Especially when you work with big code bases and you plan to maintain them for many years to come. And that is an area where Scala really shines.
      - cutler 10y ago
        Can you elaborate on this OOP for big code bases argument as I've seen it wheeled out in defence of Java and PHP5 many times but I just don't buy it. Often classes in OOP languages are used not for instantiating objects, which I would argue is their raison d'etre, but simply to encapsulate some data and a bunch of methods. What advantage does this have over simply using your language's namespacing properly? In Clojure and Python, for example, it's easy to place a bunch of functions in a single file, add a namespace and you can manage a codebase of any size. When PHP introduced namespaces in 5.3 I couldn't understand why its Java-esque OOP was still so idiomatic as they solved the main problem it was invented for.
        dsabanin 10y ago
        I'd just say that objects are more powerful constructs than structs, records and simple shapeless datastructure. They enforce structure on your data, and give you at least some clues what you can do with that data, among other things. After writing and maintaining a bunch of code in Clojure, Erlang and functional style Ruby, I feel like OOP+FP gives me greater flexibility in my design options and allows to architect better solutions to my problems.
- Recurecur 10y ago
  Haskell doesn't seem to be a very good language for doing hard or soft realtime, or simulation (realtime games, flight simulation, robotics, industrial control etc.). On the other hand, given appropriate memory management which looks to be in the works, native Scala seems a pretty good fit. It seems to me Scala is potentially much more "general purpose" than Haskell. In other words, "more practical".
  - the_af 10y ago
    I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either), but Haskell can be used to write simulators and games. Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?
    - Recurecur 10y ago
      "I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either)," Hard and soft realtime both require deadlines to be met, the difference being that in soft realtime a missed deadline is not considered a fatal error, just highly undesirable. Examples: Soft realtime: A game where 60 FPS is desired for smooth animation. Lower frame rates degrade the experience but are tolerated. Hard realtime: Flight surface control software in a fly-by-wire aircraft. Missed deadlines potentially result in a crashed plane - a true "fatal error". Any ahead of time compiled language with deterministic memory performance may be used for hard realtime. Absolute performance isn't required, although it is desirable. As long as memory primitives are available for native Scala that permit pre-allocation, and the GC can be turned off (trivial), it should work fine even for hard realtime. As an aside, I expect for many things native Scala will equal C++ in performance. On the JVM is extremely close to Java in performance. "but Haskell can be used to write simulators and games." Realtime simulations and games? It seems hard to reconcile immutable state with time-based simulation in any efficient way. Then there are garbage collection cycles and laziness to deal with. "Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?" GC based languages in general aren't good choices for the types of systems discussed above. GC is also a problem on smaller hardware (embedded systems for instance) since there should be a much larger memory pool than actually used for good performance. Haskell also throws in laziness, which leads to non-determinism. Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system.

saosebastiao 10y ago

Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost. Any similarity to Haskell is incidental to Haskell/ML's shared background in strongly typed functional programming.

OhHeyItsE 10y ago
Incidental? It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), pattern matching, lots of standard lib classes (ex Maybe (Option)), many of the methods in the collections library (map, fold, take, etc) Anyway, I wasn't trying to disparage either of them (or this project). Just poking fun at the seemingly common "I want to use Haskell but I'm forced to deploy on the JVM" use case for Scala.
- whateveracct 10y ago
  Not to mention that you can get similar power to typeclasses in the language.
- saosebastiao 10y ago
  > It's pretty well known that Scala was heavily influenced by Haskell. Except that Martin Odersky himself has explicitly said that the primary influences were SML/OCaml and Java. > In particular, do notation (for comprehensions), I'll give you that one > pattern matching Which pre-date Haskell by nearly 2 decades in ML > lots of standard lib classes (ex Maybe (Option)), Also pre-date Haskell by nearly 2 decades, in addition to be named exactly the same as ML. > many of the methods in the collections library (map, fold, take, etc) Which pre-date Haskell by almost 4 decades with origins in LISP. > Just poking fun at the seemingly common "I want to use Haskell but I'm forced to deploy on the JVM" use case for Scala. Which is where the Scalaz folks come in. They want to piggy back off of something successful, as opposed to Frege, which is closer to what they actually want (avoiding success at all costs?). Who knows, maybe they actually like the strict-evaluation by default of Scala/ML, which is quite pragmatic, but definitely more in line with ML than Haskell.
  - 10y ago

rvense 10y ago

"Scala code is like Haskell fanfic."

tormeh 10y ago
Correction: Scalaz code is like Haskell fanfic.