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 some time.
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 process.
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*. Regards, Jo