Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Alexandre E. Kopilovitch]

"Robert I. Eachus" <rieachus@attbi.com> wrote:
>I think my first deep insight into the implications of Ada programming 
>came in 1983, just after Ada 83 became an ANSI standard.  I told someone 
>working on our (Ada) compiler: "No, in Ada you model the problem space, 
>not the solution space."  I then excused myself for a minute to write it 
>on my office whiteboard.

I wish that statement will be placed on all major Ada sites, in boldface and
at the top of their homepages.
  But that truth should be also considered from the opposite direction:
if you (your team) can't deal efficiently with problem space for any reason
(most often because you either aren't familiar with the problem area or simply
it isn't clear what is problem at all in the case) then you should not expect
better perfomance using Ada. Moreover, probably a language, which is used
frequently for similar applications is a better choice in such a situation,
because there are chances that some constructs of the language will lead you
to sufficient solutions, and at least you may find (and recognize!) suitable
examples.
  In my view that explains why Ada is (and will be) used relatively rarely:
because the situations where either problem space is too vaguely defined or
programmers are insufficiently familiar with the problem area constitute vast
majority of overall software development.
  Certainly, in military and safety-critical applications the problem space
usually is well-defined and programmers are familiar with the problem area
(either by experience or by special training). So these application types
are natural targets for Ada.

>So almost every Ada advocate will tell you that this language or that 
>language is better for this particular purpose.  What we agree strongly 
>on is that when "programming in the large" the only language to consider 
>is Ada, even if most of the low-level modules are written in C, Fortran, 
>or whatever.

That "programming in the large" is another example of an application type
where problem space usually is well-defined and programmers involved are
familiar with the problem area.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Mário Amado Alves]

> >... I told someone 
> >working on our (Ada) compiler: "No, in Ada you model the problem space, 
> >not the solution space."  I then excused myself for a minute to write it 
> >on my office whiteboard. (Robert)
> 
> I wish that statement will be placed on all major Ada sites, in boldface and
> at the top of their homepages. (Alexandre)

Astonishingly convergent independent statement: "the rich type system
of Ada lets the problem express itself as source code" (my paper on
Ada-Europe 2003).

I understand Alexandre's point about many problems not being defined
enough, but I submit *the* problem is right there: many authors will
tell you that the definition of the problem is an *essential* prior
step in the path for a solution. In artificial intelligence this is an
absolute tenet (cf. e.g. Russel & Norvig 2003 AIMO 2nd ed). I wish it
was so in software engineering also, and my (and surely Robert's)
point is that the use of Ada promotes that.

Cheers,
--MAA

Re: Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Simon Wright]

maa@liacc.up.pt (M�rio Amado Alves) writes:

> > >... I told someone working on our (Ada) compiler: "No, in Ada you
> > >model the problem space, not the solution space."  I then excused
> > >myself for a minute to write it on my office whiteboard. (Robert)
> > 
> > I wish that statement will be placed on all major Ada sites, in
> > boldface and at the top of their homepages. (Alexandre)
> 
> Astonishingly convergent independent statement: "the rich type
> system of Ada lets the problem express itself as source code" (my
> paper on Ada-Europe 2003).

Can't help feeling that a problem that can be explained by source code
is going to be on the small side. And I don't fancy using source code
to back up my design to customers.

On the other hand, I remember a colleague who claimed that his VDM
spec was an excellent foundation for a customer review when annotated
with English!

Re: Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Stephen Leake]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> writes:

> "Robert I. Eachus" <rieachus@attbi.com> wrote:
> >I think my first deep insight into the implications of Ada programming 
> >came in 1983, just after Ada 83 became an ANSI standard.  I told someone 
> >working on our (Ada) compiler: "No, in Ada you model the problem space, 
> >not the solution space."  I then excused myself for a minute to write it 
> >on my office whiteboard.
> 
> I wish that statement will be placed on all major Ada sites, in boldface and
> at the top of their homepages.

I agree it's a good concept.

But push it to the extreme, and people will say we should be
programming in UML, not Ada. 

Even in C++ and C, I can program in the problem space. It's not as
easy, but I can do it.

>   But that truth should be also considered from the opposite
> direction: if you (your team) can't deal efficiently with problem
> space for any reason (most often because you either aren't familiar
> with the problem area or simply it isn't clear what is problem at
> all in the case) then you should not expect better perfomance using
> Ada. 

True.

> Moreover, probably a language, which is used frequently for similar
> applications is a better choice in such a situation, because there
> are chances that some constructs of the language will lead you to
> sufficient solutions, and at least you may find (and recognize!)
> suitable examples. 

Libraries and example code I'll give you. Language won't matter that
much. Of course, it really depends on the domain.

> In my view that explains why Ada is (and will be) used relatively
> rarely: because the situations where either problem space is too
> vaguely defined or programmers are insufficiently familiar with the
> problem area constitute vast majority of overall software
> development. 

Does that mean UML is equally doomed? The market seems to think not.

-- 
-- Stephe

Re: Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Chad R. Meiners]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:u3cjk81gg.fsf@nasa.gov...
> But push it to the extreme, and people will say we should be
> programming in UML, not Ada.

But that is a foolish argument since UML is not well defined.

Re: Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Stephen Leake]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> news:u3cjk81gg.fsf@nasa.gov...
> > But push it to the extreme, and people will say we should be
> > programming in UML, not Ada.
> 
> But that is a foolish argument since UML is not well defined.

I agree, but unfortunately, most people don't see "well defined" as an
important feature of a language. Look at Perl, UML, Java class
libraries for example.

-- 
-- Stephe

Re: Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Simon Wright]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> news:u3cjk81gg.fsf@nasa.gov...
> > But push it to the extreme, and people will say we should be
> > programming in UML, not Ada.
> 
> But that is a foolish argument since UML is not well defined.

There is nothing to prevent definition of a subset ('profile') that is
rigorously-enough defined to be translated. You can do that with a
small core of UML. For example, http://www.projtech.com/

Re: Problem space (Re: Using Ada for device drivers? (Was: the Ada mandate...))

[Chad R. Meiners]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7v8ytav9mx.fsf@smaug.pushface.org...
> There is nothing to prevent definition of a subset ('profile') that is
> rigorously-enough defined to be translated. You can do that with a
> small core of UML. For example, http://www.projtech.com/

True, but mileage will vary in accordance to which subset you choose ;)

Re: Problem space (Re: Using Ada for device drivers? (Was: the Adamandate...))

[Craig Carey]

On Mon, 12 May 2003 05:31:30 +0400 (MSD), "Alexandre E. Kopilovitch"
  <aek@vib.usr.pu.ru> wrote:

>"Robert I. Eachus" <rieachus@attbi.com> wrote:
...
>
>Alexander Kopilovitch                      aek@vib.usr.pu.ru
>Saint-Petersburg
>Russia

Hi Mr Kopilovitch. 

My Usenet client has displayed this message you sent, i.e. the first in
the thread, into an entirely new thread. The headers of the message
lack sufficient information to allow success to any client.

Just to have a bat at why Mr Kopilovitch's last message was incorrectly
threaded, I offer this hypothesis:

[1] A DOS Usenet client run under Wine is too dumb and old to allow
    messages to be sent (but it can receive them). I won't offer a
    details about the DOS Usenet client.
    A detail is that the http://www.rfc1149.net/ gateway system is
    resulting in fragmented threads and it is not a result of an
    evasion of censoring.

I quote from Mr Kopilovitch's first message; and I ask readers to swap
the words: "the problem area"; with the words "the newer Usenet client".
Here is the text now under consideration:

--------------
At Mon, 12 May 2003 05:31:30 +0400 (MSD), Alexandre E. Kopilovitch wrote:

   Subject: Problem space (Re: Using Ada for device drivers? (Was: the
    Ada mandate...))

>  But that truth should be also considered from the opposite direction:
>if you (your team) can't deal efficiently with problem space for any reason
>(most often because you either aren't familiar with the problem area
>[the newer Usenet client] ...) then you should not expect better
>perfomance using Ada.
--------------

That is implausible. Indeed it was true in a wide sense, then Ada 95 Code
optimizers that are not familiar with the larger picture, would not be
able to optimize Ada unoptimized Ada assembly code. It is the case that
the idea, "you or your group", can't be expanded to so that it includes
software implementing artificial intelligence (AI) of maybe any sort. Yet
the first author maintains Ada bindings to Prolog:

At 2002\09\04 01:21 +0400 Wednesday, Alexandre E. Kopilovitch wrote to
   Team-Ada (http://www.acm.org/archives/team-ada.html ):
>New release (0.2) of TAP (Thick Ada-Prolog) bindings replaced previous one
> at
>
>   http://www.tarkvara.com/tap
>


--
An excellent solution would be to close the e-mail to Usenet gateway.

I personally have had insufficient success with my private messages to the
users of the gateway in France that is causing many of these thread
fragmenting problems. Thread fragmenting at omp.lang.ada is done by a
quite small number of people who don't seem to have the robust explanation
that might be appropriate, once written to privately. There does not seem
to a factual basis for the idea that complaints should be private rather
than thoughout the split-off threads. It would be interesting to have
Mr Tardieu and maybe Mr Christopher Grein write in explaining the
rationale or whatever.