In the flow discussions there have been a lot of discussions about the choice of programming language. IMO that is a quite small part of the total view, the development of idioms and design patterns for building webapps in Cocoon as well as integration of external components and systems and documentation of all this, is in my view much more important. If we take a look at the current status of the flow development we have a lot of integration code for the FOM, Christopher have written a lot of code that connects the flow to form handling and other stuff, there is an ongoing discussion about how to integrate object persistance in the flow and so on.My problem with the current flow implementation is that is does not make my life easier. In my webapp I have a lot transactional stuff, trys/catchs and lookup stuff. So writing these things in Java is natural for me.
All this will (hopefully) lead to that we have a number of well documented design patterns for how to develop webapps of different kinds, backed up by good example code and integration code. After a while (hopefully) an important part of our communities developed knowledge in webapp development will be codefied in JS and easy to reuse for all of us.
Now, what would happen if we decide that JS is just but one implementation of the flow concept, and that we as a community does not have any opinion about which language to use. But as a convinience we have instead developed a continuation enabled version of BSF so that you can use your favourite language. In such a multi langage scenario would any common flow script code and design patterns develop or would we have enough problems in supporting all the language bindings for basic stuff?
Actually we allready have some experience in supporting multi language implementation of some of the basic concepts in Cocoon in the form of AxKit. I get the impression that the cross polination between the two projects is very limited nowdays. The same thing would risk to happen if we supported JS-flow, Java-flow, Phyton-flow and so on.
In a large project with lots of involved people, technical optimality is not as important as fixing the contracts when they are good enough, so that people can start to work on the next level. Chosing JS and FOM is fixing the contracts and makes it possible for the next level of webbapp development to take of. So much community effort is invested in the choice of JS as flowscript language so that it is not enough that another program language would have been a little bit better. The cost of changing direction is so high that the language must be much better in some very fundamental aspect.
Returning to wour webapps: handling transactions, try/catch and lookup stuff all seem like important stuff of general interest, to do in webapps. Don't you think it would be possible to find a way to solve these problems in the current JS-based flowscripts even if it might be less elegant than in Java?
The taste can differ, I did consulting in the telecom industry for a while and where a lot of things are described in terms of FSM. After that experience FSM is the last thing that I would use for solve anything with ;)If I think of a Flow, which connects pages and combine actions, then the FSM is the first solution, which comes in my mind. Everything else twisted my thinking.
* In FSM you have no good mechanisms for abstraction (like procedures and functions), large FSM can be quite hard to grasp.
* FSMs in textual form can be quite hard to understand, partly because they don't support any localization ( in the text) of behaviour, you must understand a lot of it at once. If you instead use the mythical FSM GUI, you instead get the problem that large FSMs take a lot of space to describe graphically, (they don't fit on your screen or your paper anymore).
* FSMs in webapps are in a strict mathematial sense not FSMs, as a FSM only is suposed to depend only on external events, if you let it depend on and update a store, it becomes something equvalent in power to a Turing machine instead (mathematical FSMs has strictly less power than a Turing machine). And it becomes structually similar to goto-programming. It can be shown that an FSM and a language with sequence, choice and repetition (a regexp is used in typical automata theory books) are equivalent. From this it follows that a structured modern programming language (one based on blocks, if and while) and a goto-language can describe the same things. The general experience is that structured languages are easier to understand and maintain than goto programs. IMO mainly as their behaviour tend to be more localized in the text, so that it is enough to understand a small part of the program at once. I believe that all these experiences applies in the comparison between our continuation based flowscript language and FSMs as well and that flowscript based webapps will bw much easier to understand and maintain than FSM based as soon as they become a little bit larger.
/Daniel
