cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <e9625...@student.tuwien.ac.at>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 20:25:16 GMT
Hi all!

I'm a bit confused by the discussion, so please let me throw in my 
(perhaps naive view) of the situation and giving you the possibility 
clearify the situation.

I understand the position of Stefano which mainly is community driven 
and wants to prevent fragmentation.
But I also found the suggestions of Sylvain and Marc (renaming certain 
parts) a good one, since they are IMHO very easy to understand by a new 
user.

So why don't you make a compromise by:
* Renaming like Sylvain and Marc suggested (and many agreed)
* Keep only one implementations (JavaScript) as the official one
* Allow alternative experimental implementations
* Let Darwin do the rest ;-)

Perhaps I'm overlooking something (perhaps the FSM stuff, which I'm not 
particularly interested in ATM), so please give me some guidance. But if 
not then I don't really understand, why it has to be that difficult.

Anyway, thanks for your effords so far (all of you)!

Bye,
	Andreas Hochsteger
	http://highstick.blogspot.com/

Stephan Michels wrote:

> 
> 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