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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.42.115.129 with SMTP id k1mr16389381icq.25.1399311283787; Mon, 05 May 2014 10:34:43 -0700 (PDT) Path: backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!c1no1734516igq.0!news-out.google.com!du2ni23176qab.0!nntp.google.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx02.iad.POSTED!not-for-mail From: Shark8 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:32.0) Gecko/20100101 Thunderbird/32.0a1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: I'm a noob here. References: <2c400962-3a09-4da2-9f56-b4f1986b80f8@googlegroups.com> In-Reply-To: <2c400962-3a09-4da2-9f56-b4f1986b80f8@googlegroups.com> Message-ID: X-Complaints-To: abuse@teranews.com NNTP-Posting-Date: Mon, 05 May 2014 17:34:43 UTC Organization: TeraNews.com Date: Mon, 05 May 2014 11:34:42 -0600 X-Received-Bytes: 6469 X-Received-Body-CRC: 3787046580 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Original-Bytes: 6488 Xref: number.nntp.dca.giganews.com comp.lang.ada:186247 Date: 2014-05-05T11:34:42-06:00 List-Id: On 05-May-14 05:28, sdalemorrey@gmail.com wrote: > Hello, > > 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. Given it was PHP I'm actually surprised you didn't list PHP's 'helpful' automatic methods for string/numeric conversion as one of your trouble-points. > 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. I don't think you'll be disappointed. One technique you could use is separating out user-input (or other data which is possibly 'tainted' or non-conformant to your expected format) via private type and having functions to return the proper, safe, internally used type(s). > What I'm having a hard time wrapping my head around though, is what > is the difference between Ada and Spark? SPARK is a subset of Ada -- the only one. Its goal was to provide for (and facilitate) safety-critical applications by restricting what Ada features would likely generate nonsense, what constructs were impossible to check/prove, etc. > What I don't understand just yet is HOW does it do that? SPARK is also a tool: it integrates a prover utility into itself so that you can more easily use formal methods in software construction. Ironsides is a DNS written in SPARK, and the authors have written a couple of scholarly papers on it for showing (a) the strengths formal-methods, and (b) that formal-methods are ready for mainstream industry-usage, and (c) that safe software needn't be slower than the unsafe. Read these two papers and you should get an idea of /how/ SPARK works: 1 - http://ironsides.martincarlisle.com/globecom_2012.pdf 2 - http://ironsides.martincarlisle.com/ICRST2013.pdf > 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? > > Or is Spark a derived language, much as C++ is derived from C, and > I'm just not really groking it properly? You can't do that in Ada either. SPARK is a proper subset, not a derived language. The SPARK profile/subset is designed to reduce the Ada language to a set which is easy/feasible/possible to run a static prover on -- not the elimination of [strictly speaking] common mistakes in the language. > I'm sure I'll have tons of other questions going forward, but I'm > excited about learning a new language as I undertake this project. Great, ask away -- c.l.a has some great people. > My initial role will be Architect but then I'll also be the > development lead. > > My own background is C/C++/Java and I have about 15 years experience > in software development with the last 5 years of that in the > Architect & Project Manager role. > > This is actually the first time in half a decade where I'll need to > be "the guy" who functions as an SME on a new language, so I need > learning resources to come up to speed as quickly as possible. Ah, tutorials and learning resources aren't exactly prevalent -- compared to, say, Java or C or C++ but there are a few around. I taught myself mainly from the John Barnes *Ada 2005* book, the *Ada 2012* book should be available soon. See: http://www.amazon.com/Programming-Ada-2012-John-Barnes/dp/110742481X/ref=sr_1_1?ie=UTF8&qid=1399310596&sr=8-1&keywords=Ada+2012 > I'm glad this newsgroup exists and I hope you guys/gals don't mind > me leaning on you for advice from time to time. > > 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. Ada was based on Pascal because its design as a learning language gave it many desirable features that addressed the strawman/woodman/ironman/steelman requirements. You don't really have to "watch out" like you do for gotchas like you do in C/C++/PHP because the language is remarkably free of them -- you can depend on the compiler to catch a *lot* of what you're used to having to do 'manually' -- so feel free to "play around" with it some. The only big 'gotcha' that comes immediately yo mind is misunderstanding tasks: 1 -- Inside an accept/do block there is no concurrency, this is inside the rendezvous and so the tasks [caller & callee] are bound together. 2 -- A task which isn't finished will keep its declaring-parent from exiting, so you may have to force/allow the close yourself w/ a "done" entry if, for some reason, you cannot use an OR TERMINATE on a select statement.