Historic Ada Design

Tooling

In a previous post I recommended, even if you're using all free tools, sticking close to AdaCore's GNATPro choices for dependencies. But there is an alternative, the somewhat coherent culture that obtained in the Ada Software Repository circa 1991. Critically, note that this was applied to command-line utilities that transformed input files to output files (perhaps following the Software Tools philosophy), there may be hidden limitations. You could view this as retrocomputing, preparation for collapse, or plain contraryism.

• Use testlog for testing. It has almost no features, so you'll have to be satisfied with very simple tests. But that was enough for the fleng compiler?
• I haven't managed to find a better formatter than gnatformat.
• PTF for all documentation?

There are also some modern inventions that I would rather not do without:

• You could use "pragma Ada_1983" but I don't think it's a good idea. You can restrict yourself where it makes sense instead (the documentation makes this very clear with respect to tagged records). Also note that you may want to not go beyond 2012, to allow use of compilers other than GNAT.
• Similarly, Alire is helpful. But it's critical to think about your dependencies. In $DAYJOB we have hobbled ourselves by using a language with an anaemic standard library (Javascript) which then requires depending on third-party code. This code has many, many CVEs logged against it. So I'd recommend packaging your own software in Alire, but depending on zero or a very small number of packages (the standard library is quite capable).

Module Structures

From reviewing some medium-sized Ada programs I see common "patterns", to use an anachronistic term because these predate the GoF book. The examples I read are ptf and x1804. NB: these are command-line utilities that operate on files, later interactive and GUI programs may be quite different (and much less portable).

Top priority is some packages that have been subsumed by later versions of the language spec. These should no longer exist.

• CLI2 from the ASR has been replaced by Ada.Command_Line
• The "Dyn" string package from the ASR has been replaced by Ada.Strings.Bounded

Second, there are some reusable packages that haven't been added to the standard yet (and some of them never should be).

• Console, which was intended as an potentially-optimized subset of Ada.Text_IO. But in practice this never happened, and it would be easier to just use Ada.Text_IO.
• Similarly, Input_File and Output_File are subsets of Ada.Text_IO that can be done without.
• In contrast, Error_Log in ptf & Error_Processor in x1804 do look useful. Like a small subset of GNATColl.Traces/syslog. It only supports error & warning levels, so you're not expected to log debug messages for normal program flow. But maybe that's ok?
• Command_Line_Processor handles the "@" shortcut on the command line to read args from a file.

Finally, there are some packages that have different implementations for different systems, but are conceptually similar.

• Command and Command_Symbols from ptf is a way to implement a simple script, but *not* a full programming language (for that see aflex and ayacc).

I'm reminded that reading code is an essential skill. It's good to get some practice.

MCP

It's not particularly related, but I've also been adding support for various MUD Client Protocol (MCP) packages to rmoo. This is an interesting way to do client-server shared apps, with the thin client being Emacs instead of an orders-of-magnitude bigger Web browser. I wonder if Web apps even qualify as "thin clients" any more, for a page megabytes of Javascript source code may be transferred to run on a platform with more LOC than the OS.

Conclusion

I hope I've presented that if you're willing to accept some compromises, there are much older and smaller choices for development tools. But note that the programs I studied were command-line utilities (although ptf is quite complex internally). It's up to engineering judgement whether using these older tools is sufficient and/or lower risk or not.