I went thru the recent "[RT] Generalizing the flow" thread and I want to
give my impressions on it.
First of all, let me remind you that we agreed (for the FOM, but I think
the vote can be applied to anything) on the general design principle
that "less is more": start small and add things *only* when needed.
This is exactly the opposite of behavioral abstraction: provide an
abstraction and free the people to implement their own in order to avoid
having to reach consensus.
Polymorphism is a great technical concept, but it's an incredibly poor
community tool: it creates balkanization.
The Avalon people know very well what I'm talking about.
Sylvain and Marc are proposing that we create an abstraction for flow
control, stating that a continuation-based implementation is just one of
the particular possible implemenations.
If you read my original RT about flowmaps (written two years ago), I was
wondering exactly this: what is the *best* way of describing the flow of
a web application in a way that keeps it centralized in one location?
There is no single answer. Just like turing completeness doesn't stop
new programming languages to emerge.
- o -
I learned programming at the age of 8, writing BASIC on a Commodore
Vic20. I did BASIC until high school when, at the age of 13, I was
*forced* to learn Pascal.
First thing I asked after being introduced to the language: if there are
no explicit line numbers, how do you know where to "goto"? Answer: you
don't, you don't need to.
What?
It was *impossible* for me to concieve a programming language without
gotos. I didn't know that it was such a common misconception that it
took decades for computer scientists to realize it was not the case.
(until Edsger Dijkstra made it evident in 1968).
After Pascal, I moved into C, then x86 assembly code, where I went back
to direct jumps, and hating it. It took me some 8 years to fully
understand why gotos are harmful. And that was as I was a teenager and
my mental flexibility was at maximum.
Will I be able to do the same now? how much time would that take me?
- o -
Marc is advocating that "there is more than just continuation-based flow
control" and he is dead right: there are as many ways to implement flow
control as there are stars in the sky.
But there are two major families of approaches: procedural vs. declarative.
The continuation-based flow is procedural. What Marc is proposing in his
wiki page is declerative. state oriented. in short, it's a FSM. it's the
"goto" equivalent for the web.
I'm sorry, but I cannot stop considering this harmful. or, at least, a
poor substitute (for this kind of usage) for what we achieved with
continuation-based produceral flow descriptions.
- o -
I understand Marc has a FSM-based controller already in place and wants
to use it as a flow controller. I think that a few lines of javascript
will do the job perfectly, or he can still keep using actions as he's
doing right now.
- o -
Sylvain likes abstactions. Otherwise the sitemap interpreter would be
called SitemapInterpreter instead of TreeProcessor.
I used to love abstractions as well.
Now I'm far more concerned about them: less is more.
Cocoon is powerful because there is *ONE* sitemap semantics and my
continuous obstructionism to the pluggability of sitemap semantics
forced discussions to happen, that created community and focused
development.
The sitemap and the flow are the core of Cocoon. Abstracting them will
balkanize the cocoon community.
I'm *strongly* -1 to anything that will go in this direction.
I'm *strongly* +1 to anything that will force discussion and improve the
existing ideas (as we did with the sitemap semantics over the years and
as we did with the FOM recently).
E pluribus unum.
NOTE: my not-so-secret agenda is to keep the cocoon community as strong
and unified as possible. This is my top priority, even higher than
technical excellence or elegance.
Still, I see nothing excellent in going back to FSM-based flow control.
I agree that flow control is a more general than continuation-based flow
control, exactly like sitemap is a much more general concept than "the
current cocoon 2.1 sitemap semantics" (which is just an instance of that
concept).
We choose one direction for our core and we keep evolving that. No
polymorphism just because a few people have legacy they want to reuse,
it's not our problem.
Yeah, the next thing to unify will have to be the form handling. XMLForm
and JXForm will be shortly unified. Hopefully, Woody will be as well.
Balkanization is the problem. FS is the signal. Community fragementation
is the danger, expecially when blocks will be there.
So, instead of routing around consensus, let's work toward it, that
means: no abstraction for core parts.
--
Stefano.
