Airbus Chooses GNAT Pro Ada for Development of Unmanned Aerial System

Sounds like a psycho to me. If you change the name of a variable in any language it will ripple through other modules.

With Ada, in his modules, he could've done this:

    Old_Name : Type_Name renames New_Name;

I'm not surprised an engineering class tended away from Ada. It's really designed to ensure robust software is produced than it is anything else. It tends to want to force you to write down far more of your mental model than other languages, and it will hold you to it. While I find this very helpful in ensuring my programs actually do what I intended, I think it also incurs some up-front costs. It's harder to just start writing anything and then slowly twist it into a solution. It also takes a little more time before you run it for the first time. The certainty that it actually works at that point is what makes it all worth it.

It's a bunch of trade-offs ill-suited for a large number of simple programs.

Emotionally I think it's also a bit of a harder sell because of it. I spend far more time trying to get it to compile than you do in other languages. Particularly if you are in a rush, it can feel worse. You don't even have an executable yet - and it's the damned language/compiler that won't let you make one! Never mind that the reason it's stopping you is that the theoretical executable wouldn't work properly. I can't decide if it is actually a matter of delayed gratification, or if it's merely very similar. But either way, I think that's one of the adoption issues I haven't seen talked about much.

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

Eventually that experience was moved into UNIX workstations, like everyone else trying to capitalise on their market.

The "I don't need IDE" culture is more related to languages born in UNIX culture.

BASIC is a word, and it means Beginner's All-purpose Symbolic Instruction Code.

I don't know why you think it's impossible to have an acronym spell a name?

That was one of the problems Ada addressed. But its initial problem was the cost of compilation and builds on the hardware of the time. That got sorted out by the end of the 80's, but then other factors like contractors not wanting their customer telling them how to do their work came into play. Sort of a confusion of requirements and implementation methods.

C compilers for the Mac came along later, and even Apple A/UX Unix System V with BSD extensions, and Gcc. A/UX ran pretty nicely in 8M on an SE/30 (512x342 mono CRT), with a MacOS 9 GUI emulator you could run xterms on.

But that said, it's strange that Kernighan wrote the above article ("Why Pascal Is Not...") in 1981, i.e. three years after the introduction of UCSD Pascal and Modula-2.

Does anybody here know the background of that article? Why was Kernighan feeling the need to defend C against a 13-year old language which was already not in use anymore in its original form at the time the article was written? Was C under attack and risking to lose its popularity?

That's very academic. The GPS is available under GPL (see https://github.com/AdaCore/gps). As long as you don't deploy GPS or link your app with it you can use it for closed-source apps as you like; it's definitely no GPL violation.

> This sucked for Smalltalk

Not sure why you compare it to Smalltalk; but for the latter you can use Squeak for free (under MIT or Apache license) since the nineties and today even a couple of other powerful Smalltalk implementations such as Pharo.

- Nullable types (Option<T>), maybe-error results (Result<T. E>) etc. that force you to check whether you're looking at the right variant. You can't have bugs where you fail to check the error value and you use invalid/meaningless data, because you syntactically cannot express access to the data. This does often manifest as avoiding NULL pointer dereferences, which is technically a form of memory unsafety, but it's really preventing a logic bug. (For instance, this would have made the "goto fail" bug unnatural to write; that one was returning err = 0 as if it were an error, which you can't really do in the Result model.)

- More generally, sum types / tagged enums and the match and if let constructs, which enforce at compile time that you're accessing data from the right variant.

- Locked data that enforces that you hold the lock when you access the data, using similar means. You can enforce that there's no direct access to the data except through the lock wrapper, and more importantly, you can enforce that the lock stays locked as long as someone holds a direct reference to the data (i.e., that you can't leak a reference to that data and use it after you've released the lock).

- Safe threading/concurrency via labeling which types can be moved between or shared across threads. Again, this is technically a form of memory unsafety (data races) but it's more about logic.

- Typestate. You can avoid bugs where you use some logical resource when it's in the wrong state (read/write a closed file handle, send protocol data while you're still handshaking, etc.) if your API consumes ownership of the object in one state and returns the object in another state, and you don't have methods on objects of the wrong state. Rust pre-1.0 had typestate as a language-level feature, but it's straightforward to implement using the typesystem and the ownership model.

Really, I would say the core feature of Rust is a richer type system and the system of ownership and shared/mutable references. The most obvious thing to do with it is to prevent buffer overflows and use-after-frees, but it's not the only thing. (And that's also why I mentioned safe dynamic allocations, which rely heavily on the ownership system; without it, it's still pretty easy to prevent buffer overflows for static allocations.)

I don't have a sense of where Ada lines up on these. I know it has a much richer type system than C too, so it's possible it answers many of the goals besides safe dynamic allocations. I just personally see the benefit of Rust as more than just memory safety.

I won't say I've never run into some kind of problem with Ada on gcc (aka FSF GNAT), but it's been pretty minimal and easily avoided. I think it's been a grand total of two or three bugs that I've known of in that time. I've also run into known gcc bugs with C++ before so the situation doesn't seem particularly bad to me.

I find it hard to believe a solo or duo dev shop has a real need for a support contract for their compiler. What language can you get a support contract for that is affordable by anyone?