3 ms·

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 p

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.
nbouscal 13y ago
I'm confused. In what sense is correctness not pragmatic? Also, have you used lenses yet? Heterogenous hierarchical data in Haskell is quite easy now.
- tel 13y ago
  It was pretty easy before with generic traversals as well. I think people give Haskell a bad rap for handling heterogenous data, but it's actually quite good at it. You just feel the pain of a poorly specific data domain more sharply and tend to want to reify it into something nicer quickly. No such option exists in Clojure unless you use Typed—and I say this as someone quite familiar with both languages.
- wes-exp 13y ago
  Guaranteed correctness has a cost in the form of extra specification needed to get things done. For example, many type errors are essentially noise: they do not catch real bugs, and they create needless busy-work for the programmer to correct them. example: function stringify(FooObj object): return object.toString() Now suppose we do some refactoring somewhere, and we want to call stringify not with a FooObj but with a BarObj. Since we have defined stringify as taking a FooObj, the compiler whines until we update the definition. However, depending on your philosophy, this error is nothing more than noise, because stringify would work fine on a BarObj. Pragmatists may wish to forgo such safety in favor of greater flexibility: function stringify(object): return object.toString() This is the essence of liberal programming: an emphasis on flexibility and minimal specification, at the cost of reduced safety guarantees.
  - nbouscal 13y ago
    That example is a straw man. First, all reasonably strong type systems support polymorphism well enough to handle that case trivially. Second, type inference is a thing, so a lot of code in strongly-typed languages even looks the same as your second code example. I'm not saying you can't come up with a fair example to support your argument. I will say, though, that it's going to be a lot harder to do so, and that such examples only rarely come up in practice. The argument for flexibility at the cost of guarantees of correctness used to be a good one, but it has weakened significantly with time, and before long will cease to be valid at all.
    - wes-exp 13y ago
      Terms like "straw man" imply that I'm trying to debate, but I'm not. You asked how correctness could be contrary to pragmatism, and I tried to provide an example.
      - nbouscal 13y ago
        Whether or not it's a debate has nothing to do with whether or not your example is valid. I was just pointing out that it isn't.
        wes-exp 13y ago
        Out of curiosity, how would you define my example stringify function in Haskell with "no cost" safety around the argument type?
        Tuna-Fish 13y ago
        The typeclass that provides "toString" in haskell is "Show". It defines a few functions, of which the important one is "show", which takes the original type and returns a string. A function that is equivalent to the java-ish example is: stringify s = show s No type definition is necessary, because the compiler can correctly infer the correct, most generic type: stringify :: (Show s) => s -> String Or, for any s in type class Show, a function that makes s into a String. Note that dispatch is done statically. Modern type systems eliminate most of the cost of type safety through good generics and type inference. Mainstream statically typed languages are just 20-30 years behind the state of the art. (note that the example actually can be reduced to: stringify = show)

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.

nbouscal 13y ago

I'm confused. In what sense is correctness not pragmatic? Also, have you used lenses yet? Heterogenous hierarchical data in Haskell is quite easy now.

tel 13y ago
It was pretty easy before with generic traversals as well. I think people give Haskell a bad rap for handling heterogenous data, but it's actually quite good at it. You just feel the pain of a poorly specific data domain more sharply and tend to want to reify it into something nicer quickly. No such option exists in Clojure unless you use Typed—and I say this as someone quite familiar with both languages.
wes-exp 13y ago
Guaranteed correctness has a cost in the form of extra specification needed to get things done. For example, many type errors are essentially noise: they do not catch real bugs, and they create needless busy-work for the programmer to correct them. example: function stringify(FooObj object): return object.toString() Now suppose we do some refactoring somewhere, and we want to call stringify not with a FooObj but with a BarObj. Since we have defined stringify as taking a FooObj, the compiler whines until we update the definition. However, depending on your philosophy, this error is nothing more than noise, because stringify would work fine on a BarObj. Pragmatists may wish to forgo such safety in favor of greater flexibility: function stringify(object): return object.toString() This is the essence of liberal programming: an emphasis on flexibility and minimal specification, at the cost of reduced safety guarantees.
- nbouscal 13y ago
  That example is a straw man. First, all reasonably strong type systems support polymorphism well enough to handle that case trivially. Second, type inference is a thing, so a lot of code in strongly-typed languages even looks the same as your second code example. I'm not saying you can't come up with a fair example to support your argument. I will say, though, that it's going to be a lot harder to do so, and that such examples only rarely come up in practice. The argument for flexibility at the cost of guarantees of correctness used to be a good one, but it has weakened significantly with time, and before long will cease to be valid at all.
  - wes-exp 13y ago
    Terms like "straw man" imply that I'm trying to debate, but I'm not. You asked how correctness could be contrary to pragmatism, and I tried to provide an example.
    - nbouscal 13y ago
      Whether or not it's a debate has nothing to do with whether or not your example is valid. I was just pointing out that it isn't.
      - wes-exp 13y ago
        Out of curiosity, how would you define my example stringify function in Haskell with "no cost" safety around the argument type?
        Tuna-Fish 13y ago
        The typeclass that provides "toString" in haskell is "Show". It defines a few functions, of which the important one is "show", which takes the original type and returns a string. A function that is equivalent to the java-ish example is: stringify s = show s No type definition is necessary, because the compiler can correctly infer the correct, most generic type: stringify :: (Show s) => s -> String Or, for any s in type class Show, a function that makes s into a String. Note that dispatch is done statically. Modern type systems eliminate most of the cost of type safety through good generics and type inference. Mainstream statically typed languages are just 20-30 years behind the state of the art. (note that the example actually can be reduced to: stringify = show)