Problem space and solution space

Problem space and solution space

[Amir Yantimirov]

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

Being in problem space is not always an advantage. Very often solution
space is magnitudes more stable and solid then continuously moving
problems. So "solution side" parts of problem-solution bridge became
more useful and reused.

The prime example of solution space thing is all sorts of
container/collections libraries, generic or common root ones. So the
lack of such standard libraries in Ada is a prooth of Ada's problem
orientiness. :))

Amir Yantimirov
http://www174.pair.com/yamir/programming/

Re: Problem space and solution space

[Robert I. Eachus]

Amir Yantimirov wrote:

> The prime example of solution space thing is all sorts of
> container/collections libraries, generic or common root ones. So the
> lack of such standard libraries in Ada is a prooth of Ada's problem
> orientiness. :))

No, when developing the various libraries, the problem space is the 
class of all problems to which the solution can be mapped.

In a sense you are right though.  In Ada you tend not to have one sort 
package in your toolbox, or one list type implementation, you have 
several.  Now the programmer solving some problem sees a part of his 
decomposition that can be solved by a list package or a sort package, 
and does a generic instantiation.  The problem is that there is no easy 
way, in Ada, to express a binding to a member of the class of sort 
generics, but to delay the choice of the actual mapping.

This is why one of the features I expect interfaces to add to Ada is a 
better way of organizing collections of sort algorithms and the like.

Re: Problem space and solution space

[Alexander Kopilovitch]

amir@iae.nsk.su (Amir Yantimirov) wrote:
>Being in problem space is not always an advantage. Very often solution
>space is magnitudes more stable and solid then continuously moving
>problems.

Beautiful frankness. indeed. One question, though: do you think that this
approach is equally applicable to other areas of science/technology?
  By the way, I see, you are from nsk.su, so you have many scientific
institutions near you. Do they permanently reproduce the same "stable and
solid solutions", not bothering themselves with annoying specifics of
"continuously moving problems"?

> So "solution side" parts of problem-solution bridge became
>more useful and reused.

Surely. Use Microsoft solutions (if you found them solid and stable), as many
people do, and be happy. And avoid Ada language, because it is designed not
for your programmer's pleasure and happiness, but for dealing with real-world
problems, which are, sad to say, continuously moving.

>The prime example of solution space thing is all sorts of
>container/collections libraries, generic or common root ones. So the
>lack of such standard libraries in Ada is a prooth of Ada's problem
>orientiness. :))

And what is your guess, why these important things weren't included even in
Ada 95 standard? Do you think that Ada language designers severely underestimated
their importance?


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

Re: Problem space and solution space

[Alexandre E. Kopilovitch]

maa@liacc.up.pt (M?rio Amado Alves) writes:
><<parts of "solution space" may be viewed as a "problem space" of
>software development process>> (Alexander)
>
>A typical situation occurs in the chain
>  1 requirements specification
>  2 design
>  3 program
>where 1 is a problem to the designer, 2 is a solution to 1, 2 is a
>problem to the programmer, and 3 is a solution to 2 (and transitively
>to 1).

No, that is only the middle part of the actual chain, which is more like this:

1 real-world problem              -- here we are in problem space

2 requirements specification      -- here we are still in problem space

3 design                          -- here we construct a mapping from some
                                  -- decomposition of the problem space into
                                  -- some decomposition of solution space

4 program                         -- here we are in solution space

5 production run and maintenance. -- is there an easy-to-follow bidirectional
                                  -- correspondence between the problem space
                                  -- and the solution space ?

Most important thing here is that we should consider solution spaces with
no less attention then problem spaces. This means that we should indeed treat
them as spaces of some sort, and try to apply to them systematically the same
approaches and notions that we routinely associate with various kinds of spaces.
  With that understanding the whole chain looks (well, I admit, quite vaguely)
as a process of construction of some sort of correspondence between the problem
space and the solution space. The task of controlling that process has its own
problem space, and this one is that I tried to tell about in my previous posting
under this subject line.
  Finally, I'd like to mention, that this view was not justified until relatively
recently (perhaps, not earlier then 1980 or so), because there was no substantial
space of solutions for general use; the available ready-to-use solutions were
mostly isolated.


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

Re: Problem space and solution space

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

> Most important thing here is that we should consider solution spaces with
> no less attention then problem spaces. This means that we should indeed treat
> them as spaces of some sort, and try to apply to them systematically the same
> approaches and notions that we routinely associate with various kinds of spaces.
>   With that understanding the whole chain looks (well, I admit, quite vaguely)
> as a process of construction of some sort of correspondence between the problem
> space and the solution space. The task of controlling that process has its own
> problem space, and this one is that I tried to tell about in my previous posting
> under this subject line.

I prefer to think of what you do as mapping existing/known solutions 
into the problem space.  When you can put together a collection of 
solutions that covers the problem space, now all you have to do is to 
realize that mapping.  In Ada a lot of that realization can be in the 
form of generic package instantiations, or calls to routines in library 
packages.

When attacking a new problem, you can often use both decomposition, 
breaking the problem into parts, and composition, putting together known 
solutions, to find a complete, usable mapping.  Once you have such a 
mapping, what happens is that at each level of abstraction, the 
architecture reflects some part of the 'actual' problem space, while the 
implementation can and should reuse existing code solutions.

But the reason I originally blurted it out, and why those few words turn 
out to be so powerful, is that when you attempt to modify the problem 
space to fit a solution model, you are almost always making a serious 
mistake.

An excellent example of when it is right to do so came up in the early 
days of Ada, when the language was still being defined.  There were some 
troubling implementation issues for Ada compilers.  Two examples were 
how to determine when an apostrophe is part of a character literal, and 
how to do overload resolution.  In both cases elegant algorithms were 
proposed that "almost" fit.  Rather than decide whether it would be 
possible to modify the solutions to fit the language, we were able to 
decide to legislate the difficulties out of existance.  (In both cases, 
the changes to the language were minor, and basically put a thumb on the 
scale where two otherwise equally acceptable language rules were being 
considered.  But opportunities like that are very rare. ;-)

I could probably spend all night listing cases where kludging solutions 
to solve problems that didn't quite match led to disaster.  But most 
readers here would say, that reminds me...   And we'd never get any work 
done.

(If you are interested, the apostrophe case was solved by making it a 
metarule that the sets of language tokens that could be followed by 
apostrophes and by character literals would be disjoint.  So a compiler 
has no problem breaking a line like String'(',',''',',')'Length into 
tokens, even though a novice Ada programmer might find it pretty 
puzzling.  The overloading resolution was solved by an elegant two pass 
algorithm with excellent bounds on complexity.  Once Ted proposed it, no 
language changes that would break the rule were taken seriously.  As I 
said, very unusual cases.)

Re: Problem space and solution space

[Craig Carey]

On Wed, 14 May 2003 06:16:28 +0400 (MSD), "Alexandre E. Kopilovitch"
<aek@vib.usr.pu.ru> wrote:

>maa@liacc.up.pt (M?rio Amado Alves) writes:
>><<parts of "solution space" may be viewed as a "problem space" of
>>software development process>> (Alexander)
>>
>>A typical situation occurs in the chain
>>  1 requirements specification
>>  2 design
>>  3 program
>>where 1 is a problem to the designer, 2 is a solution to 1, 2 is a
>>problem to the programmer, and 3 is a solution to 2 (and transitively
>>to 1).
>
>No, that is only the middle part of the actual chain, which is more like this:
>
>1 real-world problem              -- here we are in problem space
>
>2 requirements specification      -- here we are still in problem space
...

Mr Tardieu (ada.eu.org gateway maintainer) wrote back to me, on my private
topic of a solution for the problem of threads at comp.lang.ada, being
fragmented (by messages from Russia). It was suggested privately that I
modify "Mailman" software.

I can't see what change would lead to success in this matter of stops
threads fragmenting up after passing through the software in France.

If a change were made then an obvious thing to do is to have the mailman
software require that 2nd and subsequent message contain a "References"
header. However that likely will not improve the apparent situation for
users of the outstanding Agent e-mail client for the Windows OS, since
Agent and Free Agent ignore "References:" headers. I sent in a bug report
to Agent months ago on the ignoring of References headers and no fix
resulted. They almost document that problem here:
  http://www.forteinc.com/agent/features.php

Though it looks like all of Mr Kopilovitch's messages currently go through
the ada.eu.org gateway, I would hope that it gets closed.
Mr Kopilovitch may be holding on to some of the best arguments for keeping
the gateway open. It is little used.

I was writing to Mr K privately in the last week but my e-mail was not
being replied to, leaving little option but to write here.

Craig Carey
http://www.ijs.co.nz/ada_95.htm

Problem space and solution space

[Alexandre E. Kopilovitch]

"Robert I. Eachus" <rieachus@attbi.com> wrote:
>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.

Suddenly I realized that this statement has even more value that I thought when
I saw it yesterday first time. Naming "solution space" explicitly, and placing
it at the same level (within the statement) with "problem space" leads to very
interesting glimpse: potentially, parts of "solution space" may be viewed as
a "problem space" of software development process, and with that view some shaky
or too empirical things in software engineering arsenal can acquire more or less
solid ground (and thus be used in less chaotic manner).

(I can't resist the temptaion to share this understanding of a numinous word
with the community -;)


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

Re: Problem space and solution space

[Mário Amado Alves]

<<parts of "solution space" may be viewed as a "problem space" of
software development process>> (Alexander)

Indeed. A typical situation occurs in the chain
  1 requirements specification
  2 design
  3 program
where 1 is a problem to the designer, 2 is a solution to 1, 2 is a
problem to the programmer, and 3 is a solution to 2 (and transitively
to 1).

--Marius

Re: Problem space and solution space

[Simon Wright]

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

> "Robert I. Eachus" <rieachus@attbi.com> wrote:
> >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.
> 
> Suddenly I realized that this statement has even more value that I
> thought when I saw it yesterday first time. Naming "solution space"
> explicitly, and placing it at the same level (within the statement)
> with "problem space" leads to very interesting glimpse: potentially,
> parts of "solution space" may be viewed as a "problem space" of
> software development process, and with that view some shaky or too
> empirical things in software engineering arsenal can acquire more or
> less solid ground (and thus be used in less chaotic manner).

See also http://www.omg.org/mda/