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.55.77.130 with SMTP id a124mr12531697qkb.24.1509327818746; Sun, 29 Oct 2017 18:43:38 -0700 (PDT) X-Received: by 10.157.48.149 with SMTP id s21mr644797otc.2.1509327818709; Sun, 29 Oct 2017 18:43:38 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!k31no5203624qta.1!news-out.google.com!r5ni5463qtc.1!nntp.google.com!z50no5187923qtj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 29 Oct 2017 18:43:38 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:18f:900:f900:890b:5da7:fc3a:7d41; posting-account=3pYsyQoAAACcI-ym7XtMOI2PDU8gRZS5 NNTP-Posting-Host: 2601:18f:900:f900:890b:5da7:fc3a:7d41 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8347a499-b7ba-42c3-bcf1-0bcf446e7a0c@googlegroups.com> Subject: Re: Proposing/Recomending Ada Usage At Work From: Andrew Shvets Injection-Date: Mon, 30 Oct 2017 01:43:38 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:48654 Date: 2017-10-29T18:43:38-07:00 List-Id: On Sunday, October 29, 2017 at 9:36:05 PM UTC-4, Shark8 wrote: > At work there's a system (simulator + scenario-editor) being used in stud= ies which is in desperate need of an upgrade -- particularly/specifically i= n terms of the editor's usability, as the time to create a scenario is rapi= dly ballooning to fill up all the time allocated to a study. >=20 > This issue has spurred a drive for suggestions and solutions, and while m= uch of the issue is indeed more of a UI issue, there are implementation con= siderations which impact the amount of time needed to make a scenario. >=20 > Both the editor and simulator are written in Java, the editor in particul= ar started off as two other programs/collections-of-programs which were mer= ged together in an unholy amalgamation (Java Swing & AWT, IIRC) of stylisti= c solutions and as such has no real "unifying concept" which, in turn, mean= s that there's all sorts of ways that either the editor proper or the under= lying scenario can be put into an invalid state, either forcing a restart o= r saving a corrupt scenario. >=20 > The saves themselves are subdirectories containing a few custom-language = scripts and massive XML files, on which a good chunk of post processing is = run, and the logfiles are /gigantic/ for some of these scenarios (like 6GB)= -- both of these are, at various points, run through various parsers to ha= ve information extracted and reconstructed. >=20 > So, considering all of this, I'm considering proposing a rewrite in Ada (= and SPARK, where possible), as w/ Ada we can define the components in the m= odel in ways that they cannot be put into invalid states, as well as making= a system where the [need for] post processing is eliminated or greatly mit= igated. >=20 > The editor is also plagued with things like timing errors (race condition= s), and certain operations like certain "copy" functions not copying underl= ying links [and thus leading to an inconsistent simulation state]. >=20 > So, we can address some of these as follows: > (1) Properly modeling the problem-space, > (2) ensuring that model cannot be inconsistent (at least insofar as the t= ype-system can ensure/model this), > (3) creating a standardized serialization method, ideally ASN.1, which wo= uld aid in: > (a) unifying the external saves [and logs], > (b) reducing transfer-bandwidth via compact encodings, > (c) could be used to output/serialize-to XML or [possibly] current text= -logs. > (4) use the TASK construct to offload a lot of the confusion of multithre= ading, > (5) the DSA could be used to distribute the load between processing compu= ters [running the large-scenarios takes the majority of a 24hr day], > (6) if Ada 2020 is considered, then the PARALLEL block could be used to t= ake advantage of massive parallelization. >=20 > ------------------ > Anyway, what are some suggestions and tips for presenting this or making = my case? > Also, what are the points/features I'm missing? I would emphasize that Ada/SPARK does reduce risk in the long-term. Add in= AUnit and contracts and you will have a solid application that withstand j= ust about anything that you throw at it.