Sub-functions: some thoughts

BPELers,

    At the risk of going off topic, I'll try to apply an analogy[1] to
our subfunction discussion. Let us say we are crafting a specification
for a new, simple
imperative programming language. We have spent a lot of time defining
an exec() mechanism for the language that we are all agreed on, and
consider an important part of the language. It is
noted  that this actually means that subfunctions aren't
strictly necessary -- all subfunctions can be treated as a kind of
exec(). We now break into two camps over this: 

  
The minimalists, who argue that adding subfunctions is
unnecessary, and just clutters the language. The KISS principle rules.

  

  
The traditionalists, who argue that virtually every other
language of this sort has subfunctions, and programmers will expect to
have them in the new language. Doing an exec() to calculate a
square-root sounds silly, and slow.

  

    The minimalists attempt to find the middle ground, by holding that
a sufficiently clever IDE could create the illusion of subfunctions,
while in fact creating code that used exec() instead. The
traditionalists reject this line of reasoning, claiming that the
language is being crafted for humans to use, understand, and reason
with, not code generators.

    Enough analogizing; back to BPEL: we seem
to be revisiting an old issue -- who is the target of this language:
tools, or humans? This is a topic we have discussed in the past; I
believe our consensus was that human readers (and even writers) were
important. In addition, we have seem to have accepted the assertion of
the original authors that the language is not merely for execution, but
for process modelling as well.

    Also, the principle of minimalism in a language has to kept in
check. To quote Satish Thatte (June 20, 2003):

  "There is some element of judgment involved in deciding what
is minimal enough for BPEL -- emulation is not a conclusive argument."

    So how is our judgement to be informed and guided? Personal taste?
Keep the status quo,
since that is easiest? Serve crass commercial interests? Examine
current practice in industry to adopt
the best elements and build an idea of  what expectations have been
created over years of practice and innovation? Recall what makes open
technical standards viable, valuable, and widely adopted? Use a ouija
board? ;-)

-Ron

[1] In general, I hate analogies, but given the membership of this TC,
this might actually be an apt one (YMMV).