Hypertext Ada

Hypertext Ada

[Bob Munck]

  The discussion of Knuth's WEB system has pushed one of my "hot
buttons:"  the way we continue to burden ourselves with the requirements
of physical/non-computer-based media when those forms are long obsolete. 
For example, I'll bet that 90% of Ada programs would fit comfortably on
80-column IBM cards.  The legacy of cards and keypunches has been
preserved in the 80x25 screen.

  When I'm writing Ada code, I'm talking to two audiences: first the Ada
compiler and second programmers yet unborn who will maintain and upgrade
my code.  (Priorities should be reversed.)  The two audiences are very
different.  (The struggle to higher-level languages is driven by this,
in that it is an attempt to make the two audiences closer to each
other.)  I personally find it a real pain to be restricted to the forms
and media of the compiler when I'm trying to say something to the
people.  For example, quite often a picture or two would be very useful,
but after a few minutes of trying to line up "-----"s and "|"s on lines
starting with "--"s, I give up and write some less communicative text.

  At other times, I want to refer to something elsewhere in my text. 
We have the technology to allow me to do so with an icon or
special-character "button" that the reader can mouse-click on.  Instead,
I'm forced to type a long qualified name that the reader can use to
trace through my structure to the place referenced.  A pain for both of
us.  I certainly want to use italics, boldface, different fonts and font
sizes, and full proportional spacing in my documentation.

  It occurs to me that what I'm proposing here is a candidate for
consideration by the Ada 9X group.  I don't want to change the language,
but rather the data format that it is embedded within.  I want a
"multi-media hypertext" Ada with desktop-publishing capabilities like
"Mac Draw" pictures, scanner input, color, multiple fonts, orientations,
etc.  Also, and more ambitious, the idea that Ada code is _always_ read
on and with the help of an interactive tool that can travel around a
hypertext, maybe something like HyperCard.  The problem of separating
and keeping clear what the compiler deals with is not difficult, but
certainly can be a bit more sophisticated than leading "--"s.

  This means we have to raise our sights above the VT-100 as our
lowest-level programmer support, but not that much above.  A Mac or a PC
with EGA display should do fine, and cost less than 1% of the yearly cost
of its user.  The 9X people will have to struggle with "external form,"
graphics, windowing standards, and other bothersome subjects, but the
technology is all available; it's just a matter of making choices. 
While I'm against the 9X effort in general because of the political
dangers of changing the language, this wouldn't bother me because it
isn't really changing the language, but its storage medium.

  Comments?  Opinions?  Funding?
                                 -- Bob Munck, MITRE

Re: Hypertext Ada

[Robert Eachus]

In article <24216.605219947@mbunix> munck@mitre.org writes:
(Among other good ideas:)

>I'm forced to type a long qualified name that the reader can use to
>trace through my structure to the place referenced.  A pain for both of
>us.  I certainly want to use italics, boldface, different fonts and font
>sizes, and full proportional spacing in my documentation.

     This is one I'll not only second, but fight for.  Let's extend
the Ada syntax to list the standard ANSI (or ISO) control sequences,
at a minimum those begining with ESC-[, as legal any place where an
extra separator is permitted.  Italics, bold, color, and font should
be ignored when matching identifiers just as capitalization is.

>It occurs to me that what I'm proposing here is a candidate for
>consideration by the Ada 9X group.  I don't want to change the
>language, but rather the data format that it is embedded within.  I
>want a "multi-media hypertext" Ada with desktop-publishing
>capabilities like "Mac Draw" pictures, scanner input, color, multiple
>fonts, orientations, etc.  Also, and more ambitious, the idea that
>Ada code is _always_ read on and with the help of an interactive tool
>that can travel around a hypertext, maybe something like HyperCard.
>The problem of separating and keeping clear what the compiler deals
>with is not difficult, but certainly can be a bit more sophisticated
>than leading "--"s.

     This is general is harder than the above, but still worth the
effort. What we need is a standard for storage and display of Ada
source text that allows embedded pointers, either within the source,
or to supporting documentation.  The original idea was that such tools
should be part of an APSE, and DIANA was to be used as a
representation.  The stuff that Dave and Chris are doing on EASE is a
start on this, but you are asking for not only EASE, but the ability
to embed hypertext in the DIANA.  Sounds ambitious, but if we are
asking for embedded formatting notations above, why not also ask for
embedded annotations?

> This means we have to raise our sights above the VT-100 as our
>lowest-level programmer support, but not that much above.  A Mac or a
>PC with EGA display should do fine, and cost less than 1% of the
>yearly cost of its user.  The 9X people will have to struggle with
>"external form," graphics, windowing standards, and other bothersome
>subjects, but the technology is all available; it's just a matter of
>making choices.  While I'm against the 9X effort in general because
>of the political dangers of changing the language, this wouldn't
>bother me because it isn't really changing the language, but its
>storage medium.

     An Amiga will do just fine, too.  But I think you take the wrong
approach in talking about the low cost of minimal tools.  If a company
is not willing to spend $10000 or more per software engineer on tools,
has an intolerable level of turnover.  The problem is at the companies
where most of the money still goes into the dinosaurs in the machine
room, not onto users desks.

> -- Bob Munck, MITRE

					Robert I. Eachus

with STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Hypertext Ada

[Charles Williams]

In reply to Bob Munck's thoughts on Hypertext Ada, it appears to me that what
Mr. Munck wants is a *smart* Ada editor that allows you to find references of
anything in the compilation unit with or without full dot notation (with a few
other niceties that I'll address later.)

He is also right when he says that the technology is available today, but it
involves not only setting our sights above a vt-100, but also setting our
sights above a PC and even a VAX. What Mr. Munck really wants is a Rational!!!

Before everybody jumps on my back and starts screaming about the price of the
system, I contend that if you all opened your eyes and looked at the entire
life cycle costs for a large (on the order of 100K's of SLOC) project that
used a VAX (or something similar) versus a Rational, you would see that the
Rational has much lower life cycle costs and many more benifits.

As far as pictures and other graphic notation goes, what is really needed is
the ability to integrate graphic design tools such as IDE and Cadre with the
Ada environment that one is using. This integration should ultimately give the
user the ability to select a piece of an Ada compilation unit, execute a 
command (via mouse or key binding, etc.) and be able to view the graphic or
icon that corresponds to the selected fragment. What is needed for this is
also much more than a vt-100!! This requires some kind of bit-mapped workstation
(i.e. Mac's, Sun's, etc.).

As far as the Ada 9X effort goes, I don't think that media storage requests
have anything to do with the Ada language. If you want to see something like
Hypertext Ada, you should try and find a vendor who would develop it. The Ada
9X effort is to revise the Ada Language Reference Manual, and to my knowledge
the Ada LRM says nothing about how Ada source code has to be stored.

Chuck Williams
Contel Federal Systems

Disclaimer: I do not work for Rational, nor do I receive any compensation from
	    them but, I am Chairman of the Rational Users' Group!!

Hypertext Ada

[Karl Nyberg]

I think we would do well to differentiate between the HARDWARE and the
SOFTWARE needed to support the kinds of development activites that Bob &
Chuck are "discussing".  It does no good to have fancy graphics hardware if
there is no useful graphics software, or if the back end processor is
incapable of meeting the requirements of supporting the development process
in "real time" (with apologies to all those of you who think of something
different when you say that).

It's also worth considering the overall cost/benefit tradeoffs, not just for
a single project, but for an entire organization.  I think that one of the
major benefits of the PC revolution was that it put the computing power in
the hands of the users.  Moving back to a multiuser environment (be it a
Rational or VAX, or multiuser 80X86 machine, or whatever) may be a step
backward.  It may be more cost and productivity effective to pursue an
alternative that spreads the computing power (even with the need for
distributed source configuration control, etc.).  Everybody speculates, but
part of the marketing is to keep you somewhat uninformed, so you buy out of
FEAR, UNCERTAINTY, and DOUBT...

And then, how many 100K SLOC projects have YOU worked on lately?

-- Karl --

Re: Hypertext Ada

[Robert Cousins]

In article <8903071423.AA24284@grebyn.com> karl@grebyn.com (Karl Nyberg) writes:
>I think we would do well to differentiate between the HARDWARE and the
>SOFTWARE needed to support the kinds of development activites that Bob &
>Chuck are "discussing".  [Deleted Stuff] 
>I think that one of the
>major benefits of the PC revolution was that it put the computing power in
>the hands of the users.  Moving back to a multiuser environment (be it a
>Rational or VAX, or multiuser 80X86 machine, or whatever) may be a step
>backward.  It may be more cost and productivity effective to pursue an
>alternative that spreads the computing power (even with the need for
>distributed source configuration control, etc.).   [Deleted Stuff]
>
>-- Karl --

I totally agree.  One of the major reasons why people have been slow to
adopt this approach has been the relatively high cost of machines with
sufficient power to drive a REAL development environment.  I managed the
DG AViiON workstation project and was thinking about this very issue 
from the start.  In my personal view, it makes little or no sense to have
a highly skilled (and therefore quite expensive) developer being limited
by the platform on which he/she develops.  It seems that the bare minimum
is 10 to 15 MIPS per user.  [Obviously more is nicer.]  

I invite comment on this.

Robert Cousins