munck@MITRE-BEDFORD.ARPA (Bob Munck) (05/10/88)
It has occurred to me recently that one of the most primitive,
labor-intensive operations in our current Ada technology is the
actual entry of code by programmers. For example, it appears that
most programmers type an IF .. THEN statement by pressing SHIFT and
typing "I" and "F", releasing SHIFT and typing SPACE, the boolean,
and SPACE, pressing SHIFT and typing "T", "H", "E", and "N", etc.
They type lots of tabs and spaces to indent the code, take at least
three keystrokes for an assignment, have to type closing quotes,
right parenthesis, and right brackets, have to type the package or
procedure name a second time after the END, etc. etc.
I'd like to think that most programmers are using some kind of
Ada-aware editor, but I fear it isn't so. I'd appreciate an e-mail
note describing what you do and what other programmers in your
company/institution do. (People who read Ada-Info are apt to be an
unrepresentative sample.)
However, the simple Ada-aware editor is only a beginning. Editors
could do line-wrapping and spelling checking on comments as they're
typed, they could let you use a mouse to re-arrange code, and they
could display it with keywords in bold and comments in italic fonts.
They could allow abbreviation of identifiers and expand them as
they're typed, fill in the rest of an identifier when you've typed
enough for a unique selection, or let you pick names from the
declarations with the mouse.
At the next level of sophistication, an editor could contain a lot
of the compiler and use information from the current compilation
unit and the Ada library to help the programmer. This is a fairly
obvious approach that several systems already incorporate, sometimes
without doing the simpler things mentioned above.
I first saw an outline processor about twenty years ago, Doug
Englebart's fantastic system with the mouse and chord keyboard.
Currently I use a commercial product named "ThinkTank" and it
frustrates the dickens out of me not to be able to do similar things
when writing code. "Outliner-like" facilities would be great for
those who must maintain and update the code, also.
My current work is "operating system-type" code which, by its
nature, consists mostly of assignment statements, conditionals, and
complex data and code structures. I've found it useful to maintain
a drawing of the complete data structure using a CAD tool and to
write a tool that extracts a picture of the code structure to the
procedure level from the listings. I keep both of these up-to-date
and tacked to the wall in front of me. The point is, it would be
wonderfully convenient if these two pictures could be in windows on
the screen and allow me to pick names from them with the mouse.
Given that I can request statement skeletons by hitting function
keys with the left hand, I'd rarely have to move my hands to the
keyboard. Of course, it would be great to be able to update the two
pictures and have the changes propagate into the code.
Is anyone out there doing research into this kind of thing? I've
about reached the limit of macros for my emacs-like editor (Final
Word).
-- Bob Munck, MITREzellich@ALMSA-1.ARPA.UUCP (05/12/88)
In INFO-ADA Digest Vol 88 #115, Bob Munck discusses using language-aware "outline processors" for writing and modifying Ada code; he also mentions "Doug Englebart's fantastic system with the mouse and chord keyboard" from "about twenty years ago". It is probably little known, but Tymshare (whatever they're called now that McDonald-Douglas bought them up) markets the current version of Dr. Engelbart's system (called AUGMENT these days), which has hooks to let you add language-specific constructs to the BASE editor (so you can do things like issuing "Insert IF-ELSE" commands). Unfortunately for most of us, it only runs under the TENEX or TOPS-20 operating systems. They also happen to have a MiniBASE product that is a major subset of the BASE editor, and runs on the IBM PC family. I don't know whether the mini version has the hooks to add language-specific constructs or not, but it does use a mouse - and sells for only $59.50. They also made chord-keyset/mouse packages for a while, but nobody outside that community ever took to the keyset so they stopped making and selling it. I don't know who the marketers are these days, but Raylene Pak <RDP.TYM@OFFICE-1.ARPA> might be the right person to start with. A query to FEEDBACK@OFFICE-1.ARPA should also get you pointed in the right direction. Disclaimer: I've corresponded with Raylene Pak about getting MiniBASE and their AUGTERM (Augment workstation emulation package for the PC family) product, but I haven't actually used the software yet. I'm a long-time user of Tymshare's hardware and software, but haven't had any contractual connection with them for several years.
karl@grebyn.COM (Karl A. Nyberg) (05/20/88)
[Ed - forwarded. Hopefuly this won't have gone out twice!] -- Karl -- Date: Thu, 19 May 88 20:56:40 EDT From: umd5!mitre-bedford.ARPA!sdl (Litvintchouk) To: munck@mitre-bedford.arpa, INFO-ADA-REQUEST@ajpo.sei.cmu.edu Subject: Re: Typing Ada > I'd like to think that most programmers are using some kind of > Ada-aware editor, but I fear it isn't so. I'd appreciate an e-mail > note describing what you do and what other programmers in your > company/institution do. (People who read Ada-Info are apt to be an > unrepresentative sample.) I wish I had a really "Ada-aware" editor, but I've managed to tailor GNU Emacs on our Suns into something I (and a few fellow programmers) can live with. Currently the libraries I have added include: 1. VADS modes: Invoke most of the Verdix Ada tools with a single key each. 2. Code idioms: To get a "blocking queue" (in the Hibbard sense), type M-x adt-active (i.e. "active abstract data type"), at the prompt type QUEUE, and a skeleton of the package spec and body are inserted. (It includes the private part refined as a record type with a task component, etc.) I currently have a few code idioms for various kinds of abstract data types and selective waits (i.e. prioritized with guards), and am open to suggestions for more. 3. Suntools menu interface: Context sensitive Sun popup menus for these and other GNUEmacs modes I would like to add a VADS library browsing mode (which would work similar to Emacs' Buffer Menu mode), but I haven't had the time (yet). GNU Emacs already has dynamic abbrevs (i.e. can complete a name based on others already entered in the buffer), and hiding of indented structure (replaced by "...") deeper than a user-settable threshold. Together with the interface to a.tags I added, browsing of Ada code isn't too hard. One of my major gripes is that there appear to be no Ada prettyprinters that can work on code *fragments*. They all seem to work only on entire Ada compilation units; I don't even know of any ones which can recover from syntax errors in the Ada code and continue prettyprinting. Such restrictions make prettyprinters largely useless during the editing process. If a prettyprinter existed which could work on a code fragment, then one could easily create an Emacs "prettyprint-region" command by invoking the prettyprinter as an inferior process with the region as input. Bob Munck's suggestion of "outliner" like facilities for Ada is a good one. However, I thought that most document outliners assume that the document is tree-structured. But Ada's static semantics make Ada code a network, not a pure tree. (For instance, if you do something to a private type declaration, then the refinement in the private part may change, as well as references in the body, etc.) So an Ada "outliner" would need to be network structured, and deal with Ada syntax and static semantics. The commercial failure of DIANA has made attainment of this dream unlikely for those of us who cannot afford a Rational as our personal plaything. By the way, I believe that COMPASS is working on a smart interface to editing Ada source code, which eventually will include handling of network-like dependencies. If anyone from COMPASS is reading this, could you please enlighten us? Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{cbosgd,decvax,genrad,ll-xn,mit-eddie,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.
RCONN@SIMTEL20.ARPA (Rick Conn) (05/24/88)
Then again, if you are talking about editors, why stop with text? the Interactive Ada Workstation, funded by the Air Force, includes a Buhr diagram editor which allows the user to draw top-level Buhr diagrams and have these diagrams compiled into Ada package and task specifications. A nice first step toward a design. There is also a language-sensitive editor which fills in Ada constructs. The IAW will be available, at least in part, as part of Cadre's TEAMWORK during the next year or two. Rick -------
munck@MITRE-BEDFORD.ARPA (Bob Munck) (05/24/88)
> the Interactive Ada Workstation, funded by the Air Force, includes a > Buhr diagram editor which allows the user to draw top-level Buhr > diagrams and have these diagrams compiled into Ada package and task > specifications. About four years ago I started an IR&D project to do something similar with SADT diagrams. MITRE decided that the Air Force wasn't interested in things of this nature (SADT or Ada) and didn't renew the funding after the first year. (FYI, SADT diagrams are now an important tool in SDI work.) Though all I accomplished was a good PC-based tool for drawing the diagrams, I am convinced that this is the direction that "guts-level coding" has to take, be it Buhr, SADT, or whatever. People can "read" pictures better than words in a row; machines, until recently, couldn't do anything at all with pictures and could handle only very simple sequences of words (programming languages). I think it likely that Ada will be the LAST major one-dimensional programming language. When the pictures get to the point of being adequate for stating completely the operation of a system, we won't need the Ada anymore. It will become the equivalent of object code. -- Bob Munck, MITRE
RCONN@SIMTEL20.ARPA (Rick Conn) (05/25/88)
Hi, Bob, By and large, I tend to agree with you. The power of the workstations and the constantly-decreasing price/performance ratio along with the supporting graphics software and standards (still emerging) is making graphical software design and implementation more of a reality all the time. However, I still see a lot of people just plodding along with poor support budgets and 1970's technology. Like the American society with its growing chasm between the rich and the poor, I think we may also have a growing software/technology chasm. Ada may not be the last 1D language from that point of view. Rick -------
ok@quintus.UUCP (Richard A. O'Keefe) (05/25/88)
In article <25135.580491166@mbunix>, munck@MITRE-BEDFORD.ARPA (Bob Munck) writes: > People can "read" > pictures better than words in a row; machines, until recently, couldn't > do anything at all with pictures and could handle only very simple > sequences of words (programming languages). I think it likely that Ada > will be the LAST major one-dimensional programming language. People can read *some* *small* pictures better than they can read text conveying the same information. But it doesn't seem plausible to me that a program which would have been say 50k lines of ADA would be easy to follow as a collection of several thousand pictures. (Compare the information density of a paperback detective story with the information density of a comic.) I would like to see some evidence one way or the other about the practicality of pictorial systems -vs- structured text for non-trivial applications (e.g. if the whole thing can fit on a SUN screen, forget it).
rracine@ajpo.sei.cmu.edu (Roger Racine) (05/25/88)
There are many different approaches to software design. I do not believe that everyone can use pictures to do this. If you are at all familiar with the "left hemisphere" and "right hemisphere" (of the brain) theories, this should be obvious. Many people have difficulty thinking in words. They think in pictures (Einstein was one of these types of people). Then there are those who think in words. They have difficulty picturing things in their minds. Personally, I like to write words (Ada) and look at pictures for an overview. I have tried to use graphics packgaes to draw the design, and find myself "translating" the words into the graphics. It would have been much more efficient if I had a tool to help me write the words AND a tool to translate the words into pictures. The same thing was true with flowcharts. I always wrote the code first and then wrote the flowcharts. When I started working on the Space Shuttle program and found them using a flowchart generator, I was thrilled. I view the graphical design approaches as slightly better than flowcharting. I still prefer to design in a word-oriented manner.
eugene@pioneer.arpa (Eugene N. Miya) (05/25/88)
In article <12400974327.29.RCONN@SIMTEL20> RCONN@SIMTEL20.ARPA (Rick Conn) writes: >By and large, I tend to agree with you. The power of the workstations >and the constantly-decreasing price/performance ratio along with the >supporting graphics software and standards (still emerging) is making >graphical software design and implementation more of a reality all the time. >However, I still see a lot of people just plodding along with poor support >budgets and 1970's technology. Like the American society with its growing >chasm between the rich and the poor, I think we may also have a growing >software/technology chasm. Ada may not be the last 1D language >from that point of view. By and large, it has been the experience of the people I know applying to Ada jobs, that most contractors tend not to have fancy workstations yet, even Macs are few and far apart. These are major companies with 2 and 3 digit acro-names (not computer companies). Bureaucracies still have vested interest in the Departmental machine. A friend just interviewed with three Defense contractors in the LA area and decided to stay in Silicon Valley on this basis. The decentralized used of PCs and workstations really challenges the centralized authority of lots of ex-military organizations (companies, I already know about my employer). Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene "Send mail, avoid follow-ups. If enough, I'll summarize."
neff@Shasta.STANFORD.EDU (Randy Neff) (05/25/88)
I would like to point out that very complex functional objects are designed primarily with graphics, namely integrated circuits. This is done through a series of different abstractions and hierarchy. Abstractions: Functional blocks Logic gates Transistors Mask rectangles Hierarchy: Cells of cells of cells of mask rectangles In Ada, there is only a single hierarchy mechanism, the package; and only a single abstraction, the programming language code. Our research at Stanford with the language Anna (ANNotataged Ada) is adding an additional abstraction layer, an implementation independent functional specification of a package specification. This is equivalent to a logic diagram of an IC; the logic diagram explains how the chip behaves, but not exactly how it is implemented in transistors or mask rectangles.
daveb@geac.UUCP (David Collier-Brown) (05/26/88)
In article <25135.580491166@mbunix>, munck@MITRE-BEDFORD.ARPA (Bob Munck) writes: | People can "read" | pictures better than words in a row; machines, until recently, couldn't | do anything at all with pictures and could handle only very simple | sequences of words (programming languages). I think it likely that Ada | will be the LAST major one-dimensional programming language. In article <1017@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: | People can read *some* *small* pictures better than they can read text | conveying the same information. But it doesn't seem plausible to me that | a program which would have been say 50k lines of ADA would be easy to | follow as a collection of several thousand pictures. I think you're both right. Details are often best shown in text, general structure in pictures. I'd certainly prefer to walk a call/rendesvous structure in pictoral form than by reading text, and reason about the details by reading code and not pictographs. --dave (horses for courses, perhaps) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | "His Majesty made you a major 350 Steelcase Road, | because he believed you would Markham, Ontario. | know when not to obey his orders"
eachus@mitre-bedford.ARPA (Robert Eachus) (05/26/88)
[In Memorandum. The line eater, may he rest in peace.] In article <2831@Shasta.STANFORD.EDU> neff@Shasta.UUCP (Randall Neff) writes: (Some stuff omitted for brevity) > >In Ada, there is only a single hierarchy mechanism, the package; and only >a single abstraction, the programming language code. > To quote the Ada RM: Packages are one of the four forms of program unit of which programs can be composed. The other forms are subprograms, task units, and generic units. Chapter 7, paragraph 1. All four are heirarchy mechanisms, all four can be used to model abstractions (although each is most appropriate for a different set of abstractions). I'm sure Randall's omission of other hierarchy mechanisms was accidental, but there are many Ada programmers out there who don't seem to realize that generics and tasks can, and often should, be used to create abstact data types, so I couldn't let this just pass by. (Just in case someone decides to pick nits, Ada also has blocks which can be considered as a heirarchy mechanism. But they are in general not used in that way, and should be excluded also based on the sense of Randall's discussion.) Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...