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.
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.
> 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.
Given the fact that OCaml seems to be adding type class support and has support for monadic comprehension (do/for), it seems like these ideas are getting adopted in multiple places.
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).
> It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions),
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.
Python's list comprehensions are a specialization of Haskell's list comprehensions[0].
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.
Well at the very least, Haskell's came first; they were part of Haskell 98 (finalized in 1999) and Python 2.0 (the first version with comprehensions) was released in 2000.
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? :)
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.
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.
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.
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.
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.
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".
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?
"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.
Thanks, I know what hard realtime means, I just meant I didn't have experience with those systems to really debate about them. Do you have practical experience building hard realtime systems?
> 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 :)
