8 ms·

I've thought about learning Clojure but already knowing Haskell I feel that in comparison I wouldn't gain much and then loose some.

nnq 13y ago
"loosing some" is the whole point :) That's the beauty of lisps, they make "the simplest possible way of doing something" just pop out, and once you see it, you just have to do it this way! You then show the middle finger to both 'powerful type systemy abstractions' and forget you ever learned them, and then the other middle finger to 'powerfully optimized down to metal programming', and you go hunting for real world problems that you can solve using 'the simplest possible ways' thinking ...until you realize that using simple and elegant tools, you ended up building a ...type system :) (http://typedclojure.org/ http://typedclojure.org/)
- Ygg2 13y ago
  Every sufficiently advanced Lisp implementation contains an ad-hoc, badly-specified, bug-ridden implementation of half of Haskell's type system.
  - nix1 13y ago
    This one has a dissertation[1] behind it. Though unread (yet), I think it's well specified. [1]: https://github.com/downloads/frenchy64/papers/ambrose-honours.pdf https://github.com/downloads/frenchy64/papers/ambrose-honour...
  - levosmetalo 13y ago
    Until you encounter a real Lisp implementation that contains an actual thorough, well specified and bug free implementation of type system more powerful than the one Haskel has. Interested? Then take a look at the Shen[1] and enjoy having both the benefit of types and other powerful Lisp constructs in one language. [1] http://shenlanguage.org/ http://shenlanguage.org/
    - 616c 13y ago
      Is anyone using Shen yet? The only problem, and I am a passive lurker in circles in HN, Reddit, and elsewhere it has been mentioned, is an Ocamlesque license policy. People have said this will get them nowhere. It is understood they, from the outside view, want a single language implementation, not just a standard. But everyone I see says they will not touch it with a ten foot pole for this reason. Also ironically, this real implementation of Lisp necessitates being built on "lesser" or not "real lisps" for us commoners, like SBCL and CLisp. It also has hosts on Ruby, Python, and this even lesser lisp called "Scheme" (rest assured, this is a joke and not a troll). http://shenlanguage.org/Download/download.html http://shenlanguage.org/Download/download.html That being said I find it very interesting. Its licensing, even just the word if you read through, sounds very aggressive and weird. Has anyone here used Shen yet?
      - hga 13y ago
        Indeed, the license is impossible. In addition to what you point out, it attempts to say the same thing as many as 5 times, introducing unacceptable ambiguity. The final straws for me is that it is the creator's explicit intent that no incomplete or incorrect implementations be publicly accessible (he among other things thinks there's enough already...), and that the author broke a promise to the community, demonstrating that his word is no good.
      - levosmetalo 13y ago
        Yes, it's a pity it has such a license. People tend to dismiss it without even looking at it because of the license. I don't think the language will take off unless it change licensing before it's too late, but I still find it enjoyable to use with some smallish projects. I hope that Shen will get a successor that will make it more suitable for modern world while keeping ideas that make it unique and sound in the first place and smoothing the rough edges.
      - mordocai 13y ago
        I am confused about all these licensing "problems" everyone is talking about here. Could you enlighten me? Sure, Ocaml and shen have "weird" licenses but I just read through them in the last few minutes and see no major issues. The licenses for both only effect the code for the language interpreter/compiler and associated libraries itself and should have little to no effect on your own code. If you use MIT/BSD licenses then you are almost certainly fine, with GPL there are some potential issues but most people think that dynamic linking doesn't count as "linking" in the lawyer sense and, therefore, using GPL code with something like Shen would be fine. This hasn't been tested in the courts AFAIK.
  - zem 13y ago
    as ashley yakeley once noted, every sufficiently well-documented lisp program contains an ml program in its comments.
brentshields 13y ago
As someone who knew Haskell first and then learned Clojure, I can tell you that this assumption is incorrect. It's so completely philosophically opposite from Haskell in so many ways that it's a very good mental exercise to really grok them both. It will make you appreciate how much you're paying for that fantastic type system. Understanding this cost will allow you to make better decisions in the future about which technologies are a better fit for a given project.
- TuringTest 13y ago
  Sir, your comment is intriguing and I want to hear more about it. What is this philosophically opposite that you mention? Haskell is good at creating domain-specific languages, so I think the differences must be around the superior meta-programming facilities in lisp languages. So, what would you do with Clojure that you couldn't do in Haskell easily?
  - brentshields 13y ago
    It's an oversimplification, but the basic philosophical difference from my point of view is that Haskell values correctness above all and Clojure is above all pragmatic. I think all of these major differences in the languages are reflections of this: - static vs. dynamic typing - pure vs. allowing side effects - native vs. hosted - focus on syntax vs. rejection of syntax Depending on the problem, you may get big benefits out of one side or the other. One particular thing that is much easier in Clojure is dealing with heterogeneous, hierarchical data. This is just so effortless because of the combination of dynamic typing and the wonderful built-in persistent data structures. This is possible but takes a lot more work to do in Haskell and is much slower to iterate on when your data changes.
    - wes-exp 13y ago
      This comment is spot-on. According to the Yegge programming axis, Haskell is extremist conservative (emphasizes safety above all) and Clojure is some notches down into a more moderate zone (merely "conservative") that balances safety against pragmatism.
zimpenfish 13y ago
Always learn another language. It opens up new mental pathways and can help you appreciate the ones you already know in surprising ways.
djpowell 13y ago
Clojure programming might be more data-oriented than Haskell programming. I've never done any real-world Haskell programming, but I'd guess it'ld have a completely different feel. The dynamic-typing means Clojure code is usually built around data-flows of maps/vectors/strings (generic information types that are trivial to integrate from different sources), trivial serialization, code-as-data. I'd guess Haskell code is more likely to be built around abstractions based on the more powerful type system. clojure.core.logic - a Prolog-like logic language that you can embed in the middle of a Clojure function - is a good example of something that is possible thanks to Clojure's lisp macros.
- lelf 13y ago
  > clojure.core.logic - a Prolog-like logic language that you can embed in the middle of a Clojure function - is a good example of something that is possible thanks to Clojure's lisp macros. import Control.Monad.Logic And! You don't macros for that. Macros are not used much in Haskell (only for very special cases), there's no need for them.
  - Skinney 13y ago
    core.logic doesn't really use macros does it? Maybe to simplify the syntax, but macros is in no way required to build a core.logic library, at least not in the same way as core.async requires it. The real beauty of macros is to simplify syntax without taking a runtime performance hit. How would you implement thread-first or thread-last in Haskell without a runtime performance hit? Template Haskell?
  - danidiaz 13y ago
    While useful, Control.Monad.Logic is not really an alternative to core.logic. It is a search monad more than anything, and it doesn't perform any unification or constraint propagation. The type system gets a bit in the way when implementing something like miniKanren in Haskell. I suspect Clojure is a better fit for this kind of highly dynamic problem.
- tel 13y ago
  Is say that the things you describe as Clojure's strengths occupy one part of Haskell's wheelhouse. The not change is that the flows orient over highly composed custom and built-in ADTs, but they're honestly hardly more painful than maps/vectors/strings while buying a lot of robustness. And if you don't like that, it's easy to use "untyped" types as well.
lelf 13y ago
Well, there is no such simple interoperability with java from haskell, that's for sure. But otherwise… user> (:key nil) nil Mmmm, I'm not certain I particularly want this user> (nil :key) CompilerException java.lang.IllegalArgumentException: Can't call nil RUN!
- _halgari 13y ago
  As many are saying it's a pragmatic choice. And it allows you to do stuff like this: (:foo (:bar {})) Without throwing a NPE. Which is what I want 99.9% of the time. As someone who codes in Clojure close to 10 hours a day, I rarely see a problem like you describe.
- Tuna-Fish 13y ago
  If you use clojure.typed, I think the second example would give you a compile-time type error.
  - tobik 13y ago
    While true, the second example already gives you a compile-time error in normal Clojure (note the CompilerException). It never compiled and was never evaluated. This on the other hand compiles and is likely what the OP wanted to show: user> (let [e nil] (e :key)) NullPointerException
kencausey 13y ago
One of the at least occasionally useful strengths of Clojure over Haskell is the pragmatic choice Rich Hickey made by building on top of Java. This has continued with Clojurescript (Javascript) and others like Clojure on CLI, objc, etc. What this means to me is that on the occasions when I'm faced with a task like having to produce a Microsoft Excel file readable by an array of Excel versions I can leverage the wide range of libraries available in the parent environment (Apache POI, http://poi.apache.org/ http://poi.apache.org/). The attention paid to the facilities to interoperate with the underlying ecosystem means that even given the relatively short history of Clojure it is likely that someone has already done at least some of the work to make it pleasant to use in Clojure (https://clojars.org/org.clojars.boechat107/cloxls https://clojars.org/org.clojars.boechat107/cloxls).
Nekorosu 13y ago
I envy you 'cause I'm too stupid to use Haskell. I'd suggest you stay with it if it already lets you do things. And I'm staying with Clojure 'cause it works for me.

nnq 13y ago

"loosing some" is the whole point :) That's the beauty of lisps, they make "the simplest possible way of doing something" just pop out, and once you see it, you just have to do it this way! You then show the middle finger to both 'powerful type systemy abstractions' and forget you ever learned them, and then the other middle finger to 'powerfully optimized down to metal programming', and you go hunting for real world problems that you can solve using 'the simplest possible ways' thinking ...until you realize that using simple and elegant tools, you ended up building a ...type system :) (http://typedclojure.org/ http://typedclojure.org/)

Ygg2 13y ago
Every sufficiently advanced Lisp implementation contains an ad-hoc, badly-specified, bug-ridden implementation of half of Haskell's type system.
- nix1 13y ago
  This one has a dissertation[1] behind it. Though unread (yet), I think it's well specified. [1]: https://github.com/downloads/frenchy64/papers/ambrose-honours.pdf https://github.com/downloads/frenchy64/papers/ambrose-honour...
- levosmetalo 13y ago
  Until you encounter a real Lisp implementation that contains an actual thorough, well specified and bug free implementation of type system more powerful than the one Haskel has. Interested? Then take a look at the Shen[1] and enjoy having both the benefit of types and other powerful Lisp constructs in one language. [1] http://shenlanguage.org/ http://shenlanguage.org/
  - 616c 13y ago
    Is anyone using Shen yet? The only problem, and I am a passive lurker in circles in HN, Reddit, and elsewhere it has been mentioned, is an Ocamlesque license policy. People have said this will get them nowhere. It is understood they, from the outside view, want a single language implementation, not just a standard. But everyone I see says they will not touch it with a ten foot pole for this reason. Also ironically, this real implementation of Lisp necessitates being built on "lesser" or not "real lisps" for us commoners, like SBCL and CLisp. It also has hosts on Ruby, Python, and this even lesser lisp called "Scheme" (rest assured, this is a joke and not a troll). http://shenlanguage.org/Download/download.html http://shenlanguage.org/Download/download.html That being said I find it very interesting. Its licensing, even just the word if you read through, sounds very aggressive and weird. Has anyone here used Shen yet?
    - hga 13y ago
      Indeed, the license is impossible. In addition to what you point out, it attempts to say the same thing as many as 5 times, introducing unacceptable ambiguity. The final straws for me is that it is the creator's explicit intent that no incomplete or incorrect implementations be publicly accessible (he among other things thinks there's enough already...), and that the author broke a promise to the community, demonstrating that his word is no good.
    - levosmetalo 13y ago
      Yes, it's a pity it has such a license. People tend to dismiss it without even looking at it because of the license. I don't think the language will take off unless it change licensing before it's too late, but I still find it enjoyable to use with some smallish projects. I hope that Shen will get a successor that will make it more suitable for modern world while keeping ideas that make it unique and sound in the first place and smoothing the rough edges.
    - mordocai 13y ago
      I am confused about all these licensing "problems" everyone is talking about here. Could you enlighten me? Sure, Ocaml and shen have "weird" licenses but I just read through them in the last few minutes and see no major issues. The licenses for both only effect the code for the language interpreter/compiler and associated libraries itself and should have little to no effect on your own code. If you use MIT/BSD licenses then you are almost certainly fine, with GPL there are some potential issues but most people think that dynamic linking doesn't count as "linking" in the lawyer sense and, therefore, using GPL code with something like Shen would be fine. This hasn't been tested in the courts AFAIK.
- zem 13y ago
  as ashley yakeley once noted, every sufficiently well-documented lisp program contains an ml program in its comments.

brentshields 13y ago

As someone who knew Haskell first and then learned Clojure, I can tell you that this assumption is incorrect. It's so completely philosophically opposite from Haskell in so many ways that it's a very good mental exercise to really grok them both. It will make you appreciate how much you're paying for that fantastic type system. Understanding this cost will allow you to make better decisions in the future about which technologies are a better fit for a given project.

TuringTest 13y ago
Sir, your comment is intriguing and I want to hear more about it. What is this philosophically opposite that you mention? Haskell is good at creating domain-specific languages, so I think the differences must be around the superior meta-programming facilities in lisp languages. So, what would you do with Clojure that you couldn't do in Haskell easily?
- brentshields 13y ago
  It's an oversimplification, but the basic philosophical difference from my point of view is that Haskell values correctness above all and Clojure is above all pragmatic. I think all of these major differences in the languages are reflections of this: - static vs. dynamic typing - pure vs. allowing side effects - native vs. hosted - focus on syntax vs. rejection of syntax Depending on the problem, you may get big benefits out of one side or the other. One particular thing that is much easier in Clojure is dealing with heterogeneous, hierarchical data. This is just so effortless because of the combination of dynamic typing and the wonderful built-in persistent data structures. This is possible but takes a lot more work to do in Haskell and is much slower to iterate on when your data changes.
  - wes-exp 13y ago
    This comment is spot-on. According to the Yegge programming axis, Haskell is extremist conservative (emphasizes safety above all) and Clojure is some notches down into a more moderate zone (merely "conservative") that balances safety against pragmatism.

zimpenfish 13y ago

Always learn another language. It opens up new mental pathways and can help you appreciate the ones you already know in surprising ways.

djpowell 13y ago

Clojure programming might be more data-oriented than Haskell programming. I've never done any real-world Haskell programming, but I'd guess it'ld have a completely different feel. The dynamic-typing means Clojure code is usually built around data-flows of maps/vectors/strings (generic information types that are trivial to integrate from different sources), trivial serialization, code-as-data. I'd guess Haskell code is more likely to be built around abstractions based on the more powerful type system. clojure.core.logic - a Prolog-like logic language that you can embed in the middle of a Clojure function - is a good example of something that is possible thanks to Clojure's lisp macros.

lelf 13y ago
> clojure.core.logic - a Prolog-like logic language that you can embed in the middle of a Clojure function - is a good example of something that is possible thanks to Clojure's lisp macros. import Control.Monad.Logic And! You don't macros for that. Macros are not used much in Haskell (only for very special cases), there's no need for them.
- Skinney 13y ago
  core.logic doesn't really use macros does it? Maybe to simplify the syntax, but macros is in no way required to build a core.logic library, at least not in the same way as core.async requires it. The real beauty of macros is to simplify syntax without taking a runtime performance hit. How would you implement thread-first or thread-last in Haskell without a runtime performance hit? Template Haskell?
- danidiaz 13y ago
  While useful, Control.Monad.Logic is not really an alternative to core.logic. It is a search monad more than anything, and it doesn't perform any unification or constraint propagation. The type system gets a bit in the way when implementing something like miniKanren in Haskell. I suspect Clojure is a better fit for this kind of highly dynamic problem.
tel 13y ago
Is say that the things you describe as Clojure's strengths occupy one part of Haskell's wheelhouse. The not change is that the flows orient over highly composed custom and built-in ADTs, but they're honestly hardly more painful than maps/vectors/strings while buying a lot of robustness. And if you don't like that, it's easy to use "untyped" types as well.

lelf 13y ago

Well, there is no such simple interoperability with java from haskell, that's for sure. But otherwise… user> (:key nil) nil Mmmm, I'm not certain I particularly want this user> (nil :key) CompilerException java.lang.IllegalArgumentException: Can't call nil RUN!

_halgari 13y ago
As many are saying it's a pragmatic choice. And it allows you to do stuff like this: (:foo (:bar {})) Without throwing a NPE. Which is what I want 99.9% of the time. As someone who codes in Clojure close to 10 hours a day, I rarely see a problem like you describe.
Tuna-Fish 13y ago
If you use clojure.typed, I think the second example would give you a compile-time type error.
- tobik 13y ago
  While true, the second example already gives you a compile-time error in normal Clojure (note the CompilerException). It never compiled and was never evaluated. This on the other hand compiles and is likely what the OP wanted to show: user> (let [e nil] (e :key)) NullPointerException

kencausey 13y ago

One of the at least occasionally useful strengths of Clojure over Haskell is the pragmatic choice Rich Hickey made by building on top of Java. This has continued with Clojurescript (Javascript) and others like Clojure on CLI, objc, etc. What this means to me is that on the occasions when I'm faced with a task like having to produce a Microsoft Excel file readable by an array of Excel versions I can leverage the wide range of libraries available in the parent environment (Apache POI, http://poi.apache.org/ http://poi.apache.org/). The attention paid to the facilities to interoperate with the underlying ecosystem means that even given the relatively short history of Clojure it is likely that someone has already done at least some of the work to make it pleasant to use in Clojure (https://clojars.org/org.clojars.boechat107/cloxls https://clojars.org/org.clojars.boechat107/cloxls).

Nekorosu 13y ago

I envy you 'cause I'm too stupid to use Haskell. I'd suggest you stay with it if it already lets you do things. And I'm staying with Clojure 'cause it works for me.