From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: I'm a noob here. Date: Mon, 05 May 2014 10:46:58 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <2c400962-3a09-4da2-9f56-b4f1986b80f8@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 5 May 2014 17:47:00 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="42ea65963a295dd28559459f9f96c6a5"; logging-data="15191"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Zwbfw2uAoSTg8emQTB/lQNKUTGNT5/lE=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <2c400962-3a09-4da2-9f56-b4f1986b80f8@googlegroups.com> Cancel-Lock: sha1:8BlwXhhOUXFnc+DCRw8/cSbrHm0= Xref: news.eternal-september.org comp.lang.ada:19696 Date: 2014-05-05T10:46:58-07:00 List-Id: On 05/05/2014 04:28 AM, sdalemorrey@gmail.com wrote: > > I've recently been placed at the head of an effort to completely retool a > forex engine. The original developers wrote the thing in PHP (frontend) and C > (backend). > > There have been issues with code sanity mostly related to the size of the > numbers being dealt with. It is not uncommon for a single pass through the > order match engine to generate numbers in excess of 10 Billion, and we're > tracking up to 16 decimal places internally on some trades. Obviously float > would be a bad idea. The initial Java prototype was using BigDecimal and > that helped a lot, but there seems to be a bit of information loss when you > do math on numbers which don't have the same scale. Other issues were > encountered as well so a new project was launched to uncover a language that > could handle this sort of work more easily. > > After a lot of research, I selected Ada as the platform upon which to build > the next generation of this engine. My general feeling is that Ada has the > best approach to minimize bugs long term, even if there is a learning curve > upfront. This is a good decision. Ada is the language of choice for software that has to be correct. There are hard data that show that using Ada results in less expensive development and fewer deployed errors compared to C/++, both by about a factor of 2. And Ada's decimal fixed-point types are specifically intended for financial applications with very large, exact values. You'll want a compiler that supports the Information Systems Annex, which will provide values with at least 18 decimal digits. > What I'm having a hard time wrapping my head around though, is what is the > difference between Ada and Spark? > > It seems to me that Spark (at least Spark 2014) is a variant of Ada which > targets the needs of systems where a code mistake might cost millions of > dollars or even lives. > > What I don't understand just yet is HOW does it do that? I've tried to > follow the Ada Gems articles and the best I've been able to glean is that > Spark appears to not allow assignment during compare i.e. none of C's if(a = > b) garbage. Which is great, and all, but why a whole different profile just > for that? Ada disallows assignment during comparisons, so that's not SPARK. > Or is Spark a derived language, much as C++ is derived from C, and I'm just > not really groking it properly? SPARK is a subset of Ada which is fully defined (nothing is "implementation defined") plus a set of annotations in the form of Ada comments. The result can be processed by SPARK tools to formally prove the absence of some kinds of errors, and can be compiled by an Ada compiler. Equivalents of some of the SPARK annotations have recently been added to Ada in the 2012 revision of the standard, so SPARK is evolving accordingly. Using SPARK requires that you have a good understanding of what the software is supposed to do up front. This information ends up in the annotations that the tools use. It's a formal, mathematical approach to S/W development that doesn't appeal to most developers (in other words, it's the opposite of C). There are data showing that it can reduce errors by an order of magnitude compared to plain Ada. > Any caveats with the language might be good to know about as soon as > possible. I took Pascal classes in high school and Ada looks like it derives > some of it's syntax from that. It's also possible that Pascal derives it's > syntax from Ada, but either way they seem to be in the same family. The initial design of Ada used Pascal as a starting point. One lesson from McCormick's experiences is to embrace user-defined numeric types, rather than using Integer and Float everywhere as most C people forced to use Ada do. I recommend Riehle's /Ada Distilled/ for learning the language: http://www.adaic.org/wp-content/uploads/2010/05/Ada-Distilled-24-January-2011-Ada-2005-Version.pdf SPARK is covered in detail in Barne's /High Integrity Software/. adaic.org is a good resource. -- Jeff Carter "Ada has made you lazy and careless. You can write programs in C that are just as safe by the simple application of super-human diligence." E. Robert Tisdale 72