Hacker News new | past | comments | ask | show | jobs | submit login

I think the problem here is that if you want to go visual, you need to go visual all the way. There should never be a case you need to manually debug a serialized representation. If your environment can't support that to an acceptable level of reliability, then you need to explicitly stick with a double-form approach, where the visual form and serialized form are "equal citizens" and both are meant for the user to work on in parallel.

Trying and failing to go with option one is what leads to the XML mess you describe.




For what is worth, the reason we tried (and promptly abandoned) the idea to work at the XML level was the following: in a visual language some stuff like:

- "Find all places where I am using records of type X and replace that with a record of type Y"

- "where did variable RunningTotal gets initialized? when do we reset it"?

- "Can I write a simple script to verify which temporary variables are not removed from the dataflow after being introduced?"

(Debug in the more traditional sense works reasonably well in webMethods - but this was not the problem - the problem was that it is impossible to reason about a "program" as a series of instructions and analyze it as such, even if at the end of the day a webMethods flow service is just that: a series of steps that manipulate data in a tuple space).

So this is not a critique of webMethods (or FMJ) - I am explaining what the problems you encounter are when you try to use the graphical metaphor to work on reasonably complex programs. Most of the successful examples cited so far seems to be mostly about audio manipulation. I suppose this means most of the time you compose smallish "scripts", you work alone and not in a team, logging is not an issue, building large, reusable components is not an issue, extending existing logic is not an issue, and so on and so on.

Having also worked a lot with an ancient 4GL application (where the language was supposedly "more expressive") I can sum it up all my doubts as follows:

Certain paradigms work well as long as the programs are written and maintained by a single developer to automate simple tasks but do not scale very well past that point




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: