[
Lists Home |
Date Index |
Thread Index
]
An ICFP-like programming contest for XML. What an excellent idea!
(The history of ICFP, BTW, suggests that the results don't depend on the
problems chosen or the tools used to build the solution so much as the
contestants.)
Bob Foster
Michael Champion wrote:
> On Thu, 30 Dec 2004 13:05:37 -0700, Uche Ogbuji
> <Uche.Ogbuji@fourthought.com> wrote:
>
>> I'm sure I can win a "productivity" bake-off using
>>available Python/XML tools any day against any XQuery machine. I can
>>say the same for most of my colleagues.
>
>
> I love that idea . Iit would be fun and instructive to see a bakeoff
> with Erik Meijer in one corner with C-Omega, Uche in another corner
> with Amara, Michael Kay in another corner with XSLT, and an XQuery
> zealot-to-be-named-later in another corner, working away at a few
> randomly chosen XML problems. :-) Anyone want to organize a physical
> or virtual version of that? (Apologies to the people named, I'm
> personifying the tools for rhetorical purposes not making a serious
> suggestion!)
>
> The trouble is, I'll bet that the results would depend on the problems
> chosen more than the tool used to build the solution -- There are
> plenty of problems that C-Omega could solve in a few lines that XSLT
> would bog down on even in the hands of a master, and vice versa. I
> wouldn't be surprised at all if Python or XQuery were the best overal
> with some fair and balanced distribution of problems, but that would
> be meaningless to people who spend most of their lives with documents
> and love XSLT, or spend their lives with straightforward schema-valid
> data and can exploit the kinds of things that C-Omega does at compile
> time.
>
> Another problem is that there are at least two target audiences here
> -- the people who learn and build tools for their own use, and those
> who build tools for ordinary mortals to use. The question in my mind
> is whether the the winner of a bakeoff among XML ubergeeks would
> predict the winner of a bakeoff among ordinary mortals with, say, a
> week's training on the tool of choice? That's a contest I would
> REALLY like to see!
>
> Sigh, yet another problem is the short-run vs long-run issue: In the
> long run we can expect with some confidence that the "declare what the
> answer looks like and let the tool build the code" approach will work
> best, but I doubt very much if any existing tools can do that. On my
> better days, I can see the point that Dana alluded to that
> short-term optimization keeps the state of the art from advancing to
> meet the full potential of the more declarative approaches. Still, in
> the long run we are all dead, and our careers will be dead much sooner
> if we don't solve real customer problems in a reasonable timeframe!
|
