[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - not in Haskell though
Joachim Durchholz wrote: > >> To adhere to uniformity, strong abstraction, and the Principle of >> Least Surprise, we thus chose to force lazy futures in Alice ML. > > Well, I wouldn't have expected that pickling has an effect (other than > wrapping the value up for transfer), so at least I would have been > greatly surprised. That "effect" is just strictness. Since you generally cannot pickle a future (and usually wouldn't want to), pickling naturally has to be strict. Making lazy futures a special case, in this one single strict operation, would be surprising (and extremely ad-hoc). - Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
[EMAIL PROTECTED] schrieb: Joachim Durchholz wrote: I'll move on to the alternatives - Alice ML and/or Clean. Both can serialize without forcing lazy subexpressions. I don't know about Clean, but with respect to Alice ML this is not correct: Alice ML uniformly blocks on futures upon pickling, including lazy ones. Bad enough, but not necessarily a showstopper: lazy data structures aren't idiomatic in ML (I just hope they aren't in Alice ML either). Sometimes you may want to pickle lazy suspensions as such, but more often it is not what you want. In particular, the suspension can easily be larger than its result, I'd say that in this case, the suspension should have been forced earlier. I.e. the problem is not in the pickling but in the suspension being larger than its result. I'm entirely unsure how to determine when a suspension should be forced anway. The programmer could give hints, but that would probably break all kinds of abstraction barrier; and the system usually doesn't have enough information to decide when it should do it. Seems like one of those problems that generate lots of PhD papers... and the closure may contain resources which cannot be pickled. If such a suspension was produced by an abstraction you may even argue that making contained resources observable partially breaks the abstraction. Well, Alice ML doesn't serialize things that don't make sense outside the originating process (i.e. resources). That's better than silently serializing a file handle and being surprised by that handle meaning an entirely different file after unpickling. OTOH one could do even better. Simply unpickle a resource as a proxy for the original resource in the originating process. (If the process has died, assume that the resource was closed - the vast majority of resource types has a "closed/unusable" state anyway.) To adhere to uniformity, strong abstraction, and the Principle of Least Surprise, we thus chose to force lazy futures in Alice ML. Well, I wouldn't have expected that pickling has an effect (other than wrapping the value up for transfer), so at least I would have been greatly surprised. I even dislike to see something like that in a language that has side effects. But you can't have everything anyway ;-) Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - not in Haskell though
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 No category theory. A basic understanding of apples and boxes is all that is required. http://haskell.org/haskellwiki/Monad has a list of about 10, plus pretty much every book/general tutorial introduces Monad's as well. If there is really nothing out there that helps you understand, you might want to prod some authors as to what isn't clear/understandable. And Haskell let's you serialise thunks just fine (use Yhc), 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. Haskell is fun, Haskell is good, but its not the right answer to every question. Just have fun doing whatever you do :) 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. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - not in Haskell though
Joachim Durchholz wrote: > I'll move on to the alternatives - Alice ML and/or Clean. Both can > serialize without forcing lazy subexpressions. I don't know about Clean, but with respect to Alice ML this is not correct: Alice ML uniformly blocks on futures upon pickling, including lazy ones. Sometimes you may want to pickle lazy suspensions as such, but more often it is not what you want. In particular, the suspension can easily be larger than its result, and the closure may contain resources which cannot be pickled. If such a suspension was produced by an abstraction you may even argue that making contained resources observable partially breaks the abstraction. To adhere to uniformity, strong abstraction, and the Principle of Least Surprise, we thus chose to force lazy futures in Alice ML. > 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.) No FUD, please ;-) ;-) Cheers, - Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - not in Haskell though
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? > 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'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. What I propose is the following: keep Haskell as a possibility (with one discovered problem), consider problems with those other languages, then decide. 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 ;-) Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
OK, just to let everybody know why I'm dropping Haskell.
Basically, the reasoning is this:
* I want to write a process that doesn't terminate.
* Since the environment can and will enforce termination occasionally,
the process must be able to write its state to some external storage
("serialize it"; flat file or database doesn't make much of a difference).
In fact I'll want to serialize most of the program's state on a regular
basis (say, once per day), just to safeguard against bugs and hardware
crashes.
* In all Haskell implementations (with the exception of Yhc), there is
no way to write out data without forcing unevaluated expressions inside.
(Yhc isn't mature yet, so it's not an option currently.)
* 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.
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.
I'll move on to the alternatives - Alice ML and/or Clean. Both can
serialize without forcing lazy subexpressions.
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).
Regards,
Jo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
