Hacker News Reader

Comment by pdpi | Hacker News Reader

You're probably going to have a bad time trying to do it like that. Perl/Python/Ruby are brilliant at what they do, and the problems they're best at aren't necessarily problems that Haskell is very good at.

If you're interested in learning the language, I suggest starting with Learn You a Haskell For Great Good[1] (first programming book I've ever considered to be a page-turner), then following it up with Real World Haskell[2] (going through that one now myself)

[1] http://learnyouahaskell.com/

[2] http://book.realworldhaskell.org/read/

View on HN

To expand on this, Haskell is excellent to make your own parser. Take special note of say Chapter 16 Parsec of Real World Haskell[1]. This is the sort of application where you would choose Haskell over Perl/Python/Ruby.

Of course parsing is something thats very important if you are making your own DSL. And this is another application where Haskell really shines. This is why the guys who do programming language research produce papers with code in Haskell. Its orders of magnitude easier to make your toy language for exploring evaluation order in Haskell than it is to do the same in Java.

Its easier to learn a language if you're building something you're interested in though. Personally, I learnt a lot of Haskell implementing a web app with Yesod[2].

Good luck.

[1] http://book.realworldhaskell.org/read/using-parsec.html [2] http://www.yesodweb.com/

I feel like I see a lot more cases where the research language is built as an extension of Haskell or its syntax tree is written up as a (G)ADT possibly with the derived `read' as the "parser" (but possibly just constructing and interpreting ASTs within a Haskell program).

I don't really agree.

Python, at least, has the PLY library, which makes parsing (IMO) easier than with Parsec.

Other languages, like OCaml, also make writing parsers very easy.

Haskell with Parsec might beat C with lex/yacc, but I don't think it's that great compared to what else is available.

After using PLY in production and (afterwards) toying with Parsec for a side project, I could never go back to PLY. Even aside from PLY's obvious flaws (docstrings as code, mutation instead of returns, ample use of python magic backstage...), Parsec wins by being more configurabile and composable.

Whoever is maintaining my PLY mess now might get a handle on it faster than they could learn Haskell, but probably not by much.

Could you elaborate why you feel this way? I could also just vote for one or the other, but I'd like to see discussion about the relative merits of PLY or Camlp4 w.r.t. Parsec.

I can't deny part of the reason is that I'm simply more comfortable with Python.

I think my main contention was the "orders of magnitude" claim in the comment I replied to. Parsec is nice, but it's not "orders of magnitude" better than PLY or camlp4 or other parsing tools in other languages.

Haskell also has Attoparsec, a simpler faster alternative to Parsec

>Of course parsing is something thats very important if you are making your own DSL.

Writing a DSL was my original motivation for learning Haskell beyond it being just a toy. About a day after I really got going on my parser I decided to abandon the idea of a DSL and just write it as a monad.

"This is why the guys who do programming language research produce papers with code in Haskell."

Structural pattern matching is also a nice thing to have when writing interpreters.

Reply on news.ycombinator.com