Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!jls
From: jls@netcom.COM (Jim Showalter)
Newsgroups: comp.software-eng
Subject: Re: Modifiability
Message-ID: <1991Jun10.174641.8176@netcom.COM>
Date: 10 Jun 91 17:46:41 GMT
References: <11714@ncar.ucar.edu> <1991Jun7.165928.1903@weyrich.UUCP> <1849@uqcspe.cs.uq.oz.au> <1991Jun10.122656.18795@zip.eecs.umich.edu>
Distribution: comp.software-eng
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 48

>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 am reminded of a time when a former employer was considering changing
its method of implementing document generators from writing programs in
Ada to using a textual grammar to write "meta-documents" that would then
be compiled to Ada code via a translator. On the surface this new method
had a lot of appeal--it would eliminate the need to write Ada code just
to generate documents, it seemed like it would be an easier language to
learn because it was specialized to document generation, it was closer
to the end product (documentation) so it seemed like a more natural
mapping between the problem space and the solution space, etc etc etc.
On closer investigation, however, the scheme broke down: we kept finding
places where we would need to add more complexity to the specification
language in order to handle this or that case that had arisen in the 
course of generating documents, until the resulting grammar was nearly
as complex as Ada itself but WITHOUT a base of commercially available
parsers, formatters, editors, compilers, debuggers, etc. Yes, we considered
the hybrid strategy of providing a general grammer for 80% of the cases
with an escape-to-Ada mechanism for the trickier cases, but we realized
that this made nobody particularly happy--now the implementor was faced
with mastering TWO programming languages, plus which the onus of providing
a means of communication among the various Ada-escapes was placed on
the implementor (how, for example, do you hand global state back and
forth between separated invocations of individual Ada programs?...). In
the end, we concluded that the initial appeal of "simplicity" for the
textual strategy didn't hold up under analysis, and that sticking with
pure Ada implementation was the superior strategy.

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. (There are certainly development groups I'm aware
of that use Ada as their specification and implementation language.)
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *