Newsgroups: comp.ai,comp.lang.misc,comp.programming,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!pipex!uunet!timbuk.cray.com!driftwood.cray.com!chuckm
From: chuckm@willow129.cray.com (Charles E. Matthews)
Subject: Re: A new approach to software engineering!
Message-ID: <1994Dec23.115040.4648@driftwood.cray.com>
Originator: chuckm@willow129
Lines: 140
Sender: chuckm@willow129 (Charles E. Matthews)
Nntp-Posting-Host: willow129
Organization: Cray Research, Inc.
References: <D0wsx8.6zC@prl.philips.nl> <netnewsD18uuF.Ju1@netcom.com>
Date: 23 Dec 94 11:50:40 CST
Xref: glinda.oz.cs.cmu.edu comp.ai:26056 comp.lang.misc:19723 comp.programming:13640 comp.software-eng:28913


In article <netnewsD18uuF.Ju1@netcom.com>, scottw@advsysres.com (Scott A. Whitmire) writes:
> In <D0wsx8.6zC@prl.philips.nl>, pvloon@prl.philips.nl (Paul van Loon) writes:
> >Domain Specific Formalisms (DSFs)
> >---------------------------------
> >
> >Within Philips Research in Eindhoven we form a group of people that
> >highly believe that for a lot of application domains it is time for 
> >a new approach to software development. We want domain experts
> >to generate software themselves without the need of programming
> >experience. To that end we have developed, and to some extent 
> >have experience with, an approach that is characterised by the
> >following aspects:
    [snip...]

> 
> I wanted to post this publically to spur some discussion.  This is a topic
> that needs some discussion among software professionals.  Tool vendors would
> have us believe that what you describe is possible.  I happen to disagree,
> and for a variety of reasons.
> 
    [snip...]
> 
> Scott A. Whitmire             scottw@advsysres.com

I have to agree with Scott. I have some strong reservations on the feasibility 
of this approach. From a general consideration the goal of allowing 
non-programmers to write computer programs has been attempted by many different 
companies with little success. While I still believe that this is a worthwhile 
goal, I don't think that this particular approach will achieve it. 

The claims made here remind me of the words from IBM marketing people back in
the late 80's regarding ESE. They were claiming that non-programmers could 
use ESE to create expert system applications without knowing anything about
programming. After a few years of this, all of the IBM consultants that I 
know admitted that this claim failed. If the ESE users were not programmers
at the start of their project, then either the project died before its
completion or the users became programmers during the project. The point here
is that no problem solution of a sufficient complexity can be described 
PURELY in a declarative fashion. Problem solutions are a combination of 
data description and some procedural mechanism for processing the data. The
developers of your application must be able to specify both data and the
computational procedures.  

There are some problem domains where this procedural mechanism is relatively
simplistic and therefore can be built into the underlying system, e.g. 
spreadsheets handling standard calculations. Even here, however, the user
needs to specify some procedural rules concerning which data to process and 
how to do it. As the problem domain becomes more complex, the underlying 
system must become more robust. This usually means that it also becomes more
complicated to use. 

(The uppercase sentences in the following paragraphs are taken from the 
original posting on this topic.) 

- FOR EACH APPLICATION DOMAIN, YOU DEVELOP A TAILOR MADE PROGRAMMING LANGUAGE.

I admit that there is value to doing this. You can focus your attention on 
the aspects of the language which are highly pertinent to your problem domain.
The main problem which needs to be handled is this. What happens when you 
begin looking at a new problem within your domain which is very similar to 
existing problems but different enough that it requires a little change to 
your application domain language to handle it? And then the next, and the 
next...

I think that you will find yourself in one of two positions. Either you 
agree up front that your application language will need to evolve continually
in order to satisfy new problem requirements, or you carve out the boundaries
of your problem domain. You identify what kinds of problems you will handle
and what kinds you will not handle. 

- DOMAIN EXPERTS CONCENTRATE ON THE DECLARATIVE DESCRIPTION OF THEIR DOMAIN
  KNOWLEDGE AND DON'T HAVE TO BOTHER WITH ALL KINDS OF IMPLEMENTATION 
  HASSLES. 

I have two problems with this statement. My first contention is that 
complex problem domains cannot be described purely in declarative terms. If
you interpret "the declarative description of their domain knowledge" to 
refer only to the "if-then-else" kinds of pattern matching, then I think that
your approach will fail for most problem domains. I have found that most of
the problem domains in which I have worked are characterized not only by 
declarative based rules (if-then-else pattern type matches) but also by 
procedural based rules which distinguish when and which  declarative based 
rules are important enough to consider. In other words the process driven 
rules need to guide when the declarative rules can be active. If your 
language handles this constraint, then I will remove this objection. 

My second objection comes from my observation that any kind of machine 
interpreted file is at least implicitly tied to some method of processing 
that file. In other words your domain experts can build a knowledge base 
of their domain knowledge ONLY if they have an a priori set of rules which 
define how anyone else (human or machine) will interpret what they have built
and what their intentional meaning was. 

Consider the following:

    (device PERSONAL-COMPUTER
      (requires  ((1,1 power-supply) (0,1 video-card) (0,5 DASD)...))
    )

You could use the above description to say that a PERSONAL-COMPUTER  
requires exactly 1 power supply. It may contain 1 optional video-card. 
It may contain up to 5 DASD drives, but they are not necessarily required 
in all cases. 

This description has meaning only because you have an a priori rule set 
which attaches meaning to the attribute REQUIRES and to the syntax which 
follows. In my mind that rule set contains many of the implementation details
which you claim the user doesn't need to know. I would argue that many of 
those implementation rules are absolutely essential to your ability to attach
meaning to your declaractive problem description. 

For your problem domain language to succeed, either the implementation rules 
which identify how meaning is attached to your data are pre-defined and accepted 
by all of your users implicitly, or you need to build some mechanisms into your 
language to provide this definitional structure. In either case, you cannot 
get away from your implementation considerations.

If this statement is meant only to say that your domain experts don't need to 
worry about how to specify knowledge via the syntax of the underlying 
implementation language (C, LISP, PROLOG, whatever), then that's a different
story. While I agree that it is usually inappropriate to specify data 
knowledge via the syntax of the underlying implementation language, there are
times when the structure of the data knowledge can be designed more 
efficiently if you do know the implementation details.

Well, seeing as how this post is becoming quite long, I'll stop for now. 
Although I agree with your objectives, I think that these problems need to 
be solved before this approach is generally useful. 


Regards,
Chuck Matthews

P.S. My opinions are my own and not those of ...  blah, blah, blah.
-- 
Chuck Matthews
chuckm@sdiv.cray.com                          Cray Research, Inc. 
                                              655F Lone Oak Drive
(612)683-5385                                 Eagan, MN  55121
