Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.lang.misc
Subject: The State of Software Development
Message-ID: <21402@ucbvax.BERKELEY.EDU>
Date: Fri, 23-Oct-87 08:55:33 EST
Article-I.D.: ucbvax.21402
Posted: Fri Oct 23 08:55:33 1987
Date-Received: Sun, 25-Oct-87 15:25:44 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 93

The state of software devlopment is not primitive, unfortunately most
of us are using far from state of the art tools.

These tools are:

A history log of expressions typed to the system, with undo and
edit-and-redo.

Debuggers that let us set breakpoint anywhere in the program and
singlestep at the source statement and source expression level. At any
point, you can change any piece of code INCLUDING the code currently
executing without loosing the context of the calculation so far. The
debugger must run in a window independent of either to program under
test or the history log of expressions typed to the system.  The
complete source code and documentation must be available for editing
at the click of the pointing device on any sub-expression.

If the initial state of something is undefined (like order of
evaluation in many langauges, the initial state of local variables in
C, and the scheduling of tasks in a multi-tasking system,) then the
debugger should randomize them, to catch programs that work only by
coincidence. 

data structure examiners, that let us look at a data structure as a
graph a window, or as a form in a window. And let us change the data
structure with a click of a pointing device, and the typing of an
expression. Among the data structures examinable in this way is the
calling stack of nested procedures (so we can see not only globals and
current locals, but also obscured locals.) Naturally, the data
structure presentation tool uses an object oriented system so I can
override generic printing procedures within it.

regression testers, so after any change the program gets run against a
history of all previous input data that uncovered bugs, and the
outputs compared, to ensure that no old bugs are re-introduced.

languages that provide memory-management, so I don't have to worry
about buffers being too small, or so generous that my program won't
run.

langauges that provide a model of an application program, a hierarchy
of types, and default procedures with overriding, so that most program
is the overriding of inappropriate default procedures. Even a new
program is written not by debugging a blank sheet of paper until it
works, but by debugging a no-op generic application that already has
huge amounts of error-handling, and user-interface code installed and
working.

Help systems and browsers because any system in which it is easy to
write code to perform lots of functions will be big. Too big to
memorize, so it must be easy for the system to show me around those
parts I've forgotten.

Multi-media programming languages. I don't mind specifying most verbs
procedurally, but I work with nouns such as sound and artwork that are
cumbersome to specify in C. The Macintosh associates a database with
each program, programs refer to objects in the database via keys.
Objects are pictures, icons, waveforms, melodies, ... . and are
created with an extensible type specific editor. Intrinsic data of
this sort (as opposed to the more traditional input data.) can be
changed without recompiling. 


hierarchical editors, that select from a unified system the
information that you've asked for:
conceptually, these are one unit and should be stored together:
1.) The documentation you need to understand the concepts in using this unit
2.) The documentation you need to use this unit
3.) The documentation you need to understand the concepts in fixing
this unit.
4.) The documentation you need to fix this unit.
5.) The documentation of the design history of this unit, needed to
evolve it further.
6.) The actual code
7.) Earlier versions of the code
8.) The wish-list for future enhancements to the code.
9.) the test input data and output results.
10.) the academic literature on which this unit is based.

Yet, you rarely want to look at all of this at once, so a good
programmer's editor will hide all the irrelevant pieces.

Decent global optimizers and type checkers, so that code can be made
run faster at the cost of increased compile time, with no loss of
safety.

I've met no system that has _all_ these, but each of these exists in
some systems.


--- David Phillip Oster            --A Sun 3/60 makes a poor Macintosh II.
Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu