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?
x <- getLine >>= return . read
or
x <- read <$> getLine
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:
x <- getLine
return $ read x
Same with the next example:
x <- Just 2
y <- Just 8
return $ x * y
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:
x <- Nothing
return $ x * 10
In fact, even using the syntax he proposes on the other line produces a more readable example:
Nothing >>= return . (*10)
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.
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.
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.
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.
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).
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.
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.
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.
[+] [-] fusiongyro|13 years ago|reply
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.[+] [-] crntaylor|13 years ago|reply
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.
[+] [-] mrhonza|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] chc|13 years ago|reply
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.
[+] [-] martinced|13 years ago|reply
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).
[+] [-] sitharus|13 years ago|reply
[+] [-] thirsteh|13 years ago|reply
[+] [-] Mr_T_|13 years ago|reply
[+] [-] rmangi|13 years ago|reply
[+] [-] rossjudson|13 years ago|reply
[+] [-] rayiner|13 years ago|reply
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.
[+] [-] martinced|13 years ago|reply
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.
[+] [-] martinced|13 years ago|reply
[deleted]
[+] [-] martinced|13 years ago|reply
[deleted]
[+] [-] lucian1900|13 years ago|reply