I need a message-goto object language

[Lynn H. Maxson]

I'm somewhat surprised that the method of 
structured analysis and design, which has dominated 
"large" contract software in the United States 
since the late 70's, never made it to France.<g>  
Basically the method was developed by Larry 
Constantine who published under the Yourdan Group 
and taught at IBM's System Research Institute 
(SRI).

Structured analysis uses dataflows.  Basically the 
only purpose is to insure that the system works in 
terms of completeness, having a continuous "flow" 
(connection) from the outputs in a system to their 
inputs into the system.  Structured design follows 
analysis by offering a heuristic that converts the 
dataflows into structure charts, giving you 
essentially the functional programming.

It is a two-step procedure.  More to the point in a 
recent UML conference participants heard from 
several large scale OO projects that UML had to be 
supplemented by structured analysis and design to 
support (people) communication.

I will put in a plug here for you to consider a 
specification language instead of a programming 
language as this will allow automated generation of 
dataflows, structure charts, and executables from 
the writing of a single set of specifications.  
Thus the only "people translation" that takes place 
is that from user requirements to specifications.

If you insist on an OO-only language, then you 
admit to using at least two languages, one for OO 
and one for converting it to a form (procedural) 
usable by the computer.  I would probably recommend 
a specification language which will allow either 
form in the same manner (and for the same reason) 
that it supports both declarative and 
non-declarative styles.

Language authors should not dictate user styles.  
The function of a language author, at least one not 
so arrogant to believe that "he" knows what's best 
for you, is to "enable" the user and support his 
style.  That's a far more difficult task than what 
we see reported here.  It is the one adopted by the 
PL/I committee in the early 60's.  I would suggest 
that if you want to see what's possible in a 
programming language, particularly a 
procedural-based one, that you take a close look at 
PL/I.

As a historical note Kenneth Iverson's book "A 
Programming Language" is slightly misnamed as he 
proposed its use as a specification language to 
replace flowcharting.  I would recommend highly 
your reading at least Chapter 1 to see how to 
visually represent functions and their 
interconnection.  I say visually because you can 
"see" the difference between a well-structured 
program and one of spaghetti "go-to" code.

There is nothing wrong with using structured 
programming control structures despite their 
embedded "go-to"s.  Not all "go-to"s are created 
equal.<g>  The purpose lies in creating more 
readable code in a linear manner (top-down).  The 
rules are topologically simple (one-in, one-out).

To be clear dataflows are "data passing" only, not 
"message passing".  Another difference lies in the 
processes, even their names, being unimportant in a 
dataflow analysis.  All the process represents is 
some form of a filter which maps the outputs back 
onto the inputs without concern (at this time) for 
the rules involved.  That's why it is called 
"structured" (one step at a time) analysis and 
design.  The second step, structured design, 
fleshes in the processes as well as creating their 
hierarchical structure.