Stefano Mazzocchi wrote:
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.
another view on the same 'less is more' principle might be that the [abstract interface] is *less* then the [specific implementation]
as for deciding which implementation gets favourised over which others the stress on the *only* seems to imply 'only _after_' which kind of gives a historic advantage to the first one in place
as such it might be perceived as conflicting to the darwinistic approach?
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.
after the previous remark this would bring us to comparing the advantages of 'consensus' over 'darwinism'
pure Darwinism indeed would not be able to exclude some cohabitation (as obviously seen in the real world)
Polymorphism is a great technical concept, but it's an incredibly poo community tool: it creates balkanization.
cohabitation is a far nicer word for it, it also indicates that crossing the borders and intermingling is still alowed...
the above paragraph also strikes slightly on the subject of 'humans controlling technology' or the other way around...
the question arises indeed: will the application of a "great technical concept" lead this community into behaving badly, or are the people around here still human enough to find a means to control all of it?
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.
or slightly less poetic: as many ways as there are willing members of this community
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.
urgh.
what is exactly the relation between FSM and 'goto'? and why would it be the case in the web-context?
<on the side>
my computer-science history is far less impressive: to boil it down in one line: I never even got to doing the 'goto' stuff!
isn't a simple while loop a FSM? </on the side>
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
nope, nothing in place yet some messages must of been introducing this idea
there is just no need for me to use continuations in a particular case I'm working on, can that be an observation?
there is also very little experience (and I have to admit willingness) to do (a lot of) js wrapping of existing Java backend logic.
(just an extra risk that doesn't need to be introduced)
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.
this really brings us back to why current flow did get the specific flow semantics and were not hooked up using actions. obviously LESS IS MORE?
- 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.
the other vision is that the community is not controlled by the technology it is developping (it would be a very bad case of subversion of control)
I'm *strongly* -1 to anything that will go in this direction.
if this == balcanization then how could we have another opinion? the negativism is all over the word...
if this is about 'how the community is controlled', then probably using the VETO (by all means the most personal position one could take) might be an unlucky choice for expressing your opinion
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).
some improvement might come from allowing different ideas...
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.
we could get into the ambition of achieving both since they are in completely seperate domains
even more it is probably not the ambition of the community to explore the factual limits of the term 'unified community'
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.
'few', 'they', 'our'
let us try to reread by thinking about 'users', 'us', 'community'...
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.
leaving me speechless, could somebody explain how to still contribute?
-marc= (exhausted, an confused: should I feel as a bad engineer or as a bad citizen, or both?)
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
[EMAIL PROTECTED] [EMAIL PROTECTED]
