Re: [wsbpel] Gotos Considered Harmful?

[Assaf Arkin <arkin@intalio.com>]

Very illuminating article. Both Jim and Ron raise a good point.

Like any good - and some bad - ideas, goto has survived the prohibition 
period due to nothing more than it usefulness. It's been resurrected, 
relaballed and under new name has been the topic of discussion in this 
and related groups. We can't not use it, we just fell better using it 
under a different names. I'm not suggesting we resurrect goto from the 
dead, just that we recognize what we're dealing with.

As the article points out, it's all about explicit transfer or control. 
The issue that Dijkstra was trying to correct was the lack of formalism 
and proper controls in Fortran. Gotos and common blocks were not evil by 
themselves. They just lacked the sufficient mechanism to make them 
useable. The risks - mostly bugs arising from code change - outweighted 
the benefits.

We've followed Dijkstra's teaching and took those structures out of the 
language only to end up with useless development tools. But being too 
damn useful they resurfaced as capabilities external to the language. 
And with the proper set of controls and formalisms, ended being damn 
good solutions.

Common blocks were replaced with shared data in the database. Same 
concept, same problems. Yet, where Fortan lacked any formalism and 
mechanisms to deal with race conditions, concurrent and serial access, 
segmentation, etc, the RDBMS brought back the ability to use shared data 
in a safe way.

Gotos has resurfaced in the form of callback. Think of any decent 
enterprise application, in particular one involving long running 
process. Can you imagine it without the use of callbacks? Yet, what is a 
callback other than a more capable means for 'explicit control transfer'?

As I pointed out previously, using event handlers as the basis for an 
example, we do have this looping capability already ingrained in the 
language. It wasn't part of BPEL 1.0, but I guess the authors felt it 
was useful enough to add this capability to 1.1. We can treat is as 
taboo and try to ignore its existence, we can remove it from the 
language (rollback to 1.0), or we tackle it heads on and build tools 
that can make the most out of it. Any preferences?

arkin


Ron Ten-Hove wrote:

>    I afraid we may be reasoning by anology here. Cycles in a process 
> graph may "smell" like gotos to those of  us steeped in the lore of 
> software engineering, but to a business analyst they are a natural, 
> necessary construct. They describe how real business processes work.
>
>    Trying to impose "fashionable" structured software concepts on 
> another domain sounds like a  questionable exercise, if the objective 
> is to model the business process at a high level. If this is not the 
> intent, then let us by all means attempt to structure BPEL processes 
> according to good software engineering practices, including being wary 
> of unstructured constructs.
>
> -Ron
>
> P.S. Does anybody remember computed GOTOs in Fortran IV? If gotos are 
> considered to be harmful, then the computed goto must be 
> life-threatening!
>
> Jim Webber wrote:
>
>> After hearing the arguments against Gotos on today's telcon, I have to
>> (unfashionably) suggest that they're not so bad. See:
>> http://www.ppig.org/papers/12th-marshall.pdf for a short argument in 
>> favour
>> of not ignoring Gotos.
>> Note it isn't BPEL-specific, but makes the general point that there 
>> are some
>> places where a Goto is the right thing to use (though those 
>> situations are
>> few and far between).
>>
>> Jim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>>  
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org