Re: Proposing/Recomending Ada Usage At Work

[Andrew Shvets <andrew.shvets@gmail.com>]

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 studies 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 rapidly ballooning to fill up all the time allocated to a study.
> 
> This issue has spurred a drive for suggestions and solutions, and while much of the issue is indeed more of a UI issue, there are implementation considerations 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 merged 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 underlying 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 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 have information extracted and reconstructed.
> 
> 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 model 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 mitigated.
> 
> The editor is also plagued with things like timing errors (race conditions), and certain operations like certain "copy" functions not copying underlying 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 type-system can ensure/model this),
> (3) creating a standardized serialization method, ideally ASN.1, which would 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 multithreading,
> (5) the DSA could be used to distribute the load between processing computers [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 take 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?

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 just about anything that you throw at it.