No, they are not. As Phil Leary points out in his reply lower in the thread, FLOW is more or less interpreted on the fly.
I certainly respect your experience and opinion. I have no doubt about your effectiveness within IS. However, whether something can be done faster in Java or FLOW will almost certainly depend on the task at hand. Time and time again I’ve seen solutions developed in FLOW an order of magnitude faster than the equivalent in Java. I’ve also seen the reverse, but that’s much more rare.
This is indeed the entire point of the thread. If you’re a Java programmer, and not comfortable with FLOW, you’ll certainly be faster coding Java services. But you’ll be doing so at the expense of debugging, maintenance, etc. The primary programming language of IS is FLOW, not Java. Put a capable FLOW programmer next to a Java programmer, and they will compare favorably in terms of productivity. For some tasks, the FLOW programmer will easily finish first. For some other tasks, the Java programmer will finish first.
That’s certainly doable. I assume you make heavy use of the Java API and the Service.invoke method? I assume that a good part of the code is simply building pipelines and retrieving pipeline values. This begs the question: Why are you using IS? Why not WebSphere or WebLogic, environments that are geared for Java programming?
This is arguable. I have never encountered a case where I thought debugging was hard, or slow. I’ve done a fair amount of raw Java programming and I’d argue that the amount of effort and the speed are about the same.
Speed of code execution is but one measure of a solution. Most of the time, this is immaterial to the overall solution and other factors are more important.
Agreed.
Agreed. Exception management within FLOW is quite awful.
That’s one of the primary reasons for the success of IS–you don’t need to be a Java programmer. It’s definitely a plus if you are but if you’re not, you can still be quite effective.
Do your solutions use FLOW services at all? Or is everything mostly Java services? Do you use the built-in services extensively? How much FLOW background do you have?
This thread was prompted by post such as “how can I do a Java service that will parse XML” and other posts that plainly show a lack of understanding of the “sweet spot” of IS and the basics of FLOW and the built-in services. It wasn’t to say never use Java. The key point was “know the tools you’re working with” and which to use when. My opinion is too many default to using Java services when using FLOW services would be a smarter choice.
The other extreme you seem to follow, do it as Java services first, rarely as FLOW services, seems odd to me but I can see how such an approach has a certain appeal.
It would be interesting to see the two approaches compared head-to-head. Pit a developer proficient in FLOW (primary) and Java (secondary) against a developer proficient in Java (primary) and FLOW (secondary) and see who is able to build a “better” solution based on several criteria.