A new approach to software engineering! 
Author Message
 A new approach to software engineering!

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:
-- We don't let domain experts use a general purpose language like C,
   Pascal or whatsoever. Per application domain we actually develop a
   tailor made programming language (DSF) -and corresponding (graphical)
   tool- that enables people from the domain to describe their world in
   a form that can be used automatically for further execution without
   the daily involvement of a software expert.
-- The domain experts concentrate on the declarative description of their
   domain knowledge and they don't have to bother on all kinds of
   implementation hassle.
-- We make a clear distinction between the static representation part of
   a domain, describing the abstractions with their interrelations, and
   a dynamic exploitation part, describing specific actions or tasks
   upon the representation part.
-- Reusability of domain knowledge has become possible, by connecting more
   than one task-specific software system to this declarative description.
-- We use compiler technology to implement all of these (one front-end and
   one or more back-ends).
-- We will use all good aspects of modern software programming techniques,
   like object orientation, functional programming, etcetera.

Note that we don't think task-specific, but domain-specific. We believe
that in many applications large parts of the specific tasks can be
automated. Therefore a domain expert is not asked to describe a solution,
but rather the data that is needed to generate a solution!

We would like to get feedback on this DSF approach. Therefore we are
interested in answering questions like:
Who has experience with such an approach? What was that experience? Do
you know any prototypes, or even better operational systems, build with
such an approach? What are (possible) bottlenecks in this approach?
What are relevant names and publications?

Please inform us of everything that might be of value for us. Thank you!

Reactions can be put on the net, but preferably directly mailed to:




Tue, 03 Jun 1997 23:12:44 GMT  
 A new approach to software engineering!

Quote:
>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:
>-- We don't let domain experts use a general purpose language like C,
>   Pascal or whatsoever. Per application domain we actually develop a
>   tailor made programming language (DSF) -and corresponding (graphical)
>   tool- that enables people from the domain to describe their world in
>   a form that can be used automatically for further execution without
>   the daily involvement of a software expert.

And who develops these? Programmers working in C/C++/<choose your own
general purpose language> ??

Quote:
>-- The domain experts concentrate on the declarative description of their
>   domain knowledge and they don't have to bother on all kinds of
>   implementation hassle.

Such as time/space efficiency ??

Quote:
>-- We make a clear distinction between the static representation part of
>   a domain, describing the abstractions with their interrelations, and
>   a dynamic exploitation part, describing specific actions or tasks
>   upon the representation part.
>-- Reusability of domain knowledge has become possible, by connecting more
>   than one task-specific software system to this declarative description.
>-- We use compiler technology to implement all of these (one front-end and
>   one or more back-ends).

How does the "one front-end" handle different approaches to (presumably)
vastly different problem domains?. If the approach is tailored to the problem,
doesn't using one interface to the back-end technology negate many of the
benefits?

Quote:
>-- We will use all good aspects of modern software programming techniques,
>   like object orientation, functional programming, etcetera.
>Note that we don't think task-specific, but domain-specific. We believe
>that in many applications large parts of the specific tasks can be
>automated. Therefore a domain expert is not asked to describe a solution,
>but rather the data that is needed to generate a solution!
>We would like to get feedback on this DSF approach. Therefore we are
>interested in answering questions like:
>Who has experience with such an approach? What was that experience? Do
>you know any prototypes, or even better operational systems, build with
>such an approach? What are (possible) bottlenecks in this approach?
>What are relevant names and publications?
>Please inform us of everything that might be of value for us. Thank you!
>Reactions can be put on the net, but preferably directly mailed to:


--
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    School of Computing,        Curtin University of Technology  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */


Sat, 07 Jun 1997 21:37:36 GMT  
 A new approach to software engineering!

Quote:
>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:
>-- We don't let domain experts use a general purpose language like C,
>   Pascal or whatsoever. Per application domain we actually develop a
>   tailor made programming language (DSF) -and corresponding (graphical)
>   tool- that enables people from the domain to describe their world in
>   a form that can be used automatically for further execution without
>   the daily involvement of a software expert.
>-- The domain experts concentrate on the declarative description of their
>   domain knowledge and they don't have to bother on all kinds of
>   implementation hassle.
>-- We make a clear distinction between the static representation part of
>   a domain, describing the abstractions with their interrelations, and
>   a dynamic exploitation part, describing specific actions or tasks
>   upon the representation part.
>-- Reusability of domain knowledge has become possible, by connecting more
>   than one task-specific software system to this declarative description.
>-- We use compiler technology to implement all of these (one front-end and
>   one or more back-ends).
>-- We will use all good aspects of modern software programming techniques,
>   like object orientation, functional programming, etcetera.

>Note that we don't think task-specific, but domain-specific. We believe
>that in many applications large parts of the specific tasks can be
>automated. Therefore a domain expert is not asked to describe a solution,
>but rather the data that is needed to generate a solution!

>We would like to get feedback on this DSF approach. Therefore we are
>interested in answering questions like:
>Who has experience with such an approach? What was that experience? Do
>you know any prototypes, or even better operational systems, build with
>such an approach? What are (possible) bottlenecks in this approach?
>What are relevant names and publications?

>Please inform us of everything that might be of value for us. Thank you!

>Reactions can be put on the net, but preferably directly mailed to:



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.

First, my experience indicates that once a programmer puts code into the
editor, the hard part of the task is finished.  Just as when the writer begins
to put words on the page (or into the word processor), the hard part of
writing is finished.

In every application I've built over the last 15 years, the programming has
been the easiest, if not the most tedious part, of development.  The hardest
activity is understanding the problem in the first place.  Now, this is a point
where domain experts may have a leg up on the rest of us, but often as not,
they don't have a deep understanding of their domain either.

The next most difficult task is to translate the understanding of a problem
into a rational software architecture, then into a design.

Software design is the most complex endeavor we've ever undertaken.  We are
trying to describe something we can't truly visualize to other people.  One
of the reasons that high-leve CASE tools have not worked as well as they
might is the difficulty we have communicating designs to one another, and to
our tools.

Unskilled designers can do more damage to an application that any number of
unskilled programmers.  End users can make computers do things with good tools
(programming), but they generally cannot make them to those things well, or
sometimes even make them do the right things.

I almost feel that software engineering begins when the user requests a
solution to a problem, and ends when it's time to start cutting source code.
Programming is construction, not engineering.  Deciding WHAT to program,
and HOW to program it, is engineering.

Any comments?


Advanced Systems Research    
25238 127th Avenue SE         tel:(206)631-7868
Kent Washington 98031         fax:(206)630-2238

Consultants in object-oriented development, network-based
applications, and software metrics.



Tue, 10 Jun 1997 11:25:26 GMT  
 A new approach to software engineering!


Quote:

>: First, my experience indicates that once a programmer puts code into the

>    Ah ha! This is the fundamental problem with software development
>today, it is being done by programmers!

Unfortunately, we work in a business where, before you are allowed to
design a house, you have to put in time laying bricks (or, more likely,
repainting or putting new shingles on someone's already existing house).
Promotion in many places means being allowed to supervise the brick layers,
schedule the brick layers (deal with their vacation time, etc.), and
count the number of bricks put down this week.  The interesting thing is
that this is what happens to graduates whose major calls itself a science.

How and when will Software Engineering be true engineering and we can
write blueprints and stop getting metaphorical dirt under our fingernails?

-Scott

--
                      |   |
            __|  _` | __| __|
           (    (   | |   |
          \___|\__,_|\__|\__|



Wed, 11 Jun 1997 01:03:01 GMT  
 A new approach to software engineering!

: I wanted to post this publically to spur some discussion.

        Me too!

: This is a topic that needs some discussion among software professionals.

        Although this topic might be novel to some, it certainly
isn't ground-breaking. Nevertheless, it still has tremendous potential!

: Tool vendors would have us believe that what you describe is possible.
: I happen to disagree, and for a variety of reasons.

        Regardless of what tool vendors want you to believe about
their products, these kinds of tools are indeed possible, and are
being used successfully today. As for two simple examples, for the
most part, are lex and yacc. Domain-specific languages rule :-)

: First, my experience indicates that once a programmer puts code into the

        Ah ha! This is the fundamental problem with software development
today, it is being done by programmers! We don't *want* programmers
writing applications, we want domain-experts (or even not so expert)
doing this. We don't even want programmers writing our domain-specific
tool environments, because we want domain-experts to do that too!

: In every application I've built over the last 15 years, the programming has
: been the easiest, if not the most tedious part, of development.  The hardest
: activity is understanding the problem in the first place.

        And because you didn't have tools to support your domain,
understanding the problem was even that much more difficult.

: Now, this is a point where domain experts may have a leg up on
: the rest of us, but often as not, they don't have a deep understanding
: of their domain either.

        Maybe you shouldn't be calling them *experts* then :-)
Unfortunately, incompetency can be found in any field.

: The next most difficult task is to translate the understanding of a problem
: into a rational software architecture, then into a design.

        Again, because you didn't have tools to support your domain,
translating the problem was even that much more difficult.

: Software design is the most complex endeavor we've ever undertaken.  We are

        More accurately, "Software design using *general-purpose
programming languages* is the most complex endeavor we've ever undertaken".
My feeling is that this is the crux of the entire approach. Using
general-purpose programming languages *will never ever ever* be
used to achieve significant productivity gains (based on historical
evidence that there haven't been any yet :-) and that the *only*
hope the software industry has to improve itself is to adopt some
sort of domain-specific development approach.

        Although all the existing domain-specific tools I've used
in the past supported only a small domain, e.g., specifying languages,
their productivity gains cannot be disputed. The only interesting
question remaining to be answered is how large of a domain can be
supported? Fortunately, I haven't seen any inherent bounds yet.

: I almost feel that software engineering begins when the user requests a
: solution to a problem, and ends when it's time to start cutting source code.

        Bzzz, too late. Software engineering starts when the user
*thinks* they have a problem. Who else is going to them them a solution
already exists?

Eric Marshall
EMI Software Engineering
903 Dunbarton Court
Herndon, {*filter*}ia 22070
(703) 787-0834




Tue, 10 Jun 1997 23:46:05 GMT  
 A new approach to software engineering!


Quote:
> First, my experience indicates that once a programmer puts code into the
> editor, the hard part of the task is finished.  Just as when the writer begins
> to put words on the page (or into the word processor), the hard part of
> writing is finished.

What you say about programming may be true (and in fact I believe it is).
However, I don't think the analogy with writing works. Ask any successful
writer and he'll tell you the ideas and the big picture are easy. It's the
writing that's hard. This may have to do with the fact that writing in a
natural language is more of an art than writing in a computer language.

________________________________________________________________________________

 Where do I want to go today? Anywhere but Chicago.



Wed, 11 Jun 1997 00:51:34 GMT  
 A new approach to software engineering!


Quote:
> First, my experience indicates that once a programmer puts code into the
> editor, the hard part of the task is finished.  Just as when the writer begins
> to put words on the page (or into the word processor), the hard part of
> writing is finished.

> In every application I've built over the last 15 years, the programming has
> been the easiest, if not the most tedious part, of development.  The hardest
> activity is understanding the problem in the first place.  Now, this is a point
> where domain experts may have a leg up on the rest of us, but often as not,
> they don't have a deep understanding of their domain either.

Hear, hear! The key word (in fact, the key concept) is "understanding".
I totally agree. I've written some stuff about these issues:

H.Kilov. Understand -> Specify -> Reuse: Precise specification of
behavior and relationships. In: Proceedings of the IFIP/IEEE
International Workshop on Distributed Systems: Operation and Management
(DSOM ?92). Munich, Germany, October 12-13, 1992.

H.Kilov. On understanding hypertext: are links essential? ACM Software
Engineering Notes, Vol. 19, No. 1 (January 1994), p. 30.

H.Kilov, J.Ross. Information modeling: an object-oriented approach.
Prentice-Hall, 1994.

--and the specification has to be abstract (e.g.,
implementation-independent: requirements should not be based on
solutions) and precise (no handwaving, no defaults, etc.). Developing a
specification is a _very_ difficult activity where a human cannot be
replaced by a CASE tool or by a sequence of 55 steps to write a good
specification...

Hope this helps.

-Haim Kilov



Wed, 11 Jun 1997 01:32:49 GMT  
 A new approach to software engineering!


Quote:

> >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...]

Quote:

> 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...]



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

                                              655F Lone Oak Drive
(612)683-5385                                 Eagan, MN  55121



Tue, 10 Jun 1997 19:50:40 GMT  
 A new approach to software engineering!

Quote:
> From a general consideration the goal of allowing non-programmers to write
> computer programs has been attempted by many different companies with little
> success.

Perhaps in the successful cases the result is no longer considered
programming, or the users no longer considered nonprogrammers?  I'd nominate
spreadsheets in the first instance and fortran in the second.  (Fortran was
originally considered 'automatic programming'.  In a way, it was.)  Maybe
flexible software packages and high-level languages are evolving towards
convergence.

Quote:
> - 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...

Well, what saves us here is Turing completeness, which assures that you
don't need a big complicated language to cover a big complicated domain.
Finding a simple language that covers the domain -well- is what makes
language design interesting, though -- that's bound to always require an
expert designer.

Quote:
> - 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.

I'm not quite sure what you mean here.  It's true that if-then-else rules
have narrow applicability, but the class of declarative languages is a lot
broader.  If you're saying the machine can't supply -all- the smarts, that's
indisputable.

Good special-purpose languages tend to be declarative in flavor probably
just because a lot of knowledge about what to do is built in.  Another
reason is that they're built only when no existing language does the job,
and conventional procedural languages are biased against expressing
declarative thoughts.

Quote:
> 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.
> [...]
> 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.

Are you saying the users have to know the language's syntax and semantics?
That can be a problem if the language is different enough from the domain
formalisms they're used to; even so, it may still be a win compared to, say,
a C++ library.  C++ is pretty gnarly.

- Darius



Wed, 11 Jun 1997 15:08:42 GMT  
 A new approach to software engineering!


Quote:
> Unskilled designers can do more damage to an application that any number of
> unskilled programmers.  End users can make computers do things with good
tools
> (programming), but they generally cannot make them to those things well, or
> sometimes even make them do the right things.
> I almost feel that software engineering begins when the user requests a
> solution to a problem, and ends when it's time to start cutting source code.
> Programming is construction, not engineering.  Deciding WHAT to program,
> and HOW to program it, is engineering.

If I understand your article as a whole, you're saying that software design
is too hard for amateurs, and that domain-specific languages can't help
because they only address coding, the trivial, mechanical part of the job.
I partly agree with the first point but strongly disagree with the second.
The "coding is trivial" viewpoint recalls David Gries's maxim "Don't program
-in- a language, program -into- it."  There's much to be said for that, but
it's not the last word; another approach is, "Program in the -right-
language."  In other words, program using a set of abstractions appropriate
to the domain; if those abstractions aren't already implemented, implement
them.  This is a good idea in at least two situations: where no available
general-purpose language can express the right abstractions directly, and
where one can, but it's too complicated or unfamiliar for the intended
audience.

Are amateurs bad at software design?  Yes, indeed.  I think the point is,
though, that the sort of problems they solve by themselves with a spread-
sheet, that we now consider simple, once would have needed 'real'
programming -- if they'd have bothered to use a computer at all.  We
ought to be looking for ways to continue that trend.


Quote:
>         Ah ha! This is the fundamental problem with software development
> today, it is being done by programmers! We don't *want* programmers
> writing applications, we want domain-experts (or even not so expert)
> doing this. We don't even want programmers writing our domain-specific
> tool environments, because we want domain-experts to do that too!

I think you're going overboard here.  A good mathematician who's not a
programmer could not have designed Mathematica (in detail), much less
implemented it efficiently, because you need to know both what would be
useful and what's implementable, to find the right way to connect the two;
and because you need experience designing languages.  Language design is
-hard-.  On the other hand, specialties often evolve useful formalisms that
it would be foolish to ignore.  Also, we may not have to ask domain experts
to design a whole language; in many cases they can just extend a base
language like Scheme.  It isn't completely ridiculous...

Quote:
>         More accurately, "Software design using *general-purpose
> programming languages* is the most complex endeavor we've ever undertaken".
> My feeling is that this is the crux of the entire approach. Using
> general-purpose programming languages *will never ever ever* be
> used to achieve significant productivity gains (based on historical
> evidence that there haven't been any yet :-)

I'd be surprised if Scheme and ML programmers aren't much more
productive than Fortran and Algol programmers.  Nevertheless, because
there's no limit to the things we want done, and because the easy parts
almost by definition can be automated, programming is inherently hard.

Quote:
> and that the *only*
> hope the software industry has to improve itself is to adopt some
> sort of domain-specific development approach.

There are lots of possible ways forward, though I agree that that's a very
promising one.  Some others are formal methods (partial evaluation, semi-
automatic transformation of specifications into code), programmer's
apprentices, fancier development environments & tools, machine learning
(genetic algorithms, neural nets, etc.), programming by demonstration,
"design patterns" (whatever they are; I've never read a clear explanation),
and new architectures like agoric software.  There's also the chance of
changing the sorts of programs we write: fewer mega-apps, more tools that
work together.

Most of the above are attempts to make the machines smarter; trying to make
people smarter is another possibility.

Quote:

> --and the specification has to be abstract (e.g.,
> implementation-independent: requirements should not be based on
> solutions) and precise (no handwaving, no defaults, etc.). Developing a
> specification is a _very_ difficult activity where a human cannot be
> replaced by a CASE tool or by a sequence of 55 steps to write a good
> specification...

No argument here, but the proposal wasn't to -replace- humans, but to help
them.  You wouldn't argue this way against using a high-level language
instead of assembly language.  The first HLLs embodied a useful subset of
the deep magic mastered by the wizards and put it at the disposal of the
merely capable.  Programming languages can embody programming knowledge:
garbage collection embodies knowledge of memory management, for instance,
freeing the programmer from most of the thought that would have to go into
that aspect of the specification.  So, will focusing on one problem domain
give us the chance to automate away a lot of the programmer's job?  Enough
to make it usable to nonprogrammer experts?  I recommend Jon Bentley's
"Little Languages" column in _More Programming Pearls_ to anyone who thinks
the answer is no.  Also "A Survey of Surveys" in the same book.

Of course, trying to automate unrestricted programming amounts to true AI.
Might there be a fruitful way to restrict what we're automating, other than
by problem domain?

- Darius



Wed, 11 Jun 1997 12:21:00 GMT  
 A new approach to software engineering!


[snip - original post]

: First, my experience indicates that once a programmer puts code into the
: editor, the hard part of the task is finished.  Just as when the writer begins
: to put words on the page (or into the word processor), the hard part of
: writing is finished.

: In every application I've built over the last 15 years, the programming has
: been the easiest, if not the most tedious part, of development.  The hardest
: activity is understanding the problem in the first place.  Now, this is a point
: where domain experts may have a leg up on the rest of us, but often as not,
: they don't have a deep understanding of their domain either.

Moreover, it would be a big surprise if they were any better at
choosing, organizing and expressing the right functions,
entities and behaviours to describe formally in the first place.

[snip - more very reasonable response]
: The next most difficult task is to translate the understanding of a problem
: into a rational software architecture, then into a design.

: Software design is the most complex endeavor we've ever undertaken.  We are
: trying to describe something we can't truly visualize to other people.  One
: of the reasons that high-leve CASE tools have not worked as well as they
: might is the difficulty we have communicating designs to one another, and to
: our tools.

: Unskilled designers can do more damage to an application that any number of
: unskilled programmers.  End users can make computers do things with good tools
: (programming), but they generally cannot make them to those things well, or
: sometimes even make them do the right things.

: I almost feel that software engineering begins when the user requests a
: solution to a problem, and ends when it's time to start cutting source code.
: Programming is construction, not engineering.  Deciding WHAT to program,
: and HOW to program it, is engineering.

: Any comments?

I think verification and validation play a larger role and are a key part
of the front end activities. Otherwise, I agree.

David Jaffe

--
David Jaffe



Thu, 12 Jun 1997 01:03:46 GMT  
 A new approach to software engineering!

Quote:

>> From a general consideration the goal of allowing non-programmers to write
>> computer programs has been attempted by many different companies with little
>> success.

>Perhaps in the successful cases the result is no longer considered
>programming, or the users no longer considered nonprogrammers?  I'd nominate
>spreadsheets in the first instance and Fortran in the second.  (Fortran was
>originally considered 'automatic programming'.  In a way, it was.)  Maybe
>flexible software packages and high-level languages are evolving towards
>convergence.

It has been said that the most popular programming language in existance today
is the macro language for Lotus 1-2-3.  By definition, even entering formulas
into a spreadsheet is programming.  Several companies have put their spreadsheets
under configuration control because the domain experts were getting the formulas
wrong, and making decisions on bad data.

Programming is programming, whether the langauge is declarative, procedural, or
object-oriented (which is a lot of both).

I didn't say this exactly, but the most important skill for a software engineer
is problem solving...the kind of skills that make story problems in calculus and
physics so much fun.

One other thing to consider.  Is it the best use of a physicist's time for them
to be writing applications, in any language?

Quote:

>> - 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...

That, and you'd need to learn a new language for every new domain.  It's tough
enough to learn the semantics and idioms of new domains as it is...

Quote:

>Good special-purpose languages tend to be declarative in flavor probably
>just because a lot of knowledge about what to do is built in.  Another
>reason is that they're built only when no existing language does the job,
>and conventional procedural languages are biased against expressing
>declarative thoughts.

Mostly, special-purpose languages tend to be declarative because declarative
languages are easier to write.  The translator (compiler or interpreter)
is doing little more than filling in variable values, not creating machine
instructions.

By the way, this is the most intelligent discussion I've seen in this group.
Congratulations.


Advanced Systems Research    
25238 127th Avenue SE         tel:(206)631-7868
Kent Washington 98031         fax:(206)630-2238

Consultants in object-oriented development, network-based
applications, and software metrics.



Thu, 12 Jun 1997 08:58:27 GMT  
 A new approach to software engineering!

Quote:


writes:
> [snip - original post]
> : First, my experience indicates that once a programmer puts code into
the
> : editor, the hard part of the task is finished.  Just as when the
writer begins
> : to put words on the page (or into the word processor), the hard part
of
> : writing is finished.
> : In every application I've built over the last 15 years, the
programming has
> : been the easiest, if not the most tedious part, of development.  The
hardest
> : activity is understanding the problem in the first place.  Now, this
is a point
> : where domain experts may have a leg up on the rest of us, but often as
not,
> : they don't have a deep understanding of their domain either.
> Moreover, it would be a big surprise if they were any better at
> choosing, organizing and expressing the right functions,
> entities and behaviours to describe formally in the first place.
> [snip - more very reasonable response]
> : The next most difficult task is to translate the understanding of a
problem
> : into a rational software architecture, then into a design.
> : Software design is the most complex endeavor we've ever undertaken.  
We are
> : trying to describe something we can't truly visualize to other people.
 One
> : of the reasons that high-leve CASE tools have not worked as well as
they
> : might is the difficulty we have communicating designs to one another,
and to
> : our tools.
> : Unskilled designers can do more damage to an application that any
number of
> : unskilled programmers.  End users can make computers do things with
good tools
> : (programming), but they generally cannot make them to those things
well, or
> : sometimes even make them do the right things.
> : I almost feel that software engineering begins when the user requests
a
> : solution to a problem, and ends when it's time to start cutting source
code.
> : Programming is construction, not engineering.  Deciding WHAT to
program,
> : and HOW to program it, is engineering.
> : Any comments?

You raise an important point. It brings to mind several aphorisms, like,
"Begin with the end in mind", "Don't just work hard-- work smart", "The
questions are more important than the answers", and the like. One must be
able to continually "exit the system", to quote Godel Escher Bach, and ask
whether or not this is the best approach to the problem-- or more
importantly, to ask continually, what is the problem to be solved? There
are precious few who are in the habit of questioning the underlying
assumptions of their training and their specialty and their peers. We need
more lone wolves, and fewer sheep, to use a crude metaphor.

With regard to AI, this also is doubly true: the intelligent software that
we design is constrained, domained, limited, by the way we set it up. To
generate software that is truly flexible, and able to respond creatively
to new situations, in unpredictable environments-- that can draw
analogies, and engage in inductive reasoning-- whew, what a challenge! But
I believe that these things are possible, given a willingness to start
from scratch with regard to approaches to the problem. Is it not so?



Fri, 13 Jun 1997 13:16:09 GMT  
 A new approach to software engineering!
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.

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 ump{*filter*} stovepipe systems, each written in their
domain-specific language, and what happens when I try to integrate across
domains??

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??

My ten cents worth.

Dagmar Anne Bogan

Kopania & Komorovski       Data Architecture &
Richardson, TX  75081      Performance Engineering



Sat, 14 Jun 1997 08:57:32 GMT  
 A new approach to software engineering!

Quote:
>One other thing to consider.  Is it the best use of a physicist's time for them
>to be writing applications, in any language?

Yes, it is.  At least, it can be if it is easy enough to write
applications.  Otherwise, the physicist spends all his time trying
to tell the programmer what he wants.  If programming were easy,
the end-user could just do it.  That is why sytems like Mathematica
are popular among physicists.

Ralph Johnson -- University of Illinois at Urbana-Champaign



Sat, 14 Jun 1997 10:46:55 GMT  
 
 [ 35 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. SOFTWARE ENGINEERS (NEW PRODUCT APPLICATIONS)

2. +1 Software Engineering's New Web Site

3. **Safety-Critical Software Engineering in Ada** (New Course)

4. Software Engineering position with hot new start-up!

5. +1 Software Engineering's New Web Site

6. JOB OPPORTUNITIES - Embedded Software Engineers & Systems Engineers

7. Job-Vermont-Software Reuse Team - Software Engineer

8. Deadline Approaching: ICSE 2000 Workshop on Software Product Lines

9. M2: A software development approach

10. Deadline Approaching: ICSE 2000 Workshop on Software Product Lines

11. Linguistic approaches to AI Linguistic Approaches to Artificial Intelligence

12. Linguistic approaches to AI Linguistic Approaches to Artificial Intelligence

 

 
Powered by phpBB® Forum Software