Ada 83 ========== 2025-03-22 I really love the Ada programming language. In fact it's my fave imperative language and often times when I am working in JavaScript for my job I would long to be able to live in Ada, breathe Ada, drink Ada <3. I try to keep up to date on what happens in the (small but kind) Ada community, but I'm not very active there. From time to time I check the forum on ada-lang.io to see what's the latest buzz. Last December there was a very interesting post by VMo about resurrecting an old open source Ada 83 compiler [1]. The reactions were mixed. Some thought it an interesting endevour, but others didn't see the point. GNAT is the main open source Ada compiler and although it was developed to support Ada 95 and upwards, you can tease it into a kind of Ada 83 mode with a flag. A comment about that in the forum thread got me thinking and I wrote a response that I share here. This was the comment: > I havn’t understood the interest since GNAT has a > -gnat83 option, then we can easily avoid extra feature > in our development. And this was my reply: First of all: you’re of course right in a utilitarian way. GNAT is a fantastic compiler and I personally wouldn’t want to backport the systems I’ve written in Ada 2012 to Ada 83. Let alone the horrible task of trying to communicate such a flight of fancy to my clients :-) For most intends and purposes it does not seem to make much sense to want to have a different option of writing Ada 83 code than using the -gnat83 flag. But bear with me, because I do have thoughts (and as I found out “feelings” about this :-). My personal summary of reasons why I would love to have an open source strict Ada 83 compiler: I love computer history and especially anything regarding programming language theory and development. It’s immensely valuable to realize that many of the fundamental CS problems we are facing today were already in the minds of great thinkers in the 1900s. A nice way to experience this history is to try to immerse yourself in it. With computers we often have the ability to do so. Doing this as a sort of exercise helps you understand the reasons why our field developed like it did and also helps thinking about our future. Why did Ada 95 evolve this way? Why is Ada 2022 considered a “big” language but maybe not such a bad thing? What good arguments are there for this instead of sticking to Ada 83? I think there are more than enough reasons, but I feel nothing helps cement that thought process like experiencing Ada 83 especially using the compilers of the day. Having a separate “small” Ada 83 compiler helps in the efforts with regards to permacomputing and “human scale” computing. The idea that a single person can read and understand an entire compiler without making it a gigantic effort is very charming to me. If we had a separate Ada 83 compiler that was relatively easy to grok and extend to supporting other target platforms, you could make it a nice part of the permacomputing scene. Ada has a great mix of high level programming features and considerations for correctness paired with the ability to go super close to the metal. I don’t know any other language that balances this so well. I like playing around with the UXN/Varvara ecosystem and Ada 83 is one of the high level languages that would actually be feasible to use for targetting this 64kb 8-bit VM. You don’t always need the full modern Ada to be productive. I have tested compiling Ada to WASM with the awesome GNAT LLVM toolchain. It’s a very neat feat of engineering and might in the future be quite usable for a lot of tasks, but at the moment I wouldn’t use it for replacing the JavaScript in a typical SPA. I often have to write web interfaces in embedded environments and pulling in a WASM file that is hundreds of kb’s is too much. Making a smaller RTS, and all the other things involved in getting the size down when compiling “modern” Ada is quite a task. Interesting to some, but I prefer to work from the ground up instead and would love to be able to make an Ada 83 backend that outputs WASM directly. This DIANA project that Vincent has so kindly brought to our attention might be just the ticket :heart_eyes: In the free software side of things Ada has one main compiler and although understandable I think it’s not necessarily a good thing for the health of the language in general. I applaud all the efforts of Adacore and all the other folks who work on GNAT and you’ll have to pull that compiler from my cold dead hands, but having alternatives is a good thing in general. It helps the ecosystem. It opens up alternative paths to the future, to other languages perhaps, or to support on all kinds of platforms. Porting GNAT is quite a bit of effort and although cross-compiling is neat there’s nothing like hearing an old machine from decades ago purring while it’s meticulously compiling the code I’ve written in 2024. But that might be a personal defect :grin: There might be some more “engineery” reasons why Ada 83 is valuable or maybe sometimes even more so than modern Ada’s. I know there’s still people who prefer C (even C89) to C++ for example, so there might be something there. However I wouldn’t know frankly. I’m no expert since the first Ada I used was Ada 2005, so my love of this language kind of “grew up” in the modern era. Hyperlinks: [1]: https://forum.ada-lang.io/t/anyone-interested-in-resurrecting-an-open-source-strict-ada-83-mil-std-1815a-compiler/1015 ----------------------------------------------------------- Tags: english