Otherwise known as "Haskell"?
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.
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.
As a Scalaz committer and as a developer working at one of the largest scala shops (that makes heavy use of Scalaz), we don't try to write Haskell on the JVM. We do try to write pure, functional code as much as we can, and so what we end up with falls somewhere in the middle between an OCaml and Haskell.
Funnily enough, Scala's implicit-based type classes were the inspiration for the coming modular implicits type classes in OCaml (as opposed to the Haskell approach). It wouldn't be the first time that two languages have mutually inspired each other (The Rust and Swift teams have both acknowledged certain design decisions inspired by the counterpart).
Is it documented anywhere that this was inspired by Haskell? To me, Scala for comprehensions seem syntactically more like a generalization of Python comprehensions than Haskell's monadic do notation.
I think Scala was influenced by Haskell's list comprehensions.
0: needs citation, though I remember reading something semi official about pythons comprehensions being influenced by Haskell. Maybe Python.org's page on Haskell.
But don't mistake that for lack of practicality!
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.
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.
It seems to me Scala is potentially much more "general purpose" than Haskell. In other words, "more practical".
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?
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.
> As an aside, I expect for many things native Scala will equal C++ in performance
Are you familiar with Haskell performance?
> [can Haskell be used for] realtime simulations and games?
Yes.
As I said, I can't speak for hard realtime, but then again, most sims and games seldom require it.
> GC based languages in general aren't good choices for the types of systems discussed above.
You seem to be arguing out of theory (which is why I asked you if you were speaking from experience). We're also not discussing GC based languages "in general"; we are discussing Haskell, which is a very practical language which can and has been used successfully in a variety of real-world applications, and which qualifies as a general purpose language. If in doubt, talk to an actual Haskell practitioner instead of arguing out of theoretical positions, and you'll be surprised. Many such practitioners frequent HN, and I'm sure they are eager (no pun intended) to discuss the systems they've worked in.
For that matter, will Scala Native not be a GC language?
> Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system.
As I argued before, in practice this means Scala is not a great language for OOP or FP. It's understandable that experienced practitioners of either style will prefer cleaner & better languages.
I don't predict a particularly great outcome for Scala outside the JVM, since I think the JVM is its main selling point. Once you remove this point, other languages become distractingly attractive :)