>>> Mr. Kay But I remain an enthusiast for pure functional programming; the more I see it in action, the more I feel it is the right solution for 90% of the code we write. <<<
<NON POLITICALLY CORRECT OPPINION FOLLOWS> Given I LOVE XQuery over nearly any language, I am slowly leaning the other way from Mr Kay The fact that every XQuery (and XSLT) implementation I know has had to provide non-functional idioms to me indicates that the dream of pure functional programming is that ... a broken dream. Side effects are *extremely valuable*... atleast for humans, even if dangerous, the value vs danger vs potential optimization of an ideal optimizer to me weighs in with the side effects and abandoning the pure functional aspects. Modeling temporal changes is something us humans innately understand (even if poorly) and demanded by people. We wince at the thought of someone wanting an accumulator or a mutable variable "Thats so OLD FASHIONED" ... but damnit, it works and its something people understand. I understand the goals and theory of pure functional programming are profound ... but in practice I have been more and more convinced that atleast for human programmers pure functional programming is horridly painful and that the promises of the "computer figuring out a better way of doing what you meant" are still an unfulfilled pipedream. I boldly propose that perhaps as a group we step back and get off our high horse and admit that some procedural aspects to XML processing be embraced instead of hidden in the dark corners of "vendor implementations" that every single vendor has had to provide because pure functional programming has simply not lived up to its promise. ---------------------------------------- David A. Lee [email protected]<mailto:[email protected]> http://www.xmlsh.org
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
