The Haskell Heap
blog.ezyang.comThanks to _why, I do tend to like comics making programming ideas more clear. I'm not sure how someone who doesn't already know how a Haskell heap works is supposed to get anything out of this, tho. How is "Some presents explode when you open them, others are haunted by ghosts that open other presents when disturbed," going to clear anything up for someone who is lost?
It looks like it's just an introduction to a yet-to-be-written series. Why not wait until the series actually contains some useful information before posting it?
Nice drawings, tho. I'm looking forward to the rest.
This is what make it difficult to understand the performance profile of a Haskell program. Take a look at the book Real World Haskell for a taste of how ugly it can get.
http://book.realworldhaskell.org/read/profiling-and-optimiza...
Luckily Haskell does give you the ! operator (e.g., !x), which tells the compiler to evaluate the variable.
Ok, this seems a bit better than the spacesuit and bananas metaphor, but we'll have to wait for the future posts to see whether it is really better. He does veer into spacesuit bananaisms (e.g. the ghosts and the hand grenades) but maybe he will explain those metaphors better in the future.
P.S. Spacesuit bananaism is a new term I just coined to refer to people that use thoroughly baffling metaphors to explain already confusing Haskell concepts thus managing to make Haskell even more confusing and ending up with gibberish even the most seasoned Haskell pros cannot grasp. It comes from some guy's attempt to explain monads with a metaphor involving spacesuits and bananas.
Out of all the confusing and misleading monad tutorials out there, this one finally made it click for me: http://ertes.de/articles/monads.html. He doesn't use any off-the-wall analogy like spacesuits or ghosts inside of boxes. Instead, he just explains monads for what they essentially are: reified future computations. Once I saw monads for what they are, instead of all the things they are not (e.g. bananas), it all seemed so simple. The fundamental similarities between various monads such as IO and lists, which had previously eluded me, really came into focus.
I wish more tutorial writers would realize that just because someone is a novice doesn't mean a challenging concept must be candy coated or abstracted to the point of near-meaninglessness in order to be palatable. Quite the opposite, in many cases.
I found that what made them click was writing them by hand. Writing a few simple programs using the Maybe, Reader, State and List monads and then implementing them by yourself from first principles clearly demonstrated for me that there was nothing magic at all about how they worked :)
Why can't Haskell tutorials speak plainly? I write code, I read mathematics. Each software concept has a linkage to a mathematical concept. I am not a magician to be gibbered at by strange words only understood by the esoteric initiates.
Then it sounds like you would want to learn about the runtime from this:
Thanks!
It'd be nice if there was something between obscure mutterings and the compiler internal docs though, doncha think? :-)
How about papers? Almost everything has been written up. This is the introduction to the multicore runtime:
http://research.microsoft.com/en-us/um/people/simonpj/papers...