Now that this is totally off topic, I wanted to say thanks for the long description. I don't have the formal experience with language design that you do (which I should before arguing about it ;)). The distinction between declarative and procedural is of particular interest, and one which had never been made clear to me before. I didn't read the entire email yet, but I will, and probably come back with some questions.
cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sean A Corfield > Sent: Wednesday, July 23, 2003 9:58 AM > To: [EMAIL PROTECTED] > Cc: Sean Corfield > Subject: Re: [CFCDev] Extra white space > > > On Tuesday, Jul 22, 2003, at 21:09 US/Pacific, Barney Boisvert wrote: > > I spent hours arguing with a friend who does exclusively .NET stuff > > about > > event driven web apps. As long as you have to reload the entire page, > > procedural seems like a much more logical way to go. You start at the > > top > > of the page, and go until you get to the end of the page, and then > > stop. > > But that isn't the only option - Flash widgets (or even full Flash > apps) mean that a single rendered page can make multiple requests to > the server before the page needs to be reloaded. That's an important > step forward and a reason why event-driven applications are important. > Flash allows genuinely asynchronous events, breaking down the > procedural model. > > > That "driven by an XML file" statement pretty much > > gives it away. If it's declarative, the order is fixed when it's > > coded, not > > runtime, and is therefore procedural. > > Actually declarative programming - a la Prolog etc - is specifically > *not* procedural. That's the whole point of a declarative approach: the > engine can implement the solution in any order it wishes, as long as > the declarative rules are obeyed. > > Mach II, for example, allows a single incoming event to generate > multiple additional events. At present, those events are queued in the > order they are generated but there is no real reason why that needs to > be the case. One of the experiments I intend to conduct with Mach II is > to change the event processing mechanism to process the queue in > different orders to see how far the model can be pushed. > > Consider a simple web form that accepts user feedback, writes it to a > database and says "Thank you". There's no requirement that the database > be updated before the thank you page is generated - they could be done > in parallel (if the language allowed it) and could certainly be done in > either order even in CF. Mach II allows you to process the > submitFeedback event and generate updateFeedbackDatabase and > sayThankyou events but those could be processed in any order (and then > the output generated by 'sayThankyou' would be returned to the browser). > > > I'm curious. At a very high level, is this a fair description of what > > happens in a typical Mach-II request cycle? > > 1) Fire an event (click a button/link) > > 2) Let the event handlers do whatever, possibly firing additional > > events > > 3) get page content > > This is the result of one or more event handlers as part of step 2. > > > 4) add layout(s) > > There's no specific layout mechanism but you can either: cascade one > view into another (using content variables); or use a view plugin. The > cascading happens as a result of an event handler (and is therefore > part of step 2). > > > 5) return the page to the client > > Yes. > > So in reality what it does is: > > 1) An external event comes in > 2) Process events until they are all processed > Processing an event may generate additional events > 3) Return result to external system > > And in between various processing points, plugins are called: > - preProcess > - preEvent > - postEvent > - preView > - postView > - postProcess > Some of these will be called multiple times depending on what events > are processed and which views are selected. > > > To me there is a very distinct line between the first two steps and > > the last > > three steps. > > Hopefully, the above explanation makes it clearer? > > > It is my > > humble opinion that using an object system to do procedural work is bad > > I think you're confusing several things here. OO and procedural are not > actually exclusive - almost every single OO language is procedural. > Declarative languages are few and far between - and all of them require > an execution framework under the hood that is procedural. Why? Because > we rely almost entirely on a procedural execution architecture: the > register-based, sequential CPU. OO allows for a less sequential > procedural system because the execution framework often permits > parallel and/or asynchronous operation. Declarative programming takes > that a step further by not imposing procedural ordering. > > Procedural programming is about specifying 'how' things happen and, > usually, 'when' (i.e., in order). > > Declarative programming is about specifying 'what' needs to happen (but > not 'how' - or 'when'). > > OO is (generally) a form of procedural programming that provides > polymorphism, inheritance and encapsulation - which provides a > high-level idiom to model the problem space. Most OO systems rely on > synchronous messaging - procedure calls. > > An implicit invocation architecture (events, listeners) lets you mix > declarative programming (specifying the events, listeners and some > operations) with procedural programming (inside the listeners - for the > sequence of operations that is executed when a specific event is > processed). > > Back to my simple web form example - it has three events: > - submitFeedback > - updateFeedbackDatabase > - sayThankyou > There would be a feedbackDatabase listener and a thankyouView. You > would declaratively say something like: > > on event submitFeedback(args): > raise updateFeedbackDatabase(args) > raise sayThankyou > > on event updateFeedbackDatabase(args) > notify feedbackDatabase('add',args) > > on event sayThankyou > view thankyouView > > In CSP (Communicating Sequential Processes - a stylized language > specifying programs for parallel systems), you have the choice of > grouping operations with parallel or sequential qualifiers. Occam is a > good example of a concrete language based on CSP. In such a language, > the first declaration above could be written: > > on event submitFeedback(args): > parallel > raise updateFeedbackDatabase(args) > raise sayThankyou > or: > > on event submitFeedback(args): > sequence > raise updateFeedbackDatabase(args) > raise sayThankyou > > It should be clear that there is no reason in this scenario why the > declarative version needs to imply the second (sequential) form - the > first (parallel) form is a valid option and may be more efficient. > > Sorry for the length of this but it touches on a subject dear to my > heart - computer language design and implementation, which was my post > graduate research work in the 80's, and my first few jobs. > > Sean A Corfield -- http://www.corfield.org/blog/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
