Haskell vs Clojure syntax(honza.ca)
honza.ca
Haskell vs Clojure syntax
http://honza.ca/2013/02/haskell-vs-clojure-syntax
18 comments
It would have been more compelling if the author exhibited two code snippets that do the same thing.
In the Clojure example, he adds two numbers together, defines a function that modifies a string by prepending "Hello " and defines a constant.
In the Haskell example he overloads the `pure` and <*> functions to work on the 'Maybe' type, allowing arbitrary functions to be lifted into 'Maybe' to allow automatic propagation of failure.
In the Clojure example, he adds two numbers together, defines a function that modifies a string by prepending "Hello " and defines a constant.
In the Haskell example he overloads the `pure` and <*> functions to work on the 'Maybe' type, allowing arbitrary functions to be lifted into 'Maybe' to allow automatic propagation of failure.
I know some Clojure and barely any Haskell at all. I opened up "Learn you a Haskell" and copied and pasted a few code samples that appeared to have strange syntax. The idea of the post was to show the difference in the amounts of syntax in the two languages.
You know 'some' of language A and 'barely any' of language B, and you thought it would be a good idea to write a blog post comparing them and post it to HN?
[deleted]
This has to be the shallowest possible analysis you could have given this issue. No explanation of the tradeoffs or exploration of why they took the routes they did. Just, "Haskell has, like, syntax man. Syntax is hard."
Additionally, the explanation of Clojure syntax is woefully incomplete — going by this article, {:age 1} and #inst "@2012-02-12T01:02:03.456" aren't valid Clojure. In reality, Clojure is very syntax-heavy for a Lisp, and most Lisps still have more complicated syntax than the simplistic "Things go between parentheses, the first of which is evaluated as a function and the rest of which are arguments" — look at just about any macro definition in any Lisp to see a fair bit of syntax beyond parentheses.
Additionally, the explanation of Clojure syntax is woefully incomplete — going by this article, {:age 1} and #inst "@2012-02-12T01:02:03.456" aren't valid Clojure. In reality, Clojure is very syntax-heavy for a Lisp, and most Lisps still have more complicated syntax than the simplistic "Things go between parentheses, the first of which is evaluated as a function and the rest of which are arguments" — look at just about any macro definition in any Lisp to see a fair bit of syntax beyond parentheses.
This has to be the shallowest possible analysis you could have given this issue
Not disagreeing here. Moreover I'm not really sure comparing these two on syntax makes a lot of sense: comparing an homoiconic language with a non-homoiconic one from the syntax point of view is weird. Then the main difference between these two languages is related to typing IMHO.
If you want the benefits of homoiconicity in Haskell, there's a Liskell project (not sure how good it is yet but it certainly is interesting).
Not disagreeing here. Moreover I'm not really sure comparing these two on syntax makes a lot of sense: comparing an homoiconic language with a non-homoiconic one from the syntax point of view is weird. Then the main difference between these two languages is related to typing IMHO.
If you want the benefits of homoiconicity in Haskell, there's a Liskell project (not sure how good it is yet but it certainly is interesting).
That's hardly a fair comparison, the equivalent Haskell to the Clojure example is fairly similar, though my Haskell is a bit rusty at this point.
sum = 1 + 2
greet name = "Hello " ++ name
usercount = 34
What a terrible post. Those two snippets aren't even slightly related. It's like the author is comparing a basic "Hello World" in C to some entry from the obfuscated C competition.
Clojure has [] and {} and #{} and '() and #() and : and ^ and @ and Foo. and .foo and ->, ... you still have to learn them to understand Clojure code.
I don't understand why such sophomoric drivel gets posted so often to hacker news.
With Haskell you get to learn the crazy syntax of the standard. With Clojure you get to learn the crazy syntax of whatever program you're looking at.
Not really. The culture with Clojure is that macros have reasonably long, descriptive English names. You don't have to go digging in the documentation or source to figure out what a macro does. Haskell, meanwhile, inherits mathematical culture and abuses operator overloading to the point where you can't figure out anything code is doing without looking at the source.
I'd argue that being able to define custom operators is far, far, worse for readability than being able to define custom syntax that's invoked by an English-language macro.
I'd argue that being able to define custom operators is far, far, worse for readability than being able to define custom syntax that's invoked by an English-language macro.
Well it was sort of a lisp macro joke. ;)
It's more like with Clojure you're learning the "crazy" Lisp syntax. Sure Clojure has some specifities like #(...) and the -> macro but it's mostly the minimal Lisp syntax.
Learning Clojure has helped me learn elisp too (no more #{} and {} in elisp but the syntax is quite similar).
The one thing I noticed after learning Clojure is that suddenly it became very easy to learn all these Common Lisp and elisp blog posts containing code.
Learning Clojure has helped me learn elisp too (no more #{} and {} in elisp but the syntax is quite similar).
The one thing I noticed after learning Clojure is that suddenly it became very easy to learn all these Common Lisp and elisp blog posts containing code.
What? Haskell barely has any syntax as well. Slightly more than lisps, but nowhere near to C family languages.
I would have written "Just 16."
> Nothing >>= \x -> return (x * 10)
I would have written "Nothing." Actually, that about sums it up.
Edit: just to expand on the above with some commentary, his examples are all basically as if he saw a salad in a bag, decided he wanted a salad, and proceeded to buy all the ingredients from separate bags, stick them in one big bag, open them all from inside the other bag and mix them together. In practice, you just don't need to do things this way.
The first example is treating Maybe as an applicative functor. In practice, when someone does this, they don't use a bare operator like ( * ). Suppose I want to read in an integer from the user. Which is easier to understand?
or
This is the usual way <$> is used, not his way. You could even get some mileage out of using monads with the do notation, by doing something more like:
Same with the next example:
but there's no intrinsic reason to instead write that as he did.
Similarly, his second example reads much better when you consider the do notation:
In fact, even using the syntax he proposes on the other line produces a more readable example:
If you don't understand what's going on with his second example, you should brush up on monads. You don't need to understand applicative functors to get things done, but they do make life better when used in moderation.