[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
jo at durchholz.org
Sun Dec 24 09:20:48 EST 2006
Tomasz Zielonka schrieb:
> On Fri, Dec 22, 2006 at 06:16:03PM +0100, Joachim Durchholz wrote:
>> * Forcing the expressions that get written out means that I cannot use
>> lazy evaluation freely. In particular, if some library code returns a
>> data structure that contains a lazy-infinite subexpression, serializing
>> it would not terminate, and I'd have little chance of fixing that.
> I fear that you may not have a good intuition about laziness and how it
> is used in practical programming at this moment. Why not try and see if
> there really is a problem?
Because I might end up having sunk several weeks of my time, just to
find that there is a problem anyway.
Second reason: the restriction will warp my design style. I'll avoid
putting infinite data structures in the game data - and that means I
can't explore open-end strategies, I'll have to "program around" the issue.
For this reason, I'd rather wait until Haskell serializes thunks as a
matter of course, and explore lazy programming fully, rather than trying
it out now and have my style warped.
>> Now that the first serialization will destroy many of the advantages of
>> laziness, I don't think I should try to wrestle with its disadvantages.
> A common problem with laziness is the possibility of introducing space
> leaks. That's when the program accumulates a big thunk which, if forced,
> would reduce to a small and simple value. "Nobody" is interested in this
> value now, so it is kept in a lazy, space inefficient form. A classic
> example is a thunk like this (1+1+1+1+1+1+...)
> One solution to this problem is "deepSeq" - forcing full evaluation of a
> data structure. Naive serialisation performs this as a side-effect.
> What I want to tell is that the "problem" you see here could just as well
> be a *solution* to a different problem that you haven't considered yet -
> space leaks!
I'm aware of this kind of problem.
However, hailing deepSeq as a solution before I even encounter the
problem is just constraining the design space.
Besides, why use a lazy language at all if I can't use laziness anyway?
Most of the data will be in the server, which will get serialized at
>> I'll move on to the alternatives - Alice ML and/or Clean. Both can
>> serialize without forcing lazy subexpressions.
> I am pretty sure that with those solutions you will meet other problems
> of the same caliber.
No FUD, please ;-)
And yes I know there are devils lurking in every language and
environment. I'm pretty sure that Haskell has a few others to offer, too.
(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.)
> What I propose is the following: keep Haskell as a possibility (with
> one discovered problem), consider problems with those other
> languages, then decide.
Exactly. The decision I made right now is just to explore another
language. I'll be back and trying out Haskell after a while - though
that probably won't before serialization didn't get serious.
> There doesn't seem to be a perfect programming language.
>> This all said, I still don't think that Haskell or its execution
>> environments are bad. They just don't fit my requirements, which are
>> A) I want to get my feet wet with an FPL (seriously, this time), and
>> B) I want to do a webserver application (I know the domain).
> Haskell would play well with those requirements. I've created some web
> applications in it, and I was delighted with the things I learned in the
> I am starting to suspect that you have a third requirement you haven't
> told us about, like: C) I want to make profit ;-)
I won't deny that profit is on the agenda, but it's taking a back seat
during the evaluation phase.
The situation is slightly different: I'm sick of PHP and want to make
profit with something better ;-)
However, I admit there are additional requirements, too. I just didn't
want to add too much noise explaining why I chose exactly that project
for exactly this language.
The real hidden agenda is that I'd like to have to option to move away
from browser-based stuff, toward client-server stuff. The ability to
serialize arbitrary data between applications would be almost
indispensable - you can program around the restriction, but then you get
impedance mismatches *between Haskell applications*.
More information about the Haskell-Cafe