Re: Untyped Ada?

[Georg Bauhaus <rm.plus-bug.tsoh@maps.futureapps.de>]

On Fri, 2008-04-04 at 19:38 +0200, Dmitry A. Kazakov wrote:
> On Fri, 4 Apr 2008 08:16:04 -0700 (PDT), Graham wrote:

> > I dare say that you wouldn't want to program a missile in such a loose
> > way, but for the kinds of things I'm involved in - financial apps and
> > simulations - the level of strictness of Ada would be a turn-off for
> > many developers.
> 
> This puzzles me. Do not financial applications have quite strict
> requirements imposed numeric behavior? Or are you writing for Bear Stearns?
> (:-))

I suppose it depends on 
(a) type of finance and
(b) on whose side you're on.


Say money is passed to/from a private customer. (Or, to the
state.) There are strict rules for how to add two money values
when these are the results of division, say. Thus they may need a
smaller fractional unit than the smallest currency unit permits:
"Here is $ 1. We are three. We'll divide the dollar evenly.
Each of us gets ..."
Ada's fixed point numbers are practical here.

There are really no rules when it comes to market analysis,
portfolio optimizing, and so on, as long as operation of the
software generates money, or is o.K. for the scientific
community. There should not be any obvious signs of
negligence in the software, though.
Obvious negligence in number handling might potentially be
used to provide evidence of fraud.  Market participants
may want fraud, or the friendlier forms of financial
advantage, but you want to avoid evidence. Avoid precise
evidence for sure. So the rules for computing with numbers
can be different from what you'd expect from a SPARK type 
machine control programming style, I suppose.

Likely some variables and functions will be controlling
the algorithms, reflecting what is important.
They'll read something like

   Xyz_At_Stake : Some_Type;

   function Noticeable_Change
     (Now, Then: Money; Interval: Time_Span)
     return Boolean;


Anything that works is acceptable. Not everywhere, but some
companies can operate with just the necessary level of
precision in their products. The dominant question is rather
whether or not the software works profitably. Also, whether
the software can be used as a subsidiary instrument to
generate profit, e.g. as a showcase. It does then not matter
much what the software is computing, *exactly*. More important
than  producing correct results WRT some econometric formulas,
it should compute something reasonable, i.e. results that can be
defended and that are useful in persuading someone to sign a
contract. Let's call it computer age scientific sales promotion.
(I mean in the sense of positive science, said without bias.)

If you read about the current money crisis, one cause is
attributed to (the lack of) trust among traders.
The theory of trust as a function value is not yet fully
established, let alone established with precision. How could
it? Scientific, even computable, rationalization of the
trading business? Would you want to pay for being replaced
with a computer program? So the financial market has a
more extensive set of rules about number handling than machine
control I suppose.



> What do you mean? In fact Ada's fixed strings handling is the best I know.
> You should never need Unbounded_String except for rare cases, when you
> wanted to return two strings out of one function.

Replacements of varying length are ssllllloooooooowww.