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

[Stephen Leake <Stephe.Leake@nasa.gov>]

"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