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
