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

[Joachim Durchholz]

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