Newsgroups: comp.lang.misc,comp.programming,comp.software-eng,comp.ai,comp.ai.philosophy,alt.consciousness
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!news.sprintlink.net!news.tyrell.net!tyrell.net!jcs
From: jcs@tyrell.net (John Stauffer)
Subject: Re: A new approach to software engineering!
Message-ID: <D1H1pF.CCn@tyrell.net>
Followup-To: comp.lang.misc,comp.programming,comp.software-eng,comp.ai,comp.ai.philosophy,alt.consciousness
Sender: usenet@tyrell.net (*)
Nntp-Posting-Host: tyrell.net
Organization: Tyrell Corporation - 800-TYRELL-1 - POP's in 504/816/913/316
X-Newsreader: TIN [version 1.2 PL2]
References: <3dljip$7vq@news.worldlink.com> <3dnops$n85@news2.delphi.com>
Date: Tue, 27 Dec 1994 13:34:27 GMT
Lines: 78
Xref: glinda.oz.cs.cmu.edu comp.lang.misc:19750 comp.programming:13681 comp.software-eng:28983 comp.ai:26107 comp.ai.philosophy:24095

DAGMARA@DELPHI.COM (DAGMARA@news.delphi.com) wrote:
: Is this truly a "new approach"?  I seem to vaguely remember the same 
: ideas of the end-user creating their own software tools back in the early 
: 80s with the advent of Lotus and dBase, and later in the 90s with 
: rule-based expert systems.

I agree that this is not a completely new approach, but I do think that it
has been proven to work in the past.  I have spent the past two years
writing CAE software for an engineering company.  From talking to those
that have been around for a while, the general approach that is used to
solve complex problems is to create a problem-oriented language that allows
the engineer to express the problem in a manner that is understandable by
the computer, which can then perform its analysis and present the solution.

Some examples:

1.  My supervisor previously wrote a structural design package for
    analyzing load cases and designing beams and connections.  The user
    interface was a command interpreter, which could be used either
    interactively or with a data file.  The interpreter accepted commands
    that described the load cases that would be required of the structure.
    When they decided to add automatic steel detailing and shop drawing
    generation, a development language was created that described the
    elements in an engineering drawing.  This new problem-oriented language
    was used by the developers to aid in the development of this new
    capability.

2.  The project that I am currently working on basically entails the
    creation of an object-oriented language for modeling engineering
    elements.  Engineers can interact with this language to express
    their designs instead of using paper and pencil along with several CAD
    iterations.  This application incorporates a GUI interface and a
    three-dimensional model of the system being designed, but the user is
    essentially using this interface to execute "commands" which describe 
    their design.


I am beginning to feel that all application development is really language
development, at some level or another, with the actions that a user can
take being the language's syntactic elements.  It is important for software
developers to be aware of this and to design languages that are
symantically consistent and allow users to express themselves effectively.

: My attitude is: let domain experts do what they do best in their domain, 
: and allow me to do what I do best, by figuring out how to provicde them 
: with appropriate applications.

: What I envision are umpteen stovepipe systems, each written in their 
: domain-specific language, and what happens when I try to integrate across 
: domains??

The language paradigm only applies to the input of data and places no
constraints on how that data is used or stored after it has been entered.
The information could be processed and then placed in some centralized RDBMS
if application integration is important; or write another problem oriented
language transforms the data from the disparate applications into some
common data format.

: I recently had a similar discussion with a collegue of mine who chastised 
: me by telling me that end-users can be educated to do more of their own 
: programming, and my response is "why should an end-user (or domain 
: expert) be required to learn how to program?"  Is it fair to expect users 
: to be domain experts AND programmers/software engineers??

End-users can be enabled to provide more of their own computer solutions.
The solution, however is _not_ with visual tools or GUI builders, but by
providing them with domain specific "languages" that provide an intuitive
mapping to their domain.  End-users are more often capable than programmers
at formulating their solutions, but they will still need programmers around
to create environments that remove barriers such as memory management, user
interface, data integrity, data modeling, etc.

--
=============================================================================
 John Stauffer				EMail:	jcs@tyrell.net
 Black & Veatch				Phone:	(913)339-3805
 					FAX:	(913)339-3511
=============================================================================
