| student 2007-11-19, 10:10 pm |
| Nick Wedd wrote:
> In message <Pine.LNX.4.64.0709140923440.24057@frank.dcs.qmul.ac.uk>,
> Matthew Huntbach <mmh@dcs.qmul.ac.uk> writes
>
> < snip >
>
>
> I once, a bit over 20 years ago, wrote some commercial Prolog for a
> project where it really did seems appropriate.
>
> Suppose a client was trading on a stock exchange and has long and short
> positions in various stocks and options. The stock exchange had a
> well-defined set of rules on how much margin the client must put up.
> These rules were moderately intelligent, for instance they recognised
> that if you have written calls on a stock with a certain date and
> exercise price, and also written puts on the same stock with the same
> date and a lower exercise price, then the total risk is no greater than
> the larger of the separate risks. There were other rules like this,
> many of them more complicated. The set of rules was liable to change
> from time to time.
>
> My task was to represent these rules in Prolog, and to write an engine
> which, given a client's total position, could find the way of pairing
> its components so as to satisfy the rules with the minimum total margin
> requirement.
>
> Nick
While I would agree that present-day ISO Prolog not very useful
outside the classroom, present-day ISO Prolog is not co-extensive with
the concept of Prolog -- and Prolog is not a "language" is the abusive
sense in which that term is misapplied to deterministic
stepwise-imperative computing notations.
At issue is not whether Prolog can make deterministic
stepwise-imperative computers jump though complicated hoops as quickly
as deterministic stepwise-imperative notations such as "C" can, but
whether it actually makes sense to use anything less than a fully
executable logic-based declarative language such as Prolog to express
the specifications of complicated problems when those specifications
will themselves have to be repeatedly revised in the face of sudden and
unpredictable changes in the respective underlying realities -- and
especially when decisions based on outmoded specifications will carry
serious risk of injury and loss of life.
Although I am no longer as enthusiastic about PDC Prolog as I was at
the time, a comment I made in this connection some 15 years ago seems to
me to be appropriate in this context:
<quote>
COMPUTER BB
TOPIC: PROGRAMMING
TO: <xxxxx> (<xxxxxxx> )
FROM: BILL HOGAN (TWDX23A)
SUBJECT: PROGRAM NEEDED
DATE: 07/13/93
<xxxxx>- I am pressed for time at the moment, but I do not
want to let this opportunity pass, so I hope you will not
mind too much if I import an excerpt from something I
recently wrote to someone else (on Compuserve), to whit:
Setting aside the question of the existence or
non-existence of (affordable) canned software that might be
adapted to your particular scheduling problem, the most
important part of any scheduling problem consists of
describing the problem.
Scheduling problems that involve people are notoriously
hard to define: it is very easy to get trapped on a
merry-go-round whereby every time you think you have
captured "the" problem, someone who does not like one of
the consequences of your definition turns around and says
"Oh, but that's not what we meant! We didn't want THAT
consequence so you will have to reformulate your definition
of the problem!"
Unfortunately, if your specification of the problem has
been "adsorbed" into, say, a C++ program, then even a
seemingly tiny change in the set of propositions that
describe the problem can play havoc with the "code" you
wrote on the basis of the original set of assumptions.
But if your specification of the scheduling problem has
been written out in an executable language (properly
speaking) like PDC Prolog, the job of reformulating the
problem and the job of "reprogramming" the scheduler are
one and the same thing.
I heartily recommend that you write out your definition of
your scheduling problem in PDC Prolog; properly done,
everyone involved will be able to understand what you have
written and, once they agree that you what you have
written is in fact a description of the problem that
exists, they will have to accept the consequences of your
description because those consequences will be logical
consequences of that description.
That's how it works with PDC Prolog: the description of
the problem and the program that generates the solutions to
the problem are one and the same thing.
As you know, people problems tend to be logic-intensive
and highly situation-specific, which is just a way of
saying that you have to be close to them in order to
understand them; to people who care only about fashioning
computer programs that sell in the millions, like pop music
albums, the notion of writing programs that are essentially
"single copies" is, I think, understandably unappealing.
But for people who have to deal with people problems one
day at a time, the availability of a computing formalism
that is at once a language (in the sense of being
thinkable-in-terms-of) and a programming language (in
the sense that with it you can make computers do things) is
very good news.
</quote>.
Plus ça change ...
--
Maximize end-user autonomy.
|