cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 18:51:30 GMT


On Mon, 14 Jul 2003, Stefano Mazzocchi wrote:

>
> On Monday, Jul 14, 2003, at 05:32 America/Guayaquil, Stephan Michels
> wrote:
>
> >> My point is: absraction in some key areas might prevent discussion
> >> (like this one) and might prevent ideas to be exchanged (like the
> >> above, which might be totally damn or genial, I don't know [kudos to
> >> Chris to pointing me to BPEL4WS, BTW]
> >
> > All JavaScript Code can be transform into Assembler, or Basic. That's
> > not the point. A programming language should make the implementation
> > of a solution for a given problem as easy as possible.
>
> A scripting language for a flow description is, IMNSHO, the most
> natural way to describe it (see below why)

I agree with you that writing a Javascript program is a lot easier than
writing a state chart, but only if you have a mostly linear combination
of pages.

> > In the direction
> > the people prefer Basic over Assembler, and later Pascal/C over Basic.
> > My problem with the current flow implementation is that is does not
> > make my life easier.
>
> You said you haven't even tried using it.

No, I don't said that. I also try to be open as possible. I tried
but the only point I love of the Javascript is the fast development,
which were negatived if you must developed Java components.

> > In my webapp I have a lot transactional stuff,
> > trys/catchs and lookup stuff.
>
> Which are entirely possible with the current flowscript.
>
> > So writing these things in Java is natural for me.
>
> All java programmers tend to think at javascript as the "poor man
> client side shitty version of java". It's not. It only has a very
> unfortunate name and a very unfortunate history of object model
> inconsistencies between interpreting environments. But the language is
> *extremely* well designed and balanced, must more than it appears at
> first sight.

I understand that you defend Javascript. And it is a really
good implementation for the majority. I really don't want to
offend some people. The only thing I can say is that I tried,
but it is not a solution for me.

> > If I think of a Flow, which connects pages and combine actions, then
> > the FSM is the first solution, which comes in my mind.
>
> Of course. That's exactly why GOTO was implemented in programming
> before understanding that you didn't need it.
>
> But now it's a sin to even thinking about having it.

No, it's dangerous like pointer. If you know what you are doing, fine,
but in the other case you should abandon them.

> But, if history repeats, it will take a few decades to understand that
> "FSM for the web are to be considered harmful". So I don't expect
> everybody to buy it right now. I'm patient :-)

Okay, maybe I'm wrong, but maybe not.

But if I understand you correct, you try to prevent different solutions,
which try to adopt some ideas of the continuation concept.

> It reminds me of those people I meet that say they will not use Cocoon
> because it doesn't promote official J2EE practices.
>
> Those comments used to piss me off.

:) No, I'm not one of these peoples.

> Now I just smile, sitting very relaxed on the side of the river,
> waiting for their dead bodies to pass by ;-)

Gosh, you must be confident!

The problem with your way is that you maybe find the energy minimum of
the system, or maybe you stuck in a local minimum.

Raise your mutation rate ;-)

Stephan.


Mime
View raw message