Proposing/Recomending Ada Usage At Work

Proposing/Recomending Ada Usage At Work

[Shark8]

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?

Re: Proposing/Recomending Ada Usage At Work

[Andrew Shvets]

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.

Re: Proposing/Recomending Ada Usage At Work

[Brian Drummond]

On Sun, 29 Oct 2017 18:36:04 -0700, 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.

I suspect the GUI aspect will be critical : you need a GUI toolkit that 
simply works and doesn't get in the way. This will have a highly visible 
impact on the project - good or bad - as its the easiest to see and 
criticize.

I'd be budgeting a small amount of time to try Gnoga (and keep the 
interface browser based) - others like gtkada change substantially 
between revisions, requiring maintenance (and a fairly substantial 
investment in learning how to use it), or add platform dependencies like 
requiring Windows. 

Not saying Gnoga is the answer but GUI is a recurring problem and I'm 
interested to hear how you tackle this aspect.

-- Brian

Re: Proposing/Recomending Ada Usage At Work

[Lucretia]

On Monday, 30 October 2017 01:36:05 UTC, Shark8  wrote:

> (6) if Ada 2020 is considered, then the PARALLEL block could be used to take advantage of massive parallelization.

Does GNAT support this yet?

Re: Proposing/Recomending Ada Usage At Work

[tclwarrior]

On Monday, October 30, 2017 at 3:43:31 AM UTC-4, Brian Drummond wrote:
> On Sun, 29 Oct 2017 18:36:04 -0700, 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.
> 
> I suspect the GUI aspect will be critical : you need a GUI toolkit that 
> simply works and doesn't get in the way. This will have a highly visible 
> impact on the project - good or bad - as its the easiest to see and 
> criticize.
> 
> I'd be budgeting a small amount of time to try Gnoga (and keep the 
> interface browser based) - others like gtkada change substantially 
> between revisions, requiring maintenance (and a fairly substantial 
> investment in learning how to use it), or add platform dependencies like 
> requiring Windows. 
> 
> Not saying Gnoga is the answer but GUI is a recurring problem and I'm 
> interested to hear how you tackle this aspect.
> 
> -- Brian

I Gnoga actively maintained, do they have a github page^ 

Re: Proposing/Recomending Ada Usage At Work

[tclwarrior]

On Monday, October 30, 2017 at 3:43:31 AM UTC-4, Brian Drummond wrote:
> On Sun, 29 Oct 2017 18:36:04 -0700, 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.
> 
> I suspect the GUI aspect will be critical : you need a GUI toolkit that 
> simply works and doesn't get in the way. This will have a highly visible 
> impact on the project - good or bad - as its the easiest to see and 
> criticize.
> 
> I'd be budgeting a small amount of time to try Gnoga (and keep the 
> interface browser based) - others like gtkada change substantially 
> between revisions, requiring maintenance (and a fairly substantial 
> investment in learning how to use it), or add platform dependencies like 
> requiring Windows. 
> 
> Not saying Gnoga is the answer but GUI is a recurring problem and I'm 
> interested to hear how you tackle this aspect.
> 
> -- Brian

Is Gnoga actively maintained? do they have a github page?

Re: Proposing/Recomending Ada Usage At Work

[Lucretia]

On Monday, 30 October 2017 14:46:58 UTC, tclwa...@gmail.com  wrote:

> Is Gnoga actively maintained? do they have a github page?

Looks like it's on SF :/

Re: Proposing/Recomending Ada Usage At Work

[Shark8]

On Monday, October 30, 2017 at 8:46:58 AM UTC-6, tclwa...@gmail.com wrote:
> On Monday, October 30, 2017 at 3:43:31 AM UTC-4, Brian Drummond wrote:
> > On Sun, 29 Oct 2017 18:36:04 -0700, 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.
> > 
> > I suspect the GUI aspect will be critical : you need a GUI toolkit that 
> > simply works and doesn't get in the way. This will have a highly visible 
> > impact on the project - good or bad - as its the easiest to see and 
> > criticize.

You are correct that GUI is critical, though only insofar as building the scenarios goes. (They're not interested in "whiz-bang" graphics; heck one of the basic entities look kinda like lolipops.) -- https://image.slidesharecdn.com/pythonincombatmodel-100805000040-phpapp01/95/how-and-why-python-is-used-in-the-model-of-realworld-battlefield-scenarios-5-728.jpg?cb=1281400284

> > 
> > I'd be budgeting a small amount of time to try Gnoga (and keep the 
> > interface browser based) - others like gtkada change substantially 
> > between revisions, requiring maintenance (and a fairly substantial 
> > investment in learning how to use it), or add platform dependencies like 
> > requiring Windows. 

This is definitely putting the horse before the cart; while Gonga could certainly be an excellent solution GUI-wise the biggest problem would be selling the rewrite -- something that actually is needed -- in terms of the current problems.

> > 
> > Not saying Gnoga is the answer but GUI is a recurring problem and I'm 
> > interested to hear how you tackle this aspect.

Right now I'm looking at things from the "advantages Ada provides" angle, while I certainly will have sections for alternatives (such as creating a prepopulated force-structure), I need to make the Ada proposal *SHINE*.

> Is Gnoga actively maintained? do they have a github page?

AFAIK, it is.

Re: Proposing/Recomending Ada Usage At Work

[Shark8]

On Monday, October 30, 2017 at 8:46:58 AM UTC-6, tclwa...@gmail.com wrote:
> 
> Is Gnoga actively maintained? do they have a github page?

 From https://sourceforge.net/projects/gnoga/
 Last Update: 2017-10-22

Re: Proposing/Recomending Ada Usage At Work

[Shark8]

If it helps, the project that I'm involved with is called Combat XXI, and is used by the army; see:

http://www.trac.army.mil/COMBATXXI.pdf

----
Also, since I'm proposing a rewrite, even papers like [1] will be useful in bolstering my case for long-term benefits.


[1] PDF: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/pldi117-yang.pdf
    Page: https://www.microsoft.com/en-us/research/publication/safe-to-the-last-instruction-automated-verification-of-a-type-safe-operating-system/#