soft-eng@MITRE.ARPA (Alok Nigam) (10/28/88)
Soft-Eng Digest Fri, 28 Oct 88 V: Issue 40
Today's Topics:
Software Maintenance (2 msgs)
Structured Editor vs. Text Editor (2 msgs)
Lisp machine Environments (4 msgs)
----------------------------------------------------------------------
Date: 23 Oct 88 17:12:59 GMT
From: uwslh!lishka@speedy.wisc.edu (Fish-Guts)
Subject: Software Maintenance
Well, it looks like there is an interest in a discussion on
software maintenance. Nobody else has started one yet, so I guess I
*could* get the ball rolling...(O.K. I will ;-).
One of the interesting developments in the software engineering
field as of late is NeXT's choice of bundling an object-oriented C
compiler (Objective C) and a nice group of reusable "objects" that
programmers can use. NeXT makes the claim that objects are much
easier to utilize than the traditional function call interface that
most systems offer; a specific example that was given was that using
windows in a program is supposedly *much* easier than past windowing
programmer-interfaces (and as a programmer on the Amiga, I can see a
real need for this sort of thing!).
Assuming that it is easier to use the NeXT objects, my question
is whether software maintenance with an object-oriented interface is
easier than software maintenance with a function-oriented interface?
IMHO, I would assume that it is, because objects (at least, very
strict objects) package an entire function in one programming "unit,"
whereas I feel that functions allow for too many interdependencies.
Therefore, it would be easier to maintain and upgrade an object
because changing a particular aspect of an object is not *as* likely
to break other objects. [If anyone needs more clarification on the
last point, just ask.]
Now, the above is pretty much conjecture on my part. What do
you think?
------------------------------
Date: 25 Oct 88 22:25:26 GMT
From: mnetor!utzoo!yunexus!geac!geaclib!daveb@uunet.uu.net (David Collier-Brown)
Subject: Software Maintenance
> I am looking for network discussions on software maintenance. Is
> there such a group (I've checked the help info, no luck). Or is
> this a good conference for issues of maintaining software?
Well, one fairly important place to look is MIT... There was a
seminal work on maintenance and the evolving of large systems done
as part of project MAC, which popularized the use of version
numbering schemes in Multics and the Arpanet, both of which had to
last far longer than the typical application (be it accounting,
graphics, spreadsheet or whatever... you can't affort to rewrite
operating systems and networks regularly: ask IBM about os/360).
Regrettably, i can't remember the **right name** of the paper.
Maybe when I get down there next month...
------------------------------
Date: 25 Oct 88 00:20:37 GMT
From: gandalf.cs.cmu.edu!ntanaka@pt.cs.cmu.edu (Nobuyoshi Tanaka)
Subject: Structured Editor vs. Text Editor
Please forgive me if this question was discussed before.
There are two main idea for editors, I think. One is a simple text editor,
the other is a structured editor. The structure editor will guarantee the
result of editing is legal for the specific programming language, of course.
So, in that point, it is superior to the simple text editor. But, I feel
most of the existing structure editors are not so friendly for me. Say,
when I want to move a cursor downward and to insert words, I may not do it
straight in the structured editor. How do you think? I know, it may
depend on programmers' taste. Or, does anyone around there know the editor
that has both characteristics of the text editor and those of the structured
editor, i.e., in which we can move the cursor in the same way as in the text
editor and which guarantees the result of editing are legal to the language?
Any opinions and suggestions are appreciated. Please send me an e-mail.
I will post the summary.
------------------------------
Date: 26 Oct 88 01:24:00 GMT
From: m.cs.uiuc.edu!wsmith@uxc.cso.uiuc.edu
Subject: Structured Editor vs. Text Editor
My research group at the University of Illinois has written a language
oriented editor, Leif, that has most of the characteristics you describe.
First, the program may be edited with text editing commands and the text is
also analyzed to locate syntax errors. Also, commands are available to select
syntactic elements of the program. Leif may be targeted to several
different languages by writing a new specification in Bison and Lex.
I believe that guaranteeing that the result of the editing is legal in the
language is too strict. When I am translating a program from one language to
another, or performing a complex editing change, I often make the program
syntactically incorrect but will the later correct the error. Leif
accomodates this desire by postponing its analysis until a request is made.
The command move-to-error will find any syntactic errors and help correct
them.
Leif is available via anonymous FTP from a.cs.uiuc.edu (cd pub/Leif) and
other arrangements are possible if FTP is impossible.
----------------------------------------------------------------------------
Bill Smith | Mail sent to leif@cs.uiuc.edu or
wsmith@cs.uiuc.edu | uiucdcs!leif will go to our research group
uiucdcs!wsmith | headed by Roy Campbell.
------------------------------
Date: 23 Oct 88 18:31:16 GMT
From: ai.etl.army.mil!mike@ames.arpa (Mike McDonnell)
Subject: Lisp Machine Environments
The best software development environment on the planet earth is a lisp
machine. This is a "PC" in the generic sense. It is the quality of the
supporting environment that makes this so. Those of us who know and
love these beasts are saddened by the manufacturing and marketing
ineptitude of the selling companies who have more-or-less insured that
"lispms" will never be much more than a curiosity. Sigh.
------------------------------
Date: 24 Oct 88 21:09:21 GMT
From: uwslh!lishka@speedy.wisc.edu (Fish-Guts)
Subject: Re: Lisp Machine Environments
Do other people in this group feel this way as well? I agree
that Lisp environments typically have some nice features and tools,
but trying to read Lisp for too long makes me see non-existant
parentheses. That and the dynamic scoping make it harder to read than
many other languages, IMHO. Don't get me wrong: I think Lisp is one
of the all-time GREAT languages (although I prefer the Scheme
dialect), but I do not think it is one of the best to have to
write/read/revise/debug/maintain code in. There just isn't enough
structure to the actual language. BTW, I've used some Franz Lisp,
Emacs Lisp, XLisp, C-Scheme, and did several semester projects on
Xerox Lisp Workstations ("1108's") in InterLisp, LOOPS, and OPS5 (a
Lisp-derived language).
Aside from the language, the Xerox 1108 workstations do not seem
to offer that much more than modern environments for other languages.
Windowing is now common. Browsers are becoming common.
Language-oriented editors are becoming common. Symbolic debuggers are
becoming common. Interpretters for compiled languages (such as C) are
becoming common. Although most language environments do not offer all
of the above features, most of them are present. On my Amiga, I have
everything listed above except the interpreter (although not as well
integrated; what do you expect for mostly PD software? ;-). Are Lisp
environments still *that* much better for development.?
One thing I have considered doing is adding an extensive
preprocessor to Lisp, to make it look more "structured" (like C or
Pascal). Essentially, one would write in my structured language (call
it CL), and the CL-parser would spit out Lisp code as an intermediate
language, to be interpretted or compiled or whatever. I'm sure
*someone* has thought of this before. Any comments?
------------------------------
Date: 25 Oct 88 21:05:54 GMT
From: amara!chionia!tom@uunet.uu.net (Tom Doehne)
Subject: Re: Lisp Machine Environments
> Do other people in this group feel this way as well?
Yes, I feel this way. My reasons are below.
> I agree that Lisp environments typically have some nice
> features and tools, but...
opinion of Lisp as a difficult unstructured language omitted...
> Aside from the language, the Xerox 1108 workstations do not seem
>to offer that much more than modern environments for other languages.
>Windowing is now common. Browsers are becoming common.
>Language-oriented editors are becoming common. Symbolic debuggers are
>becoming common. Interpretters for compiled languages (such as C) are
>becoming common. Although most language environments do not offer all
>of the above features, most of them are present. On my Amiga, I have
>everything listed above except the interpreter (although not as well
>integrated; what do you expect for mostly PD software? ;-). Are Lisp
>environments still *that* much better for development.?
The greatest shortcoming is that all those things are not integrated in
non Lisp-machine environments, lacking the tremendous advantages integration
gives.
I worked on a Symbolics 3670 for the last two years, and feel that it is
one of the finest development environments available for rapid prototyping.
The integration of the parts of the environment give the following benefits:
The editor not only `knows' about the language, but about the program
you are writing. With a keystroke or two, it will load the definition
of the function your cursor is on, so it can be edited. Or it will
let you cycle through all calls to a function. Incremental
compilation of a selected part of the edit buffer is useful, as are
things like setting trace and breakpoints. Cutting from the editor to
an interpreter or vice versa is helpful, especially if you want some
idea of what an expression will do in the program and don't want to
type it twice. I also liked being able to call up documentation by
positioning the cursor on the function name and hitting
<cntl>-<sh>-d.
In the debugger, it is nice to be able to invoke the editor on an
offending function definition, change and recompile it, then return to
the debugger window and reinvoke the call from a point just before the
problem occurred. (An advantage of an interpretive language.) It is
also possible to grab the values of variables in the debugger, operate
on them, return the resulting value(s) as the function's result(s),
and continue with execution. This is especially nice for ignoring a
bug that is fairly unimportant so that you can test what you are
working on at the moment. Finally, the Symbolics debugger gives you
numerous options for continuing execution when you enter it (if it
can). Finally, you can `inspect' any data object on the stack, and
follow all the pointers easily, by invoking the Inspector.
The inspector (a data browser) made it easy to follow pointers,
examine nested data structures, and edit them. Since you can call it
from your code, you can easily stub a function by calling the
inspector with a list of parameters. When it is called play with the
parameters in the inspector to get the value the function should
return, and exit the inspector giving it that value to return (a
matter of a few mouse clicks). Helps a lot with testing, especially
if someone else doesn't have the function written, but you have a good
idea of what it should return.
It's also possible to simply try things out on a command line
interpreter, then cut the sequence from the interpreter and paste it
into the editor to turn it into part of your program.
The latest Symbolics online documentation is quite impressive. Not
only can you go through list of sections that contain a certain
string, but the sections are hypertext, so you can go from one topic
to a related one mentioned there. It supports diagrams not just text.
It has a tree structured summary for browsing. And the ability to
shove topics to one side (literally) and take them up later. Even
days later (you can permanently store the list of topics you have).
I won't mention the support for OOPS, except to say it's fairly nice.
------------------------------
Date: 25 Oct 88 17:39:04 GMT
From: apple!shebs@bloom-beacon.mit.edu (Stanley Todd Shebs)
Subject: Re: Lisp Machine Environments
>>[...] manufacturing and marketing
>>ineptitude of the selling companies who have more-or-less insured that
>>"lispms" will never be much more than a curiosity. Sigh.
Amen to that. There are also technical reasons that have been argued over
endlessly. My view is that specialized Lisp processors have never been
able to stay ahead of stock hardware and "normal" programming environments
for more than a year or two - if for no other reason than that the good
ideas in the Lisp environment get imitated/improved on elsewhere. For
instance, Lispms have complicated and slow window systems, while the rest
of the world ends up using X. Lispms have hardware for tags, now SPARC
has it too, but simpler and less obtrusive. Nowadays the big push is to
have GC for every language, down to and including C. Lisp isn't some sort
of magic that renders systems uncopyable; instead the Lisp marketeers are
in the unenviable position of pioneering, then being trampled by the hordes
following along and re-engineering!
>[...] trying to read Lisp for too long makes me see non-existant
>parentheses.
You have clearly failed to reach the level of true Lisp wizardry :-).
Parentheses are unimportant to reading, about as significant as commas
in most languages. Indentation and special forms, that's all that counts.
> One thing I have considered doing is adding an extensive
>preprocessor to Lisp, to make it look more "structured" (like C or
>Pascal). Essentially, one would write in my structured language (call
>it CL), and the CL-parser would spit out Lisp code as an intermediate
>language, to be interpretted or compiled or whatever.
This has been done several times since the 60s. LISP2, CLISP for Interlisp,
and RLISP for Portable Standard Lisp spring to mind immediately; there are
probably others.
------------------------------
End of Soft-Eng Digest
******************************