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.198.79 with SMTP id b76mr12148904qkj.26.1509327364544; Sun, 29 Oct 2017 18:36:04 -0700 (PDT) X-Received: by 10.157.52.218 with SMTP id t26mr647596otd.10.1509327364499; Sun, 29 Oct 2017 18:36:04 -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!k31no5200378qta.1!news-out.google.com!r5ni5463qtc.1!nntp.google.com!z50no5184478qtj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 29 Oct 2017 18:36:04 -0700 (PDT) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.113.16.86; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.113.16.86 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Proposing/Recomending Ada Usage At Work From: Shark8 Injection-Date: Mon, 30 Oct 2017 01:36:04 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:48651 Date: 2017-10-29T18:36:04-07:00 List-Id: At work there's a system (simulator + scenario-editor) being used in studie= s which is in desperate need of an upgrade -- particularly/specifically in = terms of the editor's usability, as the time to create a scenario is rapidl= y ballooning to fill up all the time allocated to a study. This issue has spurred a drive for suggestions and solutions, and while muc= h of the issue is indeed more of a UI issue, there are implementation consi= derations which impact the amount of time needed to make a scenario. Both the editor and simulator are written in Java, the editor in particular= started off as two other programs/collections-of-programs which were merge= d together in an unholy amalgamation (Java Swing & AWT, IIRC) of stylistic = solutions and as such has no real "unifying concept" which, in turn, means = that there's all sorts of ways that either the editor proper or the underly= ing scenario can be put into an invalid state, either forcing a restart or = saving a corrupt scenario. The saves themselves are subdirectories containing a few custom-language sc= ripts and massive XML files, on which a good chunk of post processing is ru= n, and the logfiles are /gigantic/ for some of these scenarios (like 6GB) -= - both of these are, at various points, run through various parsers to have= information extracted and reconstructed. So, considering all of this, I'm considering proposing a rewrite in Ada (an= d SPARK, where possible), as w/ Ada we can define the components in the mod= el 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 mitig= ated. The editor is also plagued with things like timing errors (race conditions)= , and certain operations like certain "copy" functions not copying underlyi= ng links [and thus leading to an inconsistent simulation state]. 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 typ= e-system can ensure/model this), (3) creating a standardized serialization method, ideally ASN.1, which woul= d 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-l= ogs. (4) use the TASK construct to offload a lot of the confusion of multithread= ing, (5) the DSA could be used to distribute the load between processing compute= rs [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 tak= e advantage of massive parallelization. ------------------ Anyway, what are some suggestions and tips for presenting this or making my= case? Also, what are the points/features I'm missing?