Daaaammmn! Well said Stefano!
More info in line.
Stefano Mazzocchi wrote:
<snip/>
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.
Now with one of our chief reasons blocking cooperation gone, we are starting some evolutionary growth in all of our modern containers toward one standard. We are starting small--we have three very different ways of recording meta information, which we are unifying. That said, here are some things which is helping us toward our goals:
* We have three modern containers with different requirements. It may sound bad, but you need that many different implementations to get close to a generic solution.
* We are adopting a more XP approach to the world. Start small and add as necessary. Adding tests first help us stay honest (although this is slow in comming--we are behind).
* The different implementations help us understand what is necessary and what isn't. Designing for simplicity is difficult. We are not there yet, but two people who have migrated from ECM based projects to Fortress were very impressed with just how easy it was. That wasn't by accident.
You may ask, "Aren't you standardizing on one way of doing things?" My answer is yes. It took a couple of tries to find out what was *good enough*. We also are learning how to balance contract strength and usability.
Change is a constant ;P We are learning to provide our users with the tools to allow that change without major rework to their projects.
<snip/>
- 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.
Ok, I started late. I was 12 with a Commodore 64. I jumped from BASIC to Assembly.
Unlike your experiences, Borland Assembler for the C64 provided a really nice feature: labels. I could put a label any place I needed to jump, and the compiler would take care of the line numbers. It even had some relative labels that were used for conditionals and loops. Awesome stuff.
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.
The thing you have to ask yourself is "what is being modeled?". The whole idea of _flow_ means that we have a task with a beginning and an end. The procedure is the primary concern. I agree with your summation in this instance.
However, don't forget that rule based programming (Artificial Intelligence) is purely declarative. Given a set of facts, you can apply a rull and get results that make sense. That is also a very powerful tool--but not for this purpose.
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.
Agreed. The problem with Cocoon is that there are so many extension points and abstractions, you have a conceptual internal model that is as clear as mud. The problem as I tell folks in situations like this is not that abstractions are bad, but that the *wrong* abstraction is bad.
Abstractions allow you to try different ways of doing things until you find the one that works. If you can't find the
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.
Cocoon is powerful for a great many reasons. Just provide enough wiggle room for revolutionary ideas like Flow to be able to be tried out. That doesn not mean over-abstraction or FS, it just means to allow different evolutionary paths to be tested.
You will find that as you move forward an abstraction to an idea that just makes better sense. For example, as the Cocoon community works to merge the three different form handling standards into one which parts of the evolutionary branches are the strongest, how they complement each other, and how you can provide for future evolution of the standard.
Remember that stagnation is just as bad as balkanization--be careful not to allow the pendulum to swing too far the other way.
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.
Do allow for that on multiple cases. Just try not to allow long time forks like GCC and EGCS which after several years finally were able to remerge. Remain lightweight and agile.
Still, I see nothing excellent in going back to FSM-based flow control.
I agree. It is the wrong abstraction.
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.
Amen! The key to avoid community fragmentation is to avoid drawing a line in the sand and daring people to cross it ;P Seriously: guidance is preferred over mandate. Once a mandate is handed down, then you will have the community polarize on the issue. When you issue guidance, then the community is more likely to consider working through the issues and converging on one way. That one way is usually somewhere in the middle of all seemingly opposing views.
It has been my experience that as long as people are willing to defer their preference to whatever is the greater good, then there are no unsolvable problems.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin