Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!swrinde!mips!prls!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: Modifiability
Message-ID: <35455@athertn.Atherton.COM>
Date: 12 Jun 91 18:10:29 GMT
References: <1991Jun10.174641.8176@netcom.COM> <11714@ncar.ucar.edu> <1991Jun7.165928.1903@weyrich.UUCP> <1849@uqcspe.cs.uq.oz.au> <1991Jun10.122656.18795@zip.eecs.umich.edu>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Distribution: comp.software-eng
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 62

In article <1991Jun10.174641.8176@netcom.COM>, jls@netcom.COM (Jim
Showalter) writes:
>I'd assert, however, that
>more than 95% of a reasonably sized program's code is an attempt at writing
>a non-ambiguous specification. 1/2 :-)

> Excellent point, and a great way to succintly express my dissatisfaction
> with formal specification languages. I have seen such languages work well
> in a restricted domain (e.g. state transition tables), but in the larger
> scheme of things they either wind up too specific for the general case,
> or so general they are no longer concise...

> I think there is a lesson here for anyone who wants to specify systems
> in a formal language--it may well be the case that any time one wants
> to formally specify a system of suitable complexity to be interesting,
> the resulting specification language is itself so complex that it provides
> scant improvement over English or, alternatively, the language of 
> implementation itself. 

The flip way to look at what this might mean to formal language designers
is what Jim pointed out in the first paragraph.  Conciseness and clarity
can be critical to a new language being a significant improvement
over another language.  Scale matters: you can only see so much at
a glance, on a page, or on a monitor.  As you exceed those levels you
quickly overwhelm the user with complexity.  It takes a very clever
designer to create a new representation that is significantly more
compact in physical representation and things needing to be learned,
and yet at the same time which has enough clarity that the symbols
are easily learned, recognized, and understood in context.   There
are only a very few basic prototypical language forms in common use
today: lisp-style derivatives, algol-style derivatives, unix-command
line style derivatives, troff style markup derivatives, spreadsheet
derivatives, 4GLstyle descriptive languages, and a few iconic languages.

Far and away the most common base for new languages is the algol style.
It is not clear that this is as wise a choice as the overwhelming
preference seems to indicate--some of the other forms, or forms not yet
invented or in common use might be much better.  Rather selection of
the algol style language form may be driven by other factors such as
the availability of parsers and compiler-compiler technology for this
form (e.g. lex and yacc) and the high level of familiarity of programmers
with this style (both in day to day use, and in classes on building
compilers from school days).  Familiarity with this form and tools might
argue for its use in terms of quickest implementation, but overlooks
whether this form will be best for the task at hand.

I think this is especially important to consider this because technology has
provided reduced cost display technology with many more "degrees of freedom"
for designers than the old monochrome 80 char wide Ascii only teletypes
for which most of the above forms such as the algol style were developed.
The use of color, alternate fonts, non-character symbols, 2D and 3D spatial
locations, varying line widths, animation, etc. available on todays
monitors offers the potential for design of new languages (both
schematic and textual) which use more of these degrees of freedom to
achieve greater compactness. By and large today's designers have
ineffectually taken advantage of these
new degrees of freedom, but they do offer hope for improvements over past
results.

Scott McGregor
Atherton Technology
mcgregor@atherton.com