7 ms·

Now I'm somewhat biased, but that complete list of advantages also applies to Haskell. [^1] In fact, nearly all of the claims made about Clojure here can be ma

Now I'm somewhat biased, but that complete list of advantages also applies to Haskell. [^1] In fact, nearly all of the claims made about Clojure here can be made about haskell more strongly. I've half a mind to do a direct comparison on every point. I'd be interested to hear the author's thoughts on the similarities and differences. [^1] With the obvious exceptions of s-expressions, java/js interop, and "subjectively good design".

cdmckay 6y ago
The JVM interop is a huge positive for Clojure, in my opinion. Being able to consume any JVM library makes Clojure usable in many more professional settings than Haskell.
- fiddlerwoaroof 6y ago
  Yeah, I worked at a company where several Haskell projects crashed and burned because of interop issues with existing JVM systems, but the Clojure project I worked on did really well.
- johnday 6y ago
  Yeah, that makes sense. If the killer app is JVM interop, nothing but JVM based languages should even be on the table. The "why Clojure?" question just becomes "because Clojure is the best language on the JVM," which is not too interesting of a topic IMO. Haskell has decent interop with C/C++ languages, but certainly nobody uses haskell because of that.
  - BoiledCabbage 6y ago
    If the killer app is practical usage than Clojure clearly comes out on top. The problem with function language adoption is people keep pushing Haskell likes it's anything more than at its essense a language exploration research project. The fact that you'd have a comment that ignores a language because it wins by default because it practical is more proof that people evaluating languages are speaking two different... well languages. Some are looking for what they feel have the coolest ideas, others are looking for languages with very cool ideas, much better than what they're using today, and can still be effective/ productive in. Haskell is cool if you want to think about or play with ideas. Clojure is cool ideas, and can still be productive in (ie full modern library support). As well if you don't know, F# falls into that same bucked of cool ideas, better than your avg imperative language and can still be very productive due to language and .net library. We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. Otherwise the produvtivity loss from lack of libraries is almost impossible to overcome from any possible produvtivity gains from the language.
    - mumblemumble 6y ago
      > We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. I certainly hope this does not turn out to be the case. Both the JVM and .NET impose a certain type system on all their client languages. Those languages have an option to embrace it, like F# or Kotlin have, or to struggle against it, like Scala has, but they don't have the option to truly pull free of it. Not without shutting out effortless interop with the rest of the platform, and, in doing so, undermining the whole purpose of being on those platforms in the first place. And, since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation.
      - BoiledCabbage 6y ago
        > since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation. Not disagreeing at all. Interop with a library means interop/conformance with its type system. Which means if you want languages with new / innovative type systems, someone will need to build a library system to resolve this. Either an untyped library system as large as the .NET or Java library systems, or a library that has a trivial way to tack on type transformation of some form so that each language that interops with it can minimally add a type translation layer between the two. What that looks like, I'm not certain. But as long as engineers need to be productive, they need a robust modern library system. No new lang will get adopted if the lang author also needs to build up a complete library system, so it must be a general component.
        mumblemumble 6y ago
        I'm hopeful that Rust will lead in a good direction. A C-style ABI, by virtue of being the least common denominator, is probably the best bet for re-usability across paradigms. Higher level languages would want to write idiomatic façades, but they already habitually do that anyway, even on higher-level platforms like Java and .NET. And I think that deterministic memory management is probably also a pretty important feature. You don't want your libraries all bringing their own clever ideas about object lifetimes and such. But you also need it to be very reliable; a real danger with inviting libraries written in C and C++ into your process space is that they are liable to corrupt your memory. Rust's affine type system seems like a big step in the right direction here. Similar thoughts for the error model. I don't have any particular complaints about exceptions, except that you don't want to be bleeding them on an external API, because that ends up being another spot where languages can fail to mesh. What's missing, though, is that there is no good cross-platform standard for libraries that work with the C ABI (neither in source nor binary form) for other languages to plug into. So that's where I get to thinking that Rust might be closer to (if not exactly at) the mark than C is.
  - andrewem 6y ago
    I think there are at least two cases where JVM interoperability is relevant. The first is when a company is already using the JVM and so knows how to deploy and monitor it; in that case, it’s easy to choose because it presumably imposes limited burdens on the company’s operations people. The second case is when you want access to some mature environment, so that all kinds of packages and services are available to support it, but don’t have a commitment to any one in particular yet, and Clojure qualifies because of the JVM; in that case, a non-JVM language like Python, PHP, or Ruby might also work.
  - didibus 6y ago
    It's not just killer JVM interop, it's killer all around interop. Clojure relies on interop more than any other major language, the language has inherent syntax around it and even its standard library is designed with it in mind. That makes it very easy to adapt over different runtimes, giving Clojure more reach than most. That's why you have Clojure JVM, Clojure CLR, Clojure Unity, ClojureScript, Clojerl (Clojure on BEAM), etc.
- city41 6y ago
  ClojureScript is another plus. I'm unsure what Haskell's story is for frontend dev (I have no Haskell experience).
  - johnday 6y ago
    The GHC compiles Haskell either directly to assembly or via LLVM. There is a GHCJS project, which works fine, but personally I've not used it. There's not much of a story in terms of frontend Haskell. On the other hand, there are two "child" languages of Haskell for the job: Elm, which is a frontend-focused language, and PureScript, which compiles to JS and is designed for that use case.
  - teodorlu 6y ago
    As someone who tried out GHCJS, then Purescript, then Elm, then Clojurescript: - GHCJS and purescript are powerful, but the learning experience might be steep[1] - Elm is an excellent entrypoint into ML programming in the browser. Solid story for new users, and a great standard library for interactive web applications. - ClojureScript differs from Elm in that it embraces its host, with all its power and all its wrinkles. Writing Elm is mostly a smooth experience. Read the guide[2], then you can actually build a web app. I've spent the most time with Elm. Other people might have different experiences. [1]: a few years since I tried, might be better now. [2]: https://guide.elm-lang.org/ https://guide.elm-lang.org/
vnorilo 6y ago
I actually don't want to get into the argument over which is better, but dynamic and static types do change everything, also with regard to how those features in the list feel in a language.
- johnday 6y ago
  Agreed! Asking which language is "better" is a fool's errand. But talking about specific upsides, especially in comparison with other languages, is a useful reductivist tool in determining how we can improve the story for each language.
teodorlu 6y ago
I really appreciate both Clojure and Haskell. I agree that > nearly all of the claims made about Clojure here can be made about haskell , but I'm not sure about `more strongly´. ## DX with Haskell (and ML friends) I miss in Clojure: - Harder to do sound, up-front design with data types and module interface, where implementation becomes almost trivial after when the type signatures make sense - Consistency checks from compiler / type checker ## DX with Clojure I miss in Elm/Haskell: - REPL ergonomics, where every action I could think of makes sense as a REPL command, leading to very small incremental pieces. - Excellent default data structures with literal representation and serialization (EDN) I'd love to read a point-by-point discussion of the article sections comparing Haskell and Clojure, though that's much to ask for in the comments field.
- JackMorgan 6y ago
  I've done a non trivial amount of both Haskell and Clojure, and this comment really hits the nail on the head. Each has non-overlapping strengths that I miss when switching. However, I've lately found F# to be my nearly perfect blend of enough things that I regularly use that I mostly just use that or Haskell when I'm messing about with katas.
  - teodorlu 6y ago
    As someone who hasn't written any F#, I'm curious about F#'s advantages over Haskell.
    - JackMorgan 6y ago
      I've had bad luck with Haskell's laziness causing hard to debug performance issues. Also the lack of libraries really hurts when it comes to even basics like queue and database interactions. Many times there's a few libraries that are all half finished. Don't get me wrong, I really like Haskell a lot, I just find that F# brings a lot of well-thought out compromise between Haskell and the wealth of libraries in .NET for production code. If it was my money in my startup, I'd have no qualms betting on F# to get me to market as soon as possible. If it was my personal OSS project that I work on for personal edification and enrichment, I'd choose Haskell nearly every time.
fulafel 6y ago
Compared to Haskell, Clojure, like Elixir and Erlang and Scheme, is a much smaller and simpler language and is easier to learn especially for people without a theoretical CS / math background. This is due to Haskell's ambitious and powerful static type system.
- mac01021 6y ago
  I'm not sure Clojure is _simpler_. I think Haskell may have more regularity and less variety in language constructs. I won't dispute that it is more alien to most programmers, though, and that laziness and monadic IO require a bunch of work to get used to.
didibus 6y ago
Interop, REPL driven development, s-expressions, and great support for working with maps seem to be the ones that don't apply to Haskell from my quick glance.

cdmckay 6y ago

The JVM interop is a huge positive for Clojure, in my opinion. Being able to consume any JVM library makes Clojure usable in many more professional settings than Haskell.

fiddlerwoaroof 6y ago
Yeah, I worked at a company where several Haskell projects crashed and burned because of interop issues with existing JVM systems, but the Clojure project I worked on did really well.
johnday 6y ago
Yeah, that makes sense. If the killer app is JVM interop, nothing but JVM based languages should even be on the table. The "why Clojure?" question just becomes "because Clojure is the best language on the JVM," which is not too interesting of a topic IMO. Haskell has decent interop with C/C++ languages, but certainly nobody uses haskell because of that.
- BoiledCabbage 6y ago
  If the killer app is practical usage than Clojure clearly comes out on top. The problem with function language adoption is people keep pushing Haskell likes it's anything more than at its essense a language exploration research project. The fact that you'd have a comment that ignores a language because it wins by default because it practical is more proof that people evaluating languages are speaking two different... well languages. Some are looking for what they feel have the coolest ideas, others are looking for languages with very cool ideas, much better than what they're using today, and can still be effective/ productive in. Haskell is cool if you want to think about or play with ideas. Clojure is cool ideas, and can still be productive in (ie full modern library support). As well if you don't know, F# falls into that same bucked of cool ideas, better than your avg imperative language and can still be very productive due to language and .net library. We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. Otherwise the produvtivity loss from lack of libraries is almost impossible to overcome from any possible produvtivity gains from the language.
  - mumblemumble 6y ago
    > We're trending to a point where any non-systems language is just an exploratory language unless it's build on JVM or .Net. I certainly hope this does not turn out to be the case. Both the JVM and .NET impose a certain type system on all their client languages. Those languages have an option to embrace it, like F# or Kotlin have, or to struggle against it, like Scala has, but they don't have the option to truly pull free of it. Not without shutting out effortless interop with the rest of the platform, and, in doing so, undermining the whole purpose of being on those platforms in the first place. And, since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation.
    - BoiledCabbage 6y ago
      > since most the interesting developments in programming languages center on type systems, that implies that huddling together on the Big Two bytecode VMs stifles a lot of really interesting innovation. Not disagreeing at all. Interop with a library means interop/conformance with its type system. Which means if you want languages with new / innovative type systems, someone will need to build a library system to resolve this. Either an untyped library system as large as the .NET or Java library systems, or a library that has a trivial way to tack on type transformation of some form so that each language that interops with it can minimally add a type translation layer between the two. What that looks like, I'm not certain. But as long as engineers need to be productive, they need a robust modern library system. No new lang will get adopted if the lang author also needs to build up a complete library system, so it must be a general component.
      - mumblemumble 6y ago
        I'm hopeful that Rust will lead in a good direction. A C-style ABI, by virtue of being the least common denominator, is probably the best bet for re-usability across paradigms. Higher level languages would want to write idiomatic façades, but they already habitually do that anyway, even on higher-level platforms like Java and .NET. And I think that deterministic memory management is probably also a pretty important feature. You don't want your libraries all bringing their own clever ideas about object lifetimes and such. But you also need it to be very reliable; a real danger with inviting libraries written in C and C++ into your process space is that they are liable to corrupt your memory. Rust's affine type system seems like a big step in the right direction here. Similar thoughts for the error model. I don't have any particular complaints about exceptions, except that you don't want to be bleeding them on an external API, because that ends up being another spot where languages can fail to mesh. What's missing, though, is that there is no good cross-platform standard for libraries that work with the C ABI (neither in source nor binary form) for other languages to plug into. So that's where I get to thinking that Rust might be closer to (if not exactly at) the mark than C is.
- andrewem 6y ago
  I think there are at least two cases where JVM interoperability is relevant. The first is when a company is already using the JVM and so knows how to deploy and monitor it; in that case, it’s easy to choose because it presumably imposes limited burdens on the company’s operations people. The second case is when you want access to some mature environment, so that all kinds of packages and services are available to support it, but don’t have a commitment to any one in particular yet, and Clojure qualifies because of the JVM; in that case, a non-JVM language like Python, PHP, or Ruby might also work.
- didibus 6y ago
  It's not just killer JVM interop, it's killer all around interop. Clojure relies on interop more than any other major language, the language has inherent syntax around it and even its standard library is designed with it in mind. That makes it very easy to adapt over different runtimes, giving Clojure more reach than most. That's why you have Clojure JVM, Clojure CLR, Clojure Unity, ClojureScript, Clojerl (Clojure on BEAM), etc.
city41 6y ago
ClojureScript is another plus. I'm unsure what Haskell's story is for frontend dev (I have no Haskell experience).
- johnday 6y ago
  The GHC compiles Haskell either directly to assembly or via LLVM. There is a GHCJS project, which works fine, but personally I've not used it. There's not much of a story in terms of frontend Haskell. On the other hand, there are two "child" languages of Haskell for the job: Elm, which is a frontend-focused language, and PureScript, which compiles to JS and is designed for that use case.
- teodorlu 6y ago
  As someone who tried out GHCJS, then Purescript, then Elm, then Clojurescript: - GHCJS and purescript are powerful, but the learning experience might be steep[1] - Elm is an excellent entrypoint into ML programming in the browser. Solid story for new users, and a great standard library for interactive web applications. - ClojureScript differs from Elm in that it embraces its host, with all its power and all its wrinkles. Writing Elm is mostly a smooth experience. Read the guide[2], then you can actually build a web app. I've spent the most time with Elm. Other people might have different experiences. [1]: a few years since I tried, might be better now. [2]: https://guide.elm-lang.org/ https://guide.elm-lang.org/

vnorilo 6y ago

I actually don't want to get into the argument over which is better, but dynamic and static types do change everything, also with regard to how those features in the list feel in a language.

johnday 6y ago
Agreed! Asking which language is "better" is a fool's errand. But talking about specific upsides, especially in comparison with other languages, is a useful reductivist tool in determining how we can improve the story for each language.

teodorlu 6y ago

I really appreciate both Clojure and Haskell. I agree that > nearly all of the claims made about Clojure here can be made about haskell , but I'm not sure about `more strongly´. ## DX with Haskell (and ML friends) I miss in Clojure: - Harder to do sound, up-front design with data types and module interface, where implementation becomes almost trivial after when the type signatures make sense - Consistency checks from compiler / type checker ## DX with Clojure I miss in Elm/Haskell: - REPL ergonomics, where every action I could think of makes sense as a REPL command, leading to very small incremental pieces. - Excellent default data structures with literal representation and serialization (EDN) I'd love to read a point-by-point discussion of the article sections comparing Haskell and Clojure, though that's much to ask for in the comments field.

JackMorgan 6y ago
I've done a non trivial amount of both Haskell and Clojure, and this comment really hits the nail on the head. Each has non-overlapping strengths that I miss when switching. However, I've lately found F# to be my nearly perfect blend of enough things that I regularly use that I mostly just use that or Haskell when I'm messing about with katas.
- teodorlu 6y ago
  As someone who hasn't written any F#, I'm curious about F#'s advantages over Haskell.
  - JackMorgan 6y ago
    I've had bad luck with Haskell's laziness causing hard to debug performance issues. Also the lack of libraries really hurts when it comes to even basics like queue and database interactions. Many times there's a few libraries that are all half finished. Don't get me wrong, I really like Haskell a lot, I just find that F# brings a lot of well-thought out compromise between Haskell and the wealth of libraries in .NET for production code. If it was my money in my startup, I'd have no qualms betting on F# to get me to market as soon as possible. If it was my personal OSS project that I work on for personal edification and enrichment, I'd choose Haskell nearly every time.

fulafel 6y ago

Compared to Haskell, Clojure, like Elixir and Erlang and Scheme, is a much smaller and simpler language and is easier to learn especially for people without a theoretical CS / math background. This is due to Haskell's ambitious and powerful static type system.

mac01021 6y ago
I'm not sure Clojure is _simpler_. I think Haskell may have more regularity and less variety in language constructs. I won't dispute that it is more alien to most programmers, though, and that laziness and monadic IO require a bunch of work to get used to.

didibus 6y ago

Interop, REPL driven development, s-expressions, and great support for working with maps seem to be the ones that don't apply to Haskell from my quick glance.