Hacker News Reader

Comment by awda | Hacker News Reader

Why Haskell?

Ah, my favorite question.

We previously had a custom DSL and it outgrew it's DSL-ness. The DSL was really good at one thing (implicit concurrency and scheduling io), and bad at everything else (cpu, memory, debugging, tooling). The predecessor was wildly successful and created new problems. Once all those secondary concerns became first order, we didn't want to start building all this ecosystem stuff for our homemade DSL. We needed to go from DSL to, ya know, an L. So the question is which...

If you understand the central idea of Haxl, I don't know of any other language that would let you do what Haxl in Haskell does. The built in language support for building DSLs (hijacking the operators including applicative/monadic operations) -really- shines in this case. I would -love- to see haxl-like implicit concurrency in other languages that feel as natural and concise. Consider that a challenge. I thought about trying to do it in C++ for edification/pedagogical purposes but it's an absolutely brutal mess of templates and hackery. There may be a better way, though.

How about Scala?

Anybody that's made a serious go of FP in Scala (applicative, monad, etc) has found that it's not worth the hassle. It fights you the whole way.

Scalaz?

I hang out with the Scalazzi and authors of FP in Scala on IRC. Most of them, including the original creator, would rather write Haskell and some are doing just that.

I think Scalaz is a pathway to Haskell. When people start loving Scalaz, they just happen to migrate to Haskell.

You would only choose Scala over Haskell if the pros (having the java library and running under the jvm) outweigh the cons (having the java library and running under the jvm) :-)

I would choose OCaml, but you made a good point. 10 internets for you, sir.

Did you have a problem with namespace collisions of identical field names in records? Is that much of a problem in Haskell? How did you deal with them? Thanks.

To be completely honest, the namespace/module situation with Haskell could certainly be a _ton_ better, but after 8 years of it I can't ever remember a time when it was ever at the top of my mind as game-breaking. Occasionally quite annoying? Yes, most definitely. But I'd say there are more many more annoying things day to day, and in any case, it is certainly a tradeoff I'll put up with for the returns.

That said, GHC 7.10 will ship with a new extension called `OverloadedRecordFields` that will allow you to have identical record field names for different datatypes. Yay!

Thanks! If it's not a pain in regular Haskell work then I'm relieved. Perhaps other data types are more prevalent in Haskell than records?

I find records are used most heavily in web development, where you are pretty much just shuffling data from browsers to databases and the other way around. But even there the field name thing doesn't pose much of a problem, I prefer defining my records in the module that handles the functions for it, so there's no issue with conflicting names anyways. I found the fact that 'id' is a standard library function to be a bigger minor annoyance.

I agree with the parent that it is a pain, but not very much of one. My pains in lacking other features when I move away from Haskell are far greater than my pains in name collision in Haskell.

I only skimmed the tutorial, but in Scala/Finagle:

  val (friendsX, friendsY) = (friendsOf(x), friendsOf(y))
  for {
    fx <- friendsX
    fy <- friendsY
  } yield (fx intersect fy).size

really liking the look of this, thanks for open-sourcing!

As I understand this, this is an easy but still explicit concurrency construction, which is not what haxl does. It's easy to imagine how something like the toy example of friend-list-intersection could be converted to explicit concurrency in languages with good concurrency support. This is an easy optimization to make by hand in the cases where concurrency is obvious at some layer or within some abstraction. The power of haxl comes when the two (or whatever) requests come from wildly different places in the AST. For example, if you combine the result of friend-list-intersection with some other numeric quantity that's the result of some other fetches. Haxl essentially performs this optimization automatically, over the entire program.

Something like...

    renderPage :: Haxl Html
    renderPage = renderHeader + renderBody + renderRightPane + renderFooter

This will travel as far as possible through all paths in the AST collecting all IO to be performed in the first round (which, once fetched, will unblock more of the AST, and the process repeats until we have an answer).

Reply on news.ycombinator.com