Conference turris::languages

I partially disagree with your wife's professor.  It started out as a truly
useful way of programming -- top down derivation, no GOTOs and so forth.
The chief advocates of SP -- Dijkstra, Wirth, Hoare, Parnas -- showed real
understanding and explained their programming methodology brilliantly.

Then Dijkstra flipped out and began spewing nonsense about how people should
not run programs that haven't been proven correct.  Real world programmers
were turned off by him and turned instead to snake-oil salesmen such as Ed
Yourdon and Ned Chapin.  When it became obvious that these greasy people
didn't have the insight but were becoming fantastically wealthy, structured
programming faded from the limelight as just another set of coding standards,
just another cure-all that doesn't work.  People became fed up with the whole
idea of structured programming.

SP is now generally regarded as just another set of coding standards, meant
to be ignored like all coding standards.

-- Bill B.

I agree with the Professor completely.

I think at the heart of that statement is the knowledge that algorithmic
languages (the majority of 2nd generation languages) are on the verge of
becoming out-dated.  SP is an algorithmic concept.

Most of the more interesting third generation languages like SETL have the
advantage of requiring programs to merely state the definition of the answer
rather than the algorithm required to compute it.  This is a clear step in the
right direction. 

In this regard, I think that APL (which was invented in 1957) was decades
ahead of its time.  It was the first 3rd generation language during a time
when 2nd generation languages were still on the drawing board.  And APL
does not have structured concepts!  They simply aren't needed.

In my eyes, FORTRAN, PASCAL, PL/I, ada, etc. are just all different dialects
of the same thing.  The main reason I just can't get excited about ada is
that at best it's only a refinement of things that have been around for
years.

	db

Well, I don't think algorithmic languages are in any danger of disappearing
in the near future.  Old habits die hard.  To a Pascal programmer, APL code
most likely reads like an object file.  (For copious examples of APL code,
see Appendix E of the VAX-11 APL Reference Manual.)  But then again, APL
probably deserves a note of its very own...

-- Bill "OPS5 (talk about unstructured languages!) Project Leader" B.

Since When Was SETL non-algorithmic???????  The talk the guy gave here at ZK
the other day described SETL, and it seemed to me to be as algorithmic as any
other language, including BLISS or MACRO-11, that I've seen.   The fact that
you give the machine NO DIRECTIONS on how to make it go fast is EXACTLY what
causes the whole thing to be A REAL PIG.  APL ditto.  

The only real trends away from that seem to me to be the rule based AI stuff
and even that is still 'here is how to do it' not 'here is what is to be done'.


As for GOTO'lessness and other things - bad programmers write bad programs,
regardless of the language.



At least Ada has true separate compilation - you don't have to rely on
programmers beliefs in interfaces or compatibility.   It will be great for
large projects...


/Bevin "just a note writing algorithm" Brett

I was very dissapointed that I wasn't able to make the SETL presentation.

Nonetheless, the SETL I used when I was in school did have algorithmic
features, but the essence of the language was to define an answer domain
and then specify the properties of the answer.  Not all programs can
be represented this way, but as an example, a program to generate prime
numbers did not have specify any algorithm, only the domain and definition
of a prime number.  That's the idea behind it (and APL).

Regarding your criticism of SETL and APL in terms of draining more system
resources: so what?  I mean, I've never understood that criticism.  Using APL
and SETL allows the machine to do things that you would have had to do
yourself. Is that bad?  That requires more resources, but what are you using
machines for anyway?  I can only assume that that criticism comes from an
attitude that a program isn't "worthy" unless it consumes a proven minimum of
electricity.  That's a very expensive attitude.  Run-time efficiency is not
always (in fact seldom) the highest priority.  APL clearly trades machine
resources off for human involvement.   I think that's a correct trade-off.

Certainly APLs performance is acceptable for many applications.  Not every
program is a device driver.  Many programs written will ultimately consume less
resources over their lifetime when running than the resources used to develop
the program.   Now if you want to talk about wasting resources, look at ada.
Ada compilers are tremendous resource hogs and yet don't do anything for you
than PL/I compilers.  APL on the other hand allows you to develop programs as
much as 10 times faster (source: James Martin, Applications Without
Programmers). 

	db

P.S.  Bill B.  Can you read Japanese?  If not, does that mean Japanese is
      unreadable?  People usually think APL is unreadable because they don't 
      know what the symbols mean.   APL is different from the
      various decendents of FORTRAN and thus it's declared unreadable.  Will
      all future languages have to look like FORTRAN to be considered readable?

      I find well-written APL to be more readable than most languages because:
      1) I understand what the symbols mean; and 2) I don't have to translate
      an algorithm back into a concept.

Any pointer to a vax/vms or vax/unix implementation of SETL would be
appreciated.

As unexpected as it seems, I have some apl progs that I wrote 10 years ago
(base twelve (no editor)) that I just dug out and I can actually read them.
My first question to people that claim apl experience is "what is the comment
symbol?".  Makes all the difference, those comments.

d

Well, one of the creators was at ZK last week, saying he wanted to establish
a closer relationship between NYU/Courant and DEC.  He said he would be
glad to provide a copy.  His host was Joel Clinkenbeard, and if Joel can't
help you, you can send mail to SCHWARTZ@NYU on the ARPAnet.
				/AHM

RE: .5
	Dave, I didn't say that *I* consider APL to be unreadable, just that
	the uniqueness of its syntax hinders the spread of its popularity.

	Back to the subject of SP:  An ex-DEC software engineer once told me
	that the reason he was initially impressed by Structured Programming
	is that when it started, he was a Fortran programmer, and Dijkstra's
	name contains the sequence I-J-K!

-- Bill B.

I disagree with the idea that structured programming is just a fad,
although a lot of fads have arisen in and around the structured
programming methodology.

What is a program?  I think it's a collection of primitives
(steps, functions, objects, or whatever you like) which direct
the actions of an interpreter towards the carrying out of a
function that appears externally as a single step.

The structure that ties together the pieces of a program is structure.
All programs have structure.  Good programs have structure that is
more readily passed on to other programmers than idiosyncratically
or perversely structured programs.

A program's initial value lies in its execution, which is accomplished by
an interpreter reading the steps and carrying them out (or, usually, a
data dependent subset of them).  A program's ongoing value lies in its
extensibility, which lies in a contemplator reading the program, and
imagining a similar program with an extension to it.  Structure helps 
the second process.

Dave C.

In case you didn't notice it, the last note implied that ALL programs
get interpreted.  So I don't get too excited about the interpreter
vs compiler controversy.  If you are going to give me a compiler,
give me one that runs fast and produces fast code.  If you are going
to give me an interpreter, give me a fast one, with lots of relevant
primitives. Is "relevant" subjective? You bet it is!

If you don't believe me that all programs get interpreted, see G.Bell
in COMPUTER ENGINEERING on layers of interpretation.

I'm afraid I find your rationale to be self-defining.   You have defined
programming using the structured approach, and therefore all programs have
structure.  That approach is what we're used to, but is not the only
approach.

Inherent in structured programming is the concept of a control flow, and
sequence.   I'm believe that the future will lead us away from this.  We
already have seen almost english-like query languages that allow you to do
things like: 

	PRINT ALL RECORDS AFTER JUNE-84 WITH UNPAID BALANCES

The above statement is really a program, but note that there is nothing
procedural about it although it could easily be translated into a structured
language.   I'm convinced that such non-procedural representation is the way of
the future.

I agree that structured languages will always have there place because our
machines our procedural.  However, I think that within 10 years most problem
solving will be done using non-procedural languages, and that is why I agree
that structured programming is a "fad".

	db

Inherent in what I've expressed above is the reason why I just can't get
excited about ada.   Having yet another procedural language is about as
exciting as a new brand of cigarette.

I concede that there are some new ideas in ada, but not enough (some think
too many) to make it some kind of programming standard.

	db

Are you saying that because our underlying hardware operates the way it
does, that procedural languages abound?  I am thinking of the Japanese
and the "fifth" generation machines.....

Rick

I would have to agree that structured programming is inherently a procedural
programming concept.  As Dave points out, there are many approaches to
higher level programming which are much less procedural than traditional
programming (APL, functional programming, logic programming, SETL, etc.).

Most of these languages, however, still have a procedural component.  APL
has control flow within functions, and programs must be organized as
collections of functions.  The same is true of SETL.  PROLOG is conceptually
nonprocedural and nondeterministic, but in practice it has its own control
flow considerations.  I believe that to this extent, the concepts of
structured programming are still relevant to these languages.  I would
say that the essence of structured programming is the correct breakdown
of a problem into subproblems, so that each unit (module / function /
procedure / clause / whatever) of the program corresponds to a subproblem,
and the resulting program structure satisfies certain desirable characteristics
of clarity, efficiency, modifiability, esthetics, etc.

But ts ofFstructured programming are still relevant to these lan
uages.  I wouldGsay that the essence of structured programming is the correct breakdownEof a problem in
o subproblems, so that each unit (module / function /�flow within functions, and programs must be organized as��	}�

Neil has identified a key point: the control structures (IF-THEN-ELSE, CASE,
etc.) are important only to procedural languages, but structured problem
solving appears to be more universal.   I agree completely.

An interesting thing to note is that most "philosophical" APLers agree that the
need for GOTO function (which is the only built-in APL control structure)
results from deficiencies in the language.  The need mostly arises from
inefficiencies in the array approach for certain problems.   The other thing
that necessitates GOTO is the need for sequential operations in a language
that strives for parallelism.

What peaks my interest far more than yet another dialect of pascal is the
introduction of nested arrays for APL.  Nested Arrays seem to elegantly address
the majority of these problems. The flexibility of nested arrays seems to solve
the efficiency problems by allowing non-rectangular, non-homogenous arrays. 
The sequential problem is largely solved by the introduction of a new operator
("each") defined to apply a derived function sequentially to arrays. 

But the most elegant feature of nested arrays is that they are completely
compatable with regular APL.  ANY correct APL program will run unmodified on a
nested array implementation.  Even more elegant is that the definition of
nested arrays is entirely "consistent" (APL-ish) with regular APL which 
allows APL to retain it's "diamond"-like structure referred to in a previous
note.

	db

Re .14:

Don't confuse Structured Programming with Structured Design.

Restricting your choice of control flow operators to a few key primitives
is what Structured Programming is generally defined to be.

The plethora of hierarchical design techniques involve Structured Design.

They are different things.  I often use Structured Programming when I have
not even stopped to design a program, because it is too trivial or is
something that I have done many times before.

				/AHM