Hacker News Reader

Comment by willvarfar | Hacker News Reader

(not downvoter)

I come to completely the opposite conclusion:

http://williamedwardscoder.tumblr.com/post/18319031919/progr...

There's nothing stopping someone writing a haskell-alike with readable syntax as long as they stay away from trying to create terms like monads to explain things that don't need explaining ;)

View on HN

I don't think that's a fair comparison. Here's a toy trie implementation I've just thrown together in Haskell. It may not be perfect, but I think it's more comparable to your Python.

http://lubutu.com/media/temp/trie.hs

> There's nothing stopping someone writing a haskell-alike with readable syntax as long as they stay away from trying to create terms like monads to explain things that don't need explaining ;)

There's nothing stopping someone from doing that while trying to create such terms, either; witness Haskell. (Or maybe your argument is that the syntax isn't readable? Well, is `>>=` really worse than `?:` in terms of immediate apprehensibility?)

However, I think it's important to recognise that the use of 'monad' is not a case of "creat[ing] terms … to explain things that don't need explaining". A pattern was identified, and it was realised that it fit into the existing mathematical formalism of monads (http://en.wikipedia.org/wiki/Monad_%28category_theory%29).

This can hardly be regarded as a willfully abstruse activity; identifying and naming existing patterns, especially if the name is already out there, is part of a (good) computer programmer's toolkit, right? http://en.wikipedia.org/wiki/Design_Patterns

And python should be embarrassed how exactly?

I never said anything about embarrassment; I was just defending the virtue of using existing names to recognise pre-explored patterns, even if they frighten people.

Monads only need a lengthy explanation if you don't understand that they are a typeclass in Haskell. The monad laws you can take to be principles on which to correctly implement them, but they aren't necessary for their use.

Besides, that whole post just gave me the impression that you haven't done the minimum necessary to understand Haskell programs. You claim that there is no immediate visual grouping of the expressions, yet you seem to gloss over all the pattern-based definitions of functions.

Now, if you find using such lengthy sequences of patterns to define your functions unsavory, you can use case expressions, which... require indentation for their cases.

On most respects, it just comes down to the fact that Haskell is different, and it takes a bit of reading to accustom oneself to it.

edit: It was a tad too defensive before. Sorry 'bout that.

Reply on news.ycombinator.com