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.
