munck@MBUNIX.MITRE.ORG (Bob Munck) (03/07/89)
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, MITREchuck@WOOGLIN.SCC.COM (Charles Williams) (03/07/89)
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!!
karl@grebyn.com (Karl Nyberg) (03/07/89)
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 --
eachus@mbunix.mitre.org (Robert Eachus) (03/08/89)
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...
rec@dg.dg.com (Robert Cousins) (03/08/89)
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