Re: can ada do big financial apps?

Re: can ada do big financial apps?

[gautier_niouzes]

This one for instance ?
http://www.adacore.com/press/deep-blue-capital-financial-system-development/

From my own experience you can gain also tremendous speed increases by warping some static data from a database into Ada code. Typically table A goes into enumerated type E, table B into type F, and links is an array(E) of F.
You gain:
- readability (e.g. you can group, reorder things, use "others")
- availability of comments
- availability of source control
- checking by the compiler of duplicates or missing items (this is really the Ada "plus") - in SQL, gaps or duplicate will be unnoticed, your numbers won't fit, and you have no chance of tracking the problem's source
- 1000's speed factor on the same server - plus it becomes so lightweight you don't need the server: you can run the program on a laptop during a meeting...
_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: can ada do big financial apps?

[Georg Bauhaus]

<gautier_niouzes@hotmail.com> wrote:
- in SQL, gaps or duplicate will be unnoticed, your numbers won't fit, and
you have no chance of tracking the problem's source

To be fair, one needs to add "typical" to "SQL", 
i.e., without user defined types, without table constraints and so forth.
With proper relational stuff in place,
Ada has no way of being just as expressive 
at the level of set specifiers, not without implementing half of Prolog.

But, special Algorithms can trade generality for speed when one needs it.

> - 1000's speed factor on the same server - plus it becomes so lightweight
> you don't need the server: you can run the program on a laptop during a meeting...
> _________________________ 
Gautier's Ada programming 
 

Re: can ada do big financial apps?

[gautier_niouzes]

Le vendredi 12 mai 2017 19:17:19 UTC+2, Georg Bauhaus a écrit :
> <gautier_niouzes@hotmail.com> wrote:
> - in SQL, gaps or duplicate will be unnoticed, your numbers won't fit, and
> you have no chance of tracking the problem's source
> 
> To be fair, one needs to add "typical" to "SQL", 
> i.e., without user defined types, without table constraints and so forth.

Agreed. Now you can guess that the full story is a little bit more complex than the easy case of tables A, B and enumerations E, F and that the error detection extends to the run-time field upon processing of "dynamic" data containing inconsistencies, typos, holes, etc.

Re: can ada do big financial apps?

[Robert Eachus]

On Friday, May 12, 2017 at 8:58:39 PM UTC-4, gautier...@hotmail.com wrote:

> Agreed. Now you can guess that the full story is a little bit more complex than the easy case of tables A, B and enumerations E, F and that the error detection extends to the run-time field upon processing of "dynamic" data containing inconsistencies, typos, holes, etc.

Actually, if you write your Oracle embedded code in PL/SQL, the biggest difference from Ada is that the convention is that reserved words are in upper case.  (They are case insensitive.) If you want to take an Ada program that uses a database, and make it an embedded procedure, the biggest change usually is to strip off the database access code.  YMMV depending on how you imbed SQL in your Ada code...