On Wed, 6 Mar 2002 18:05:42 -0500, Jason Foster <[EMAIL PROTECTED]> wrote:
> > I looked on the Rhino code, and also spoke with Christopher Oliver > > (Rhino serialization) and Norris Boyd (Rhino main developer) about > > continuations support in Rhino. > > You *have* been busy :) > > <snip content="full continuations are out"/> Yep ;-) > While I agree with your conclusions, I have to admit that I'm now starting > to get a little confused about the key points of the flow language. Going > from Stefano's recent posting to the cocoon-users group... Please see below. > > The flowmap syntax, unlike the sitemap where the XML syntax is a perfect > > choice for its intrinsic declarativity, will use a > > programming-language-like syntax since a flow is much more similar to a > > program and will normally be written and managed by programmers which > > are used to more 'procedural' approaches. > > > > The flowmap will also be transparently stateful: writing a web > > application that creates the sum of two numbers will be as easy as doing > > > > var a = getA(); > > var b = getB(); > > c = a + b; > > show(c); > > > > the underlying implementation will allow Cocoon to know 'where you left > > out' the execution of your program and restart from there. > > Transparently stateful is one thing. Full support for continuations is > another. > > From the Rhino code links already mentioned in this thread, it should be > fairly straightforward to "allow Cocoon to know 'where you left out' the > execution of your program and restart from there." This isn't the same as > continuations, but it does accomplish what Stefano describes. > > I guess what I'm wondering is whether, for someone trained in standard > procedural programming, full support for continuations really offers all > that much? Is the goal to change how these developers approach their > problems, or is it to allow them to use the same languages they already > know with transparent support for "stateful execution"? > > Near as I can tell, the really big thing, other than transparent states, > will be the abilities to call a Cocoon pipeline for output and to > construct pipelines on the fly. <-- deliberate Functionality Syndrome > provocation, but let's be honest... it *will* happen regardless of whether > we use Rhino or FlowScript. As I said in an earlier message, we should not have a language designed for the average programmer, but for the hackers we all are. It would take a lot of words to explain why we should do this, and other people have done much better explaining this. Therefore I ask you to go read some interesting stuff: Worse is Better: http://www.jwz.org/doc/worse-is-better.html (the short version) http://www.dreamsongs.com/WorseIsBetter.html (long version, highly entertaining and funny) Five questions about language design: http://www.paulgraham.com/langdes.html > I'm not trying to take anything away from continuation-style programming, > Scheme, or any other language. I'd actually like to learn about this > stuff. What I'm wondering is whether we are pursuing purity at the > expense of maintainability and comprehension? Probably this is controversial, but maintainability and comprehension usually come from purity. The whole apparent complexity that you see in Lisp like languages is built on top of only 5 (five) operations: quote, variable reference, lambda, if, set variable and procedure call! Everything else is syntax only, which is translated to above 5 operations. > Regardless, I can't wait to try out the end result. Take that WebObjects! Me too! Back to work now ;-) Greetings, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
