[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
jo at durchholz.org
Sun Dec 24 14:49:41 EST 2006
Neil Mitchell schrieb:
>> (There's still no good introduction to Monads, for example. One that's
>> understandable for a programmer who knows his Dijkstra well but no
>> category theory. And a few other things.)
> I grasped this one first time round:
That one escaped me.
> And Haskell let's you serialise thunks just fine (use Yhc),
Yhc explicitly say "not production-ready" on the main page.
I hope to return to it when that notice is gone.
> but really
> if thats what you want to do, I think you are going to suffer a lot in
> the long run... I have written client/server app's before, the whole
> point is you want to decide what computation gets performed on which
> side, not leave it up to the vagaries of lazy evaluation to come up
> with a random solution.
I'll indeed want to keep quite a strict tab on what gets computed where.
However, I can foresee the time when I explicitly want a thunk passed
around. And I need it now already for making snapshots of the
simulation's state, which will most likely contain thunks (e.g. I like
to work in infinite game universes, where the data "springs into
existence" at the time when it's being looked at; with lazy evaluation,
I could express that in a straightforward fashion as an infinite map
from coordinates to game data, and without it, I have to use other
> Haskell is fun, Haskell is good, but its not the right answer to every
> question. Just have fun doing whatever you do :)
Thanks - I hope it will work out that way.
I have seen far too many fun projects turn into bad ones... (might as
well have been my own fault, of course - we'll see).
> If at the end you wrote up a little summary of your project, what you
> used, how it went, what issues you ran into - then perhaps people can
> tell you (with the benefit of hindsight) how Haskell might have been.
Um... I think you'll be able to tell which problems would have been
non-problems in Haskell, but you probably won't be able to tell which
non-problems would have been problems in Haskell. (I tend to do things
differently than what's the established standard way of doing things.
Which means I'm usually both very innovative and very frustrated...)
More information about the Haskell-Cafe