[Haskell-cafe] Re: Getting my feet wet - not in Haskell though

[Joachim Durchholz]

Neil Mitchell schrieb:
> Hi
> 
>> (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:
> http://haskell.org/haskellwiki/Monads_as_containers

That one escaped me.
Thanks.

> 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 
techniques).

> 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...)

Regards,
Jo