Lessons from Learning Ada in 2021 | Hacker News Reader

Lessons from Learning Ada in 2021

fosdem.org

94 pointspjmlp73 comments

I like how Ada and Modula-2 have a separation between the definition of interfaces and their implementation: you can compile the interface spec and code against it before the interface has a single implementation, which makes collaboration in a team easier.

I have not tried out Ada's multi-tasking capability, but it has a simple TASK syntax: http://www.sigada.org/conf/sigada2005/SIGAda2005-CDROM/SIGAd... This should make writing control code for new hardware easier, which is of course one of the core use cases.

When I wrote Pascal code as a kid and tried to learn C, I noticed how in Pascal you could concentrate on the problem, whereas in C you would constantly have to think about memory management and other distracting features (alas, this was before C89 improved a lot of things, notably type support so the compiler could help protect you from yourself).

That is why I never liked C and never changed my mind regarding it being a step back (several actually).

Having done Turbo Pascal (3.0 - 6.0), before delving into C, was a eye opener for what a systems programming language should be able to offer as minimal set of abilities. Even the fact that C lacks something like New() is ridiculous, how many devs keep getting their array allocations wrong to malloc()?

C++ allowed me to have a bit of that Ada/Turbo Pascal feeling back.

> I like how Ada and Modula-2 have a separation between the definition of interfaces and their implementation: you can compile the interface spec and code against it before the interface has a single implementation, which makes collaboration in a team easier.

Java, C#, and Rust all have interfaces. (Although Rust might call them something different. I had a lot of trouble learning Rust.)

Even in C you can typedef a function pointer. (Although I haven't done anything like that in ~20ish years.)

The isn't talking about that sort of "interface" (which Ada also has).

This refers to a difference in logical and physical program structure in which specifications are separate from bodies--formalized version of the header/source separation in C/C++. In addition to logical separation, this provides speed ups in recompilation times.

So it's somewhat inaccurate that GP calls it an "interface", it's a specification. Ada packages have two parts: specification and implementation. The specification isn't really comparable to Java or C# interfaces and I don't think they're comparable to Rust traits either. Nor is it like typedef'ing a function pointer. The better analog is C's header files containing declarations, but not definitions, which are then implemented in various C files. A major contrast with C is that Ada's packages are named scopes and occur in pairs of spec/body, whereas in C you could have one header that is implemented over many C files, or one C files that implements many headers.

And like C header files, the range of things you can declare in a package spec is essentially any valid thing in the language: types, variables, functions, procedures, more packages, tasks, etc. But C permits the definition and declaration of anything to be in the header file, there are restrictions on Ada package specifications in that regard (some things have to go in a package body). C header `#include` order also matters (since they're text inclusion, a conflict in definitions or the use of macros can impact the outcome), whereas the `with`ing of Ada packages can be done in any order.

A good description, and this is described in the video that all of these comments are about. :P

Interfaces as generic CS term, not OOP languages features.

I had been a Turbo Pascal Programmer and in the summer of 1990 joined British Aerospace as a programmer for their avionics test software. The first week I just sat with an Ada book and compiler and taught myself and week two started using it in anger. Three weeks later they put me on a one week formal training course which I sailed through as I had picked it up pretty well by then.

I know Ada now is different- it has OOP but back then it was very much like Pascal but string handling was stricter than TP. The on-aircraft software (which I didn't work on) didn't allow generics or threading.

Threading I get, but why no generics?

Most likely due to code size.

> they put me on a one week formal training course

Remember when companies did that sort of thing?

>Ada can be difficult to approach due to using a different vernacular to most other languages,

I guess people dont learn Pascal anymore. I still remember Turbo Pascal was what brought me into programming. It took me a very very long time to get used to C style programming.

It's a real pity. They are awesome beginner languages, and even when you are not a beginner any more, they go a long way. I also like their syntax a lot.

I haven't touched Ada in like 20 years and now that it seems to be having a small resurgence it looks like a good time to relearn it. It has potential to become one of my favourite languages.

I went from Pascal directly to C. Had no issues. It was a relief not to have to do BEGIN END anymore :-) Never wrote another line of Pascal.

https://www.freepascal.org Spend your weekends coding Pascal.

I'm generally sympathetic to Ada and its design decisions, as compared against C, but on this point I agree. C's braces syntax is at least as readable. If anything I'd say it's more readable as there's an immediately obvious visual symmetry between the two brace symbols.

I also prefer the C++/modern C approach to declarations, where local variable declarations can be freely intermixed with other statements. Ada uses a noisier declare/begin/end syntax. [0][1]

[0] https://stackoverflow.com/a/59192530/

[1] https://www.radford.edu/~nokie/classes/320/declareblocks.htm...

Not me. I took typing in high school and pressing Shift and stretching fingers to get braces is much harder on my hands then typing a few extra unshifted letters.

I don't think it's about the Pascal syntax. Nobody complains about using Lua, Ruby, Crystal, Elixir. Do...end blocks are perfectly fine syntax wise. Go is a Wirth lineage language too. The issue is tooling, languages like VHDL and Ada (to a lesser extent SQL too) have poor developer experiences and they never bothered to improve and add more syntactic sugar like C++ and Java.

No, the language is constantly evolving (ada95, 2012,2020), and they do add syntax sugar and new features on a regular basis.

You can submit language rfcs here: https://github.com/AdaCore/ada-spark-rfcs

For an example of the latest additions : https://blog.adacore.com/ada-202x-support-in-gnat

As to the developer experience, I find the tooling to be quite satisfactory (IDE, build system, memory/stack analyzers, provers, etc) , the main pain point being the lack of a decent package manager (there is one now, but there are few packages).

Edit: almost all the standard c/c++ tools work out of the box as well (profilers, debuggers, etc), so it's no different from c/c++ on this regard.

almost all the standard c/c++ tools

By that do you mean the GNU ones, or…?

Gnu, intel vtune, rr, pernosco, etc. Basically anything which works from a binary with dwarf symbols. The compiler is actually gcc.

In the interest of completeness: GNAT is the most well-known Ada compiler and uses GCC as its backend, but there are at least 6 other commercial Ada compilers out there. [0] As far as I know, GNAT is the only one that uses GCC.

[0] https://news.ycombinator.com/item?id=27603292

You're right, thanks for the clarification. I tend to see gcc as the only major ada compiler, and afaik, the only one implementing all the latest additions to the language.

I think PTC has upgraded to Ada 2012, or so I hear.

It has, since two years now.

https://www.ptc.com/en/products/developer-tools/objectada

> Go is a Wirth lineage language too.

Is this commonly accepted? I thought it came off the better-C camp, plus GC.

https://en.wikipedia.org/wiki/Limbo_(programming_language)

See Robert Griesemer's talk on "The Evolution Of Go"

https://www.youtube.com/watch?v=0ReKdcpNyQg

https://go.dev/talks/2015/gophercon-goevolution.slide

> In 1960, language experts from America and Europe teamed up to create Algol 60.

> In 1970, the Algol tree split into the C and the Pascal branch.

> ~40 years later, the two branches join again in Go.

https://go.dev/talks/2015/gophercon-goevolution.slide#29

Yes, not only did Robert Griesemer work under Niklaus Wirth assistence doing a PhD on an Oberon variant, the Go method syntax is based on Oberon-2, and unsafe meta-package is pretty much UNSAFE package from Oberon/Modula variants.

Then you merge that with Limbo's syntax and channels, and you more or less get Go.

Arguably it's more a comeback from Alef, this time with GC faction winning.

(C begat a bunch of research languages, those begat Alef, a conflict about whether to add GC led to Alef dying and its features reimplemented as Plan9 libraries with side effect of Limbo, years later Go is built on top of Plan9 C compiler & runtime with syntax sugar for Alef-derived libraries).

Sure, still neither of them have Oberon-2 method syntax nor UNSAFE meta package.

Plan 9 compiler was used as means to quickly get a prototype running, and naturally Rob Pike knows the toolchain quite well.

I also agree with the Alef remark.

The legacy of Plan9 compiler stack still remains despite being rewritten purely in Go - I'd say that Pike liked his previous design :)

Lol, I actually realized that the other day, hacking on the golang compiler. The amd64 cpu instruction definitions are in a file called asm6.go and I was all "wait a minute, I recognize this from plan 9", where the amd64 compiler, linker, and assembler are 6c, 6l, and 6a respectively.

Before Go 1.5, it would literally keep around an alternative port of Plan9 C compiler plus all core system libraries, and I think it still does for C ffi

There's a lot of Pascal in go's approach to compiling/modules etc. I'm not sure I can agree there's a lot of Pascal in go syntax.

If you removed the c pre-processor and translated (the syntax of) a Pascal program to C, I imagine it might look a bit like go if you squint?

I'd say go is to Pascal and C as Javascript is to Scheme/Self and Java.

> have poor developer experiences and they never bothered to improve and add more syntactic sugar

Ada actually did in Ada 2012 and moreso in Ada 202x.

- Expression functions, and expression forms of if/else and case statements

- more natural "aspect" versions of a lot of pragmas

- iterator syntax for containers which can be user-defined

- user-defined indexing into containers (Variable_Indexing and Constant_Indexing)

- user-defined aggregate initialization (such as for containers, the Yeison library exploits this to provide JSON-like initialization)

Overall though, the language syntax is coherently put together with orthogonal elements, despite the various pieces coming together over decades. The language designers have done a superb job ensuring that Ada 2012 felt uniform, and not like a collection of bolted on parts.

Ironic to put it that way, given that Ada was of the first languages with commercial IDEs available.

https://en.wikipedia.org/wiki/Rational_R1000

Now you can complain that none of them exist as free beer, and that GNAT Studio came too late, but that is another matter.

The thing that tripped me up the most in Ada was the single quote syntax.

    Character'Val

I literally failed an exam because I couldn't locate the right function in the online manual for 2 hours. And I'm pretty liberal .. I like lisp, forth and APL but still to this day, it trips me up.

Attributes tripped me up as well, which is why I talked about them in the presentation. The language server provides completions for them, which helps significantly.

I find this somewhat amusing as Ada occupies the same space that Rust is in. At first glance I find Ada vastly more approachable than Rust, which to me feels like line-noise language/Perl. Or even C++ tbh.

But I can relate that Ada feels like you should be writing it one a flickering green terminal in ALL CAPS and debugged with a daisy wheel printer.

Or a Ada Machine, that is how Rational was founded.

https://en.wikipedia.org/wiki/Rational_R1000

http://datamuseum.dk/wiki/Rational/R1000s400

Think Lisp Machine experience, with Ada instead.

> But I can relate that Ada feels like you should be writing it one a flickering green terminal in ALL CAPS and debugged with a daisy wheel printer.

In a way, the reason for such a limited character set and clunky syntax (including, e.g. case insensitivity) was precisely to maintain backward compatibility with those earlier machines.

I learn Turbo Pascal before Turbo C (about 2 decades ago, in high school). Both used the same procedural programming approach. It was a really easy switch.

Trying to learn Haskell after C++, on the other side, was difficult for me.

This always sends me to HyperPolyglot* for a syntax comparison.

* https://hyperpolyglot.org/pascal

I've got to say, I have fond memories of writing software in Ada - I was involved in writing an air traffic control system in the mid 90s in Ada.

The language didn't get in the way for that sort of application - we had proper specs, and proper designs, so by the coding stage we had a very good idea what we were attempting to solve, and what components would be required.

I'd be interested to know how it would work in a more modern Agile working practice. I've a feeling it would require a fair bit more work to maintain with simple changes having quite a large spread through the codebase due to the strong typing, but saying that, maybe the language has evolved since I last used it and it works well.

> simple changes having quite a large spread through the codebase due to the strong typing

The opposite is true in my experience and refactors are usually well bounded.

The "killer feature" of Ada is that types are not modules for writing behavior (in general). This means that syntactically, you can move functions/procedures around somewhat freely because encapsulation and namespacing is done at the package level. It leads to a lot more appropriate data and responsibility hiding, and avoids wasted time considering "is this a method or a (standalone) free function?"

Since the compiler is a harsh mistress, it's actually a very nice environment for refactoring. Use the compiler, and use strong typing. Enumerated types, switchn/case statements where you have to fill every case, most stuff is caught at compilation and then during the first tests when you enable all the checks. We're in fact far more agile in our Ada projects than any with C or Java... Small teams, 1 to 10 mloc code bases, lots of reuse and refactoring.

> I've a feeling it would require a fair bit more work to maintain with simple changes having quite a large spread through the codebase due to the strong typing

I'm porting my Rust codebase to async, and that is SUPER infective: This lead to change everything, everywhere with the exception of the "pure" functions.

And yet, the process is super boring: I get +1000 errors, start from the bottom, change this to that, now +400 errors, continues, now 0 errors, run test. Done.

Something so big will be a nightmare on a dynamic lang, and even in C# or similar (ML lineage FTW!)

I did analysis on a complex embedded real-time, safety-critical C and Ada codebase some years back, and was surprised to end up respecting the language after seeing it shine in that use case. Really changed my perspective.

Edit: The language itself never get in the way of comprehension. It was extremely easy to read and understand code written in it. After a while I barely noticed whether I was looking at C code or Ada code.

D's embedded underscores in integer literals came from Ada. It soon migrated from D to the other popular languages.

This was one of the little things that impressed me about Ada when I first found it. In spite of the murmuring about camels, and designs by committee, my first impression of Ada was a language where attention had been given to the little details with regards to making the language easy to comprehend. Having said that, I don't think that its syntax has necessarily stood the test of time as being super-ergonomic.

Such a wonderfully human-conscious feature.

It is amazing how little things like that make a difference. It's a very popular feature with D.

I believe I'm one of very few people to ever commit Ada code into the google monorepo

That's pretty cool! What are they using Ada for? I'd love to have a reason to learn and use Ada. Spark looks really cool, I love invariants, it just seems the perfect language for me.

They had acquired a company that had written all their code in Ada. The company was founded by a guy who learned to program from doing defense contracts as a grad student. So, that's why he decided to do everything in Ada.

Interesting. I had a similar experience. Different outcome. I _was_ the grad student who did a couple of military/medical projects in Ada back in the early 90s. Loved it. Tried to take a startup down the Ada route for a non-safety critical project mid 2010s and failed to convince people. IIRC it was the bus-factor - "no one else knows this shit and if you leave who we gonna hire?". Curious - how did maintaining an Ada project work out for you?

The first programming language I put serious time into was C. When I first found Ada I was struck by how easy its syntax was to understand. I think that if you needed Ada talent in a pinch you could do well to recruit experienced programmers of all stripes and train them in Ada. The language might have its peculiarities, I don't think it's a hard language though.

That's exactly what we do, hire for developer chops, train for Ada, use existing codebases as inspiration, and let's goooo.

Who's "we"? Keen to find companies using Ada :)

Defence and infrastructure stuff, near Paris France. There's also people at BNP or SocGen. Shoot a mail or dm at AdaCore or on Ada mailing lists, they sometimes help relay job offers...

It uses Blackbox technology and was based on Pascal. It was built on DoD standards. I did Ada programming in the late 1990s as a federal contractor. We used Janus ADA for DOS which cost $10,000 per license. Try one of the free and open source ones unless you have a company that can buy a license from a commercial one for you.

if you're into FPGAs, you could contribute to the ghdl compiler, which is written in ada (which I suppose makes sense since vhdl itself is also derived from ada).

If you're into embedded control Ada is a pretty good choice.

https://hackaday.com/2019/09/10/why-ada-is-the-language-you-...

"Today, software written in Ada forms the backbone of not only military hardware, but also commercial projects like avionics and air-traffic control systems. Ada code controls rockets like the Ariane 4 and 5, many satellites, and countless other systems where small glitches can have major consequences."

Here is a hobbyist example: https://www.hackster.io/ankurverma608/running-a-finite-state...

My 1st question would be looking for ADA-related jobs.

Kotlin, Dart? Mobile apps. Java, Go? backend Python, Ruby? scripting, task automation, backend

At least finding jobs requiring them is pretty easy. ADA, on the other side to me looks very niche. I think writing missile controlling code sounds fun. CRUD is boring :)

Consider how many automobiles ship each year. They have layer upon layer of safety-critical code in them. Do you think the steering code your self-driving car is written in is JavaScript connected to Ruby microservices in the cloud?

If missiles can kill safely because their control systems are written in Ada, then cars can too.

actually I think using javascript to steer cars could be very productive in making them kill

Which is why NVidia is using Ada for safety-critical firmware, even though they are a C++ shop.

https://www.adacore.com/nvidia

Oh fun fun fun 'we didn't think we'd break the firmware written in spark so we broke the ISA' https://blog.adacore.com/when-the-isa-is-the-weakest-link

Great stuff, thanks for sharing.

High integrity software, where bugs kill. Trains, aerospace, defense, artificial heart, self driving etc.

Yes, it's smaller than web development, but there's a common theme.

I bought one of the big books on Ada a few months ago, the idea being it'd kick off another adventure into a language I wouldn't normally use.

I can't comment on the language on itself really, but I did look at what a web stack might look like in Ada. A lot of work has gone into that but the thing that kept me away for the time being was that it felt like a lot of manual work to actually get the stack in place.

If someone comes and tells me I'm wrong, and I misunderstood, then I hope they do. Because my first impression was the same one I got when trying to figure out Cmake for a beginner C++ project, and I don't really have any desire or inclination to interact with Cmake again.

All the talk about Pascal. :)

But in those days there was also Smalltalk, which I find --except for the syntax-- a very modern language. I like to think of Ruby as Smalltalk with a syntax make-over and some FP bolted on top in places it makes sense.

Reply on news.ycombinator.com