camelCase, snake_caske, PascalCase, kebab-case, so I think I'd call that Pascal_Snake_Case or something. Other than that this is really great, Ada is pretty neat and used in the most critical systems in the world: https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html
If you separate words with underscores and feel like pressing the Shift key now and them, you can simply write in proper case, like `Convert_vCard_to_XML` :) To me it seems the most readable way.
Yeah, I got hung up on exactly what to say and then was like "Steve, you're trying to learn Ada, not trying to determine what this case is called" and just wrote something. I like Pascal_Snake_Case, I'll update the post. Thanks.
AIUI Ada is case-insensitive so there's nothing preventing you from using snake_case instead, even when referencing external identifiers. Pascal_Case is purely a matter of visual style.
If he really wanted to, he could take a look at the Consolidated Ada 2012 Language Reference Manual [1] and get his mind blown.
Don't get me wrong - I'm not claiming the reference manual is a good learning source, for that I would recommend Barnes's book, but that it's an example of a language specification. Having precise specs is a minimum requirement for a safe language. Rust is too complicated as a C replacement but arguably a good C++ replacement. Unfortunately, it's not well-defined (yet) for writing safe programs. Without spec you cannot even tell compiler bugs from intended behaviour.
I am planning on looking into more reference material eventually, but I prefer to do that after reading tutorials and writing code, as a way to answer the questions that I have.
And yes, the lack of a spec is a weakness in Rust. We've been working on it for a while, and are gonna push it even harder this year.
> Without spec you cannot even tell compiler bugs from intended behaviour.
So this is true, but it's also a bit more subtle than that. For example, "there should be no undefined behavior in safe Rust" is a design principle that, while we don't have a spec, can say if something is a bug or not. (And we do have a few of those bugs.) This is, of course, not as good as a full spec, but guiding principles can really help.
I've read through this article twice now and I still fail to see your point.
Steve is most likely more familiar with Rust than any other language - which is why I would expect comparisons between it and Ada - but he doesn't go out of his way to insist on Rust's superiority.
I'm one of the writers of learn.adacore.com and I disagree. This is a thought log from somebody who knows and loves Rust and is learning a new language.
Steve if you're around: there is an error I think in your post, you write
> Ranged integers are something people always say Rust is better at than Ada
You can think whatever you’d like, anonymous hacker news account created for this comment. Everyone can read ill will into things.
I am trying to understand Ada better. I draw some comparisons to Rust because that’s one of the reasons why I’m reading about it in the first place: people ask questions comparing the two and I have no idea of the answers.
I spent much more than five minutes here, even though the writing is short; the learning website has a lot of stuff! As I said I’m the intro, this is mostly just a log of thoughts. But it was a good solid half-day of investigation. I’ll be doing more of it in the future, too.
Thanks for the write-up. It pretty much mirrors every thought I've had while reading the same tutorial, except that I personally find That_Funny_Ada_Case weirdly appealing.
And, since you're here, you probably have a typo: “GNATT” in the paragraph about threads should be “GNAT”.
Just some log of initial negative emotions. Maybe author forgot, but Rust can raise negative emotions on the initial stage also. It takes some effort and it worth it. Maybe with Ada it's the same.
I wrote down anything that stuck out: there’s a lot of questions, but also a lot of positive things! I just had more to say about things I was unsure about then things that are like “yes, this is good.”
Were you reading that as sarcasm? From Steve's other writing I've seen, and his comments here, I don't think he was being sarcastic. I think he's literally expressing something along the lines of "Oh, that's not what I would have assumed, but it's an different way that I may or may not have thought about much. That's cool, I'll see how it goes."
If that interpretation comes across as negative, then I think you either must view most interactions with the world as negative or you've somehow managed to surround yourself with "yes" men...
I miss working in Ada, but I don't miss the industry.
Working in SPARK Ada and Prolog early in my career taught me the importance of understanding what the "philosophy" of a language was in order to use it well. After far too much time spent trying to make them behave like a different language it clicks and then you get productive.
I think it's made me much more tolerant of new languages and more forgiving of my struggles when first learning them. Some times it can take a while to understand what idomatic programs look like in a new language, especially when it's a very differnt model to ones you have been used to.
I've learned Ada at uni - while I didn't appreciate it at that time, probably currently (almost 10 years later) I'd find it more interesting. Fact that your application doesn't compile if you don't write assertions validating it certainly has gained more appeal to me.
When I learned Ada, I used the wikibook [1] and bought an inexpensive used textbook from Amazon. I have a basic competency of the language, and really like the quality of the compiler toolset, the type system, the "DIY" OOP (as I call it), and the packaging system. My biggest issues with it are that bindings for databases, graphics libs, and web development libs are few and far between and usually just a lonely github repo. But, as another positive, writing bindings to C libs seems pretty easy [2], so someday I'll give it a try.
I think this is the death knell of most people trying to casually pick up Ada or most used-but-not-extremely-popular languages from the 70's and 80's, our expectation of doing something meaningful and sensible has just moved so far that not having the supporting libraries means a lot of upfront work. I think I've gotten stuck here for LISP, getting back into Pascal, Ada, and probably some other languages I wanted to experiment building a modest size application with.
It really shows how valuable having that very active and mature core library or managed package library is to a language. I did the same learning path as the prior poster but then just ended up stuck.
Part of it is admittedly laziness and used to a certain convenience. There's no package manager for the language, and OS package managers rarely carry used-but-not-extremely-popular language bindings. But the code is out there, like this SDL2 binding: https://github.com/Lucretia/sdlada
Writing bindings for C libraries is ridiculously easy. You can run a script that generates the corrects .ads for a header file and then... wait, there is no step 2. That's it!
Syntax is a sore point for me, but as a polyglot, I push through my bias. I am learning Spark instead of full Ada, and instead of Rust for a project simply because there is a lot of precedent and libraries for what I need to do - a machinery controls package with high-level safety. I do like Rust though, but I am also playing with Zig for good measure.
WRT "out" parameters, it means that very literally. There the variable is only passed out, it is not passed "in." Steve's test never assigns "A" in Foo() so "A" is an uninitialized variable that then gets stored in the mainline "A" (which has the same name, but is an entirely different variable). The mainline "A" is assigned the value 12 but then gets overwritten by the uninitialized value passed out by Foo().
with Ada.Text_IO; use Ada.Text_IO;
procedure Outp is
procedure Foo (A : out Integer) is
begin
Put_Line (Integer'Image (A));
end Foo;
A : Integer := 12;
begin
Foo(A);
end Outp;
A clearer example would be:
with Ada.Text_IO; use Ada.Text_IO;
procedure Outp is
procedure Foo (A : out Integer) is
begin
Put_Line (Integer'Image (A)); -- Uninitialized variable, random value
A := 42;
Put_Line (Integer'Image (A));
end Foo;
A : Integer := 12;
begin
Put_Line (Integer'Image (A));
Foo(A);
Put_Line (Integer'Image (A));
end Outp;
This will still give the uninitialized variable warning (typically can and should configure the compiler to turn that into an error, not a warning).
You can make variables in and out by saying that (literally). This will do what Steve expected:
with Ada.Text_IO; use Ada.Text_IO;
procedure Outp is
procedure Foo (A : in out Integer) is
begin
Put_Line (Integer'Image (A));
end Foo;
A : Integer := 12;
begin
Foo(A);
end Outp;
Also, added in a recent version of the language (as part of 2020) you can simply use 'Image directly on an object saving you a bit of typing : ). And let me let you in on a secret Ada programmers don't talk about or put in examples - you don't have to type the Identifier at the end of the procedures!
with Ada.Text_IO; use Ada.Text_IO;
procedure Outp is
procedure Foo (A : in out Integer) is
begin
Put_Line (A'Image);
end;
A : Integer := 12;
begin
Foo (A);
end;
I was told that adding the identifier to the end of blocks is just a good practice, since the compiler can tell you if you misread the nesting and wrote the wrong name.
Yes, the text explained how I should write this, my surprise is that I can get undefined behavior. And that the text says that this may, but is not guaranteed to, warn.
On Twitter the other day, someone suggested that this is because, when Ada was first made, this kind of analysis was truly to expensive, and so the guarantee was not made, and they're sticking to backwards compatibility, and modern implementation should basically always warn. That seems reasonable, but I have no idea if it's correct. I assume most real-world Ada scenarios treat warnings as errors.
To be clear, buggy in that it can sometimes not detect correct assignment, and require you to add some unnecessary assignments to shut it up. Not in that you can ever read an uninitialised variable.
That is a bit of a theme in Java. The type inference often has the same problem.
(Although the type inference is also actually unsound)
Hub, is that supposed to not be the case with C#? Because I've definitely had that experience at least once, of knowing a variable is initialized and the compiler not "getting" it until I added some semantically redundant formality.
It had processing constraints and it probably lacked some too like c interop. But largely it has the same target as rust right? Back when rust first got started was there someone on the team that knew Ada well in order to take lessons learned. It seems kind of crazy if there wasn't. It would be like Tesla not having anyone from a traditional car company involved in initial design.
In general, I have a rule of thumb: if the question is "does Graydon know about $LANGUAGE", the answer is almost always "yes." I haven't specifically spoken to him about it, though.
>Back when rust first got started was there someone on the team that knew Ada well in order to take lessons learned. It seems kind of crazy if there wasn't. It would be like Tesla not having anyone from a traditional car company involved in initial design.
Or like Go only taking into account C, Limbo, and CSP.
It’s a good opportunity to point that Ada defines “bounded errors” and “erroneous execution” as distinct things.
TLDR: reading uninitialized data in Ada is safer than in C.
Reading an uninitialized OUT argument is a bounded error, which is much less dramatic than C’s undefined behavior: the semantics is that you’ll read an arbitrary value (which is obviously bad as far an program intent is concerned), but otherwise the language constraints still hold.
This is very different from erroneous execution, which is very similar to the famous undefined behaviors in C, in which all bets are off and anything can happen.
Ah thank you! As I dig into the reference material, I’m sure I’ll gain this kind of nuance, but I appreciate you pointing this out! That indeed does also make it less dangerous.
I learned Ada because I took a new job back in 2008 (at Boeing, doing spacecraft modeling and simulation) and discovered on my first day that I would be using Ada. Naturally, I was expected to just pick it up on my own (Not complaining, that's pretty much how it goes these days).
My mother (who found it amusing I was going to be coding Ada in 2008) gave me her old Ada books from the 80s (her employer at the time sent her to an actual course to learn the new DoD mandated language, back in the days when employers invested in their people), which I still have. I ended up programming in Ada up until 2012, when I managed to get a job using Java.
The language itself I rather liked (better than Java, for sure). It's the only language I've ever used that tended to produce programs that worked correctly on their first run (getting them to compile was the difficult part). The aerospace industry OTOH, I don't miss.
From my experience it's true in python (ie not a static type system). Removing the distinction between compiling and running makes this point even stronger.
This is not at all my experience, neither with my own code or code other people produce. Unless the problem is extremely trivial the solution is very unlikely to work without a few test runs. The bigger point in all of this is that statically typed languages at least have some kind of check mark they can put on your code to say "Yeah, at least the types make sense".
They also encourage designing with types in order to enforce business logic, which is something you don't get in any of the dynamic languages.
Agreed. Have written a lot of code in Ada and Python, I have taught both of them. The fact that Ada code often works first time is something almost every student notices at some point. I have far more experience in Python, and I don’t think I’ve ever made non-trivial code work the first time.
The trick is to produce programs that also run correctly on their second and third run, and multiple other runs where the user is someone other than the creator with different ideas for the inputs.
There isn't anything special about the first run, other than emotionally.
Also, if we define "run" as everything that happens when you feed that source program to the machine, then your first run actually bombed with compile errors.
You can't sit there pretending that the compile errors are the only mistakes you made, such that your first compile-error-free run that made it all the way to program startup and through to successful termination is also bug-free.
If you were that good, you wouldn't be making trivial errors flagged by a compiler.
Well, there's a bit of a problem in how you're qualifying things. For example, certain things that aren't obviously handled by the type-system might be.
One example would be loops and off-by-one errors. For the case of For-loops on arrays Ada's solution arguably does so via the type-system; in Ada arrays "know" their own length, start- and stop-index and these are query-able via attributes.
So, given Function Sum( Input : Integer_Array ) return Long_Long_Integer you could for-loop on the parameter, querying the 'Range attribute -- yielding a possible implementation of:
Function Sum( Input : Integer_Array ) return Long_Long_Integer is
Begin
Return Result : Long_Long_Integer := 0 do
For Index in Input'Range loop
Sum:= Sum + Long_Long_Integer( Input(Index) );
End Loop;
end return;
End Sum;
And the entire problem is avoided via the type-system.
At least three people ITT have said something similar to this. Can you elaborate about what is so bad about working as a software developer in the aerospace industry? Or would that require breaking all sorts of NDAs?
I worked in defense for 10 years then left. I'm assuming its similar to the defense industry I guess (Radar and we were a Boeing sub contractor).
There a few things I don't miss:
1) It can be a little stressful, knowing that your software is controlling things that if wrong could go bad (people's lives are at stake). The strong process we had makes you abstract that away, but still its serious work.
2) Yesterdays technology tomorrow. We were using stable releases from years ago on hardware I couldn't buy in a a language hardly anyone uses (we were an Ada/C shop). I do like Ada, but it made it harder for employees let go to find new work.
it was somewhat satisfying when the end result got built and it was operational.
My software probably running today, somewhere. Even though I left a while ago.
I have a few more points but yours are a good start.
It's software work run by hardware companies. They don't schedule or budget or staff correctly. They often put engineers (of any sort) into decision making positions that should belong to computer scientists (or at least those trained in programming). Writing software is often treated as "just typing" when it's really an engineering and design activity.
Waterfall is also pervasive as a project management methodology. Even "modified Waterfall" (Vee model and others) are still subpar. What's frustrating is that, on the physical engineering side, they actually get the idea and value of prototypes and iterative development/design. But back to my first point, they still view software writing as a manufacturing activity, and not a design activity. So software shops get compared to the production line and not the engineering offices.
Regarding 2: Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. And we don't have the money (from customers) to hire the old timers, they're enjoying retirement too much.
> Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them.
Exactly this. I got stuck doing Ada near the beginning of my career. Took forever to extricate myself from that trap.
It's mind-numbing "code-to-spec" work. You aren't involved in the design or architecture (that is done several levels above you by "System Engineers"), you are given a highly detailed spec (sometimes so detailed it amounts to pseudo-code) that really doesn't allow any room for creative problem solving. The last aerospace job I had basically consisted of translating matlab script written by the scientists into Ada code (and God forbid you find a problem with one of the formulas a self-important PhD came up with).
You are treated as an interchangeable cog.
Most people who work outside the industry hear "I wrote a simulation model for a spacecraft attitude determination & control system" and think I was doing some really cool, challenging stuff. But as a software engineer, you really don't get to use your brain.
That reminds me of my dad's recollections of working with Engineers (of what branch, I'm not sure) in the oil refinery he worked at for ~30 years.
He was a pipefitter and he almost said what you just said word-for-word on a regular basis. If he had any corrections—well—he's just a lowly pipefitter, he can't be correct. Then he'd go out, work to their spec, the system would fail and he'd have to be called back in for overtime to fix it when they adjusted the spec to suit the problems he originally pointed out.
Ah. Well while a refinery is technically in the category of manufacturing, my father wasn't part of the oil refining process itself.
He was initially construction, and later maintenance on—well—all of the pipes.
So the situation wasn't as iterative. It was more, for ex:
* We need a new line for X process.
* Draft plans for new line.
* Receive [unwanted] feedback from fitters familiar with existing lines (having been in and out of them for n years)
* Disparage feedback and double-down on drafted plans
* Fitters implement plans
* Line fails (a number of times this step has nearly cost people their lives)
* Feedback of failure reverts to engineers
* Redraft plans with practical considerations applied
* Fitters implement fixed plans
AFAIU that even somewhat aligns with lean manufacturing—in that they adhered to the designed process according to the authority, and when defects were found they iterated.
I think the main complaint is that the fitters at this point act as almost an extension of the machine itself explaining why something will not work, and the given authority rejected any input at the outset—acting as the old priest caste, if you will.
I worked briefly for Toyota (subman. Toyoda Iron Works) and the process wasn't much different. The stakes were just lower as the parts were smaller, cheaper, and faster to adjust. If I, as an operator, attempted to raise issue with the engineering team I would have been laughed out of the room in the same way. †
† the engineering team had us set every M part aside for inspection 2-3 times a day so they could come check calibration. There was no other direct feedback loop that way from ops.
This is why I'd much rather be doing the Matlab modeling simulations and analysis as the first step of the project and would prefer to stay away from the actual implementation part. You get the creative fun without the hard part of tracking down bug.
You aren't involved in the design or architecture (that is done several
levels above you by "System Engineers"), you are given a highly detailed
spec (sometimes so detailed it amounts to pseudo-code) that really doesn't
allow any room for creative problem solving.
Maybe there is something wrong with me, but it sounds amazing. Compared to
“Agile Enterprise Software Development” I have to do now, where specs are
non-existent, and developers are also architects, QA, DevOps, and managers, the
job that you've described is Heaven.
Why not swap jobs? Your pitch to the aerospace company is "I've got extensive experience in software development, but I'd like to work in a more rigorous environment with people who have extensive experience in solid engineering practices, and apply my skills to safety-critical problems that will affect millions of people."
I did an internship in college at a company that wrote avionics software, and it taught me that I didn't really want to do that. My job is actually a step beyond "agile enterprise software development" in ambiguity - I'm a founder, which means that not only are my specs non-existent, but my product, customers, and business model are too, and my job description also includes customer development, sales, marketing, interaction & visual design, and enough legal to avoid completely fucking things up. But I've found that I like the highly ambiguous environment where nothing's nailed down and everything's a problem that needs to be solved in a hacky way yesterday.
Luckily the economy is broad enough that people can move around to the work that suits them best. Take advantage of that - if you find you really don't like a sort of work, do something else!
I probably would if I was a US or EU citizen. I live in Russia, and our aerospace
industry… has issues, to say the least, and I've heard that US companies tend
to be vary of Russian nationals. Thanks for the advice though, and good luck
with your enterprise!
It's not just Boeing, though. Formal training, at least in my limited perspective, is seen as a luxury now.
A related point is that training used to signify a ramp up time for an employee with an unfamiliar technology. Employees didn't go onto projects until they passed through a training course. Companies now expect zero ramp up time. Hence, they pass over highly qualified software engineers, who may not have a lot of experience in a particular technology, to get less experienced engineers who don't need training in the technology.
>My mother (who found it amusing I was going to be coding Ada in 2008) gave me her old Ada books from the 80s (her employer at the time sent her to an actual course to learn the new DoD mandated language, back in the days when employers invested in their people), which I still have.
The fact that most employees don't invest in their people today, is egregious.
The fact that an employer like Boeing lets their developers "just pick it up on their own" doubly so.
And probably explains some of their quality issues.
This quote from the parent comment made me sad because it is true. With that being said, why is this so? Is it because the internet learning makes it possible to not need training classes to learn a language like you once did? Would the poster's mother prefer a week long off site course led by instructor or going through learnadacore.com (or whatever) at her own pace?
Companies used to invest in their workers, there was an assumption (reasonably accurate for many employers and employees) that people would remain with a company for decades. It was to their benefit to train and improve the employees (NB: Layoffs and other things still happened, not claiming this was a golden age, just different).
At some point (1980s and 1990s in particular) things like retirement benefits started disappearing, replaced by 401k contributions and the like. Employees started moving more between companies so that long-term investment in employees became a problem. If I'm an employer and I spend 3 years getting you the equivalent of a graduate degree in software engineering (training on best practices, training in languages and design, attending conferences) and then you move, I have nothing to show for my effort.
You could add clauses requiring people to work for some period of time after receiving specific kind of training (like if you pay them for a degree) or requiring them to reimburse you if they leave early. But you can't do that for everything.
So companies have assumed that employees are mercenaries, and employees have become mercenaries. In the end, we still work 40+ hour weeks, but get worse compensation and companies refuse to invest in us.
All true, but omits the change in the litigation climate here in the States. Dealing with pernicious, baseless lawsuits taught me never to hire employees again.
>The fact that most employees don't invest in their people today, is egregious.
They don't because the supply of workforce highly surpasses the demand, so it's easier to find another worker. In the domains, where it's not the case (mission critical software) things are different in general.
Ada has always had a reputation for being a more secure system-level programming language, and thankfully security is very much in right now. I think Rust has played a significant role in this mini-resurrection of Ada.
Interesting. I would have guessed that a person contributing to what's touted as the new safest language ever, should already be familiar with prior art in the field. Otherwise one would be prone to unnecessarily reinventing the wheel...
Yes and no. No, if one is designing something that will be state of the art, it is not unreasonable to expect that the designer knows what the previous state of the art is.
But yes, it's weird. First, he's not a designer of the language. Second, there are too many languages for anyone to be intimately familiar with all of them.
And third, there's just this weird bunch of very negative comments. What's up with that? You don't like Rust? (Not you, lukebitts, but the original commenter.) Fine. Don't use it. You don't like the publicity it's getting? You think your language is better? Languages are tools; they're not rock bands. Feel free to like and use yours. Rust doesn't take anything away from that. You don't like Steve? You think he's getting too much attention? He's getting it for useful, informative contributions. You want that kind of attention? Go and do likewise, rather than whining and sniping because someone else is getting attention.
There is a lot of prior art in the field of PLT, and I did not get a graduate computer science degree, where much of this is taught. In undergrad, the closest classes were very broad overviews of programming paradigms generally.
There's also the difference between being familiar and knowing things in-depth; I was previously aware of the broad strokes of Ada and many of its features, but only at a high level. The point is to deepen this understanding.
I mean, I think that's fair: usually, people who can speak deeply about the tradeoffs made for particular syntax or features are the people who were directly involved in making the decisions. I just read the discussions between all of those people. If we didn't have the RFC process, I wouldn't have so much context.
Not everyone involved in Rust needs to be intimately familiar with all the prior art. Further, I'd argue that many of the people involved in Rust know as much about prior art in programming languages than anyone who has been involved in Ada in the last 20 years.
I really like the format of this article. From my very brief experience with Ada it seemed like a very well designed language to me. It's a shame it didn't get popular enough to compete with C and C++.
Yea Ada 95 was set to take off in some sort of way, but Java came out just a bit earlier and crushed it with publicity - and then Javascript was "birthed" in 2 weeks and ruined software forever..
Thats very subjective and I respectfully disagree : ). It was indeed literally created in the order of weeks (not even a full month) and it morphed into a monster quickly and punished users with its many half baked ideas and short-sided design.
If browsers used SmallTalk we would leapfrog about 30 years of reinventing the broken wheel and everyone would be better off (except maybe a few overpaid framework experts).
Assuming there would have been the same rate of adoption. I don't know, is it as easy to learn SmallTalk and do small tasks with it?
The existing ecosystem may have been pretty good, all things considered. Fast ramp-up, with eventual shift into supporting bytecode efficiently so any language can run.
Would you rather be coding around the inconsistencies in the SmallTalk implementations of Microsoft, Google and Mozilla, or just delivering a bytecode package of your code in whatever your favorite SmallTalk implementation (or any other language) is?
Yeah, I don't think so. No matter how bad Javascript is, C would be way worse. Every problem of C ported to the web so all those bad practices that are mostly harmless because they are usually in simple programs with no network access when local program all of a sudden being entirely exposed.
Interesting, in Fall of 1988, University of North Dakota was using Modula-2 as the starting language for their core classes having switched from Pascal in the Summer. The classes were taught on an IBM 370, so students also got to learn the joys of Xedit, IBM terminals, EBCDIC, and batch processing. They only used Ada for the Software Engineering class which I took and was very disappointed in, but not the language which I liked. Lisp was not fun on the VAX.
One of the things I'm a bit ticked about is that they moved the CompSci program from Aerospace to the School of Mines and Engineering. So, just as the drone era is starting they move CompSci to better align with other colleges. What a crock.
Oh cool, a UND Computer Science Alumni hangout. I started with Pascal on the IBM mainframe VSPC in the fall of '83. Batch processing was a shock coming from an Apple ][ background in high school. Was nicer when we got access to the interactive machines like the VAX and the PDP/11. I liked Ada, vaguely remember it being on the VAX.
Still have my photocopied manual for BSD 2.9 on the PDP/11 - never imagined at the time that that Unix stuff would take over the world. Nice to have had that early exposure.
They still had VSPC in 85, but had switched to CMS by 87. The punch card reader / printer ended in 85, and somewhere in a box I got a stack of cards. I took C on the VAX (they bought a AT&T 3B2 somewhere around 90 or 91), and I do vaguely remember Ada was on the VAX also.
My early hate of Lisp was a direct result of them teaching it on the VAX. I was told the VAX had 4MBytes of actual memory and the each Lisp instance took 5. I played poker in the basement of Upson II while the damn thing loaded my program and played more while it ran. Being a lover of Forth at that point, tended to make me think Lisp was a bit of a hog.
Somehow the school got a Cray (I think from a oil company), but they weren't given the manuals right away. The manuals that they printed came from microfiche I had. I'm not sure if any students ever got to use it.
UND did give a unique experience in a CompSci degree.
Never got to touch the Cray, but did some Fortran work on a Perkin-Elmer minicomputer the Aviation department had.
Looking back, in the space of 3 years I got to work on quite a few completely different OSes (VSPC, VM/CMS, MS-DOS, VMS, Unix, whatever the Perkin-Elmer was) and languages (Pascal, 370 assembler, PL/I, Fortran, Lisp, Ada, C)
I wonder if kids nowadays get that kind of broad experience.
I've never used Ada, but some of the graybeards I talk to have said that it's sort of like a predecessor to Rust, at least in some of the same concepts of safety with an emphasis on performance.
With the risk of having my foot planted in my mouth, how "systems-ey" is Ada? Could I conceivably write an OS in nothing but Ada (and obviously a bit of assembly to kickstart it), similar to something like Redox-OS in Rust?
If I remember correctly Ada has some non-sytem things, like its own threads (tasks). For our compiler (Rational) they weren't handled by the OS. Many of the closed source compiler vendors stopped supporting them (probably too much work for too few customers), thus GNAT/ Adacore and actual OS threads.
The ada runtime didn't have a lot of things built in so for our project we built a ada library that would call out to some C code that allowed ada to call to the OS for networking/shared memory/message queues and such. Sizing of types passed from ada to C was important, but wasn't too difficult. Ada also has a record type that seemed to map well to structs.
At some point maintenance was taken over by a startup,
and they moved to POSIX as the primary API as a industry standard (over "RTEMS classic" which was purely Ada). The move to C was part of that I believe.
Fair enough; after some cursory reading, it seems that Ada is objectively safer, so it makes me wonder why there wasn't an "Ada all the things!" movement.
I suppose I'd have to do a big-ish project to know for sure how it compares to C as far as maintenance is concerned.
Ada compilers, versus Rust, used to cost a lot of money. Rust is novel so it doesn't have that historical baggage and reputation associated with it.
People view Ada as verbose (it is, I won't disagree), but it's not that cumbersome (in my experience). And reading it is a pleasure compared to reading a lot of other code. From a maintenance perspective, I greatly prefer it to C.
Static analysis tools and coding practices have made C and C++ safer languages than they used to be, even if they're not innately safe languages (or designed with safety in mind) as with Ada and Rust. So this mitigates the need (though drives up the costs if you want to do it right) to use a safer language in the fields that really care about safety.
In the 90ies there was more a "move away from Ada movement" to avoid that language that the dod forced on the industry and for which it was hard to hire programmers for. Today it would be likely different. Also to stay pure Ada they would have needed to write a TCP stack in Ada, which would have been a big burden I guess.
> why there wasn't an "Ada all the things!" movement
From the history I've read, there was. Then at some point the US DoD the most vocal member, what created a very bad culture on the Ada community (based on waterfall methodologies and government contracts) that everybody learned to avoid.
I suspect toolchain availability was a big thing. Every unix shipped with a C compiler, and if you didn't like it, chances are GCC, which was free, ran on your system too.
AIUI, Ada toolchains have historically been commercial. GNAT was released in 1995, and i don't know how good it was, or is, compared to commercial versions.
A few OS's and a micro-hypervisor done in Ada or SPARK including a high-assurance, secure kernel for Ada apps with strong isolation and leak resistance. Given its main domain, Ada is often used to write bare metal with no OS or for the app (not OS) in a runtime on top of a RTOS. They're usually C and/or assembly since those are dominant for OS work.
Since you mentioned BiiN we can add its predecessor to the list. The iMAX operating system for Intel's first 32 bit processor, the iAPX432 (which Intel likes to pretend never existed), was written entirely in Ada.
I watched the whole Ada process (a series of reports that developed into the language spec). While often criticized at the time of being 'designed by committee' that wasn't really the case, but did have a lot of people critiquing it. It was a great language once you understood how to structure your programs. I think it would have had much better uptake if there were free/open source implementations of it back then, but I don't think the DoD even considered that, so it cost quite a bit of money to experiment with it and very few students had a chance to use it.
I'd argue it is largely true now. If the free version is GPL'd, students can easily use it, but a lot of folks won't want to develop in something that has what is likely to be a high commercial cost. I'm still curious how much they would charge me to use the commercial version to write some scientific software that will likely have no customers. Would they be lenient and not try to charge what they would for a developer at Boeing? I'd love to know as Ada and Spark just seem really cool.
That's what I'm referring to. I believe there is a runtime clause that means a program (Ex: hello world) isn't automatically under the GPL. However, a lot of the Adacore libraries are either GPL or commercial. At least this is how it has been explained to me.
I started reading about Ada back when it was still called "Green". One of my co-workers was one of the (very large) group of people invited to evaluate the candidate languages, and he let me read the draft proposal for the Green language. I learned Ada and used it in several projects throughout my career. It was one of those "good ideas" the Defense Department came up with that didn't quite work out.
At the time the programming language that became Ada was proposed, the Defense Department had somewhere around 700 programming languages being used in various projects. A project looking to add staff had very little chance of finding someone who knew the language being used. They had to hire an experienced programmer and expect that he would be able to get up to speed on the language being used in time to meet the (often unreasonable) deadlines. Ada was intended to replace many or most of those 700 programming languages. It sort of worked for a while. A lot of smart people worked on developing the language, and it was used in a lot of projects. The problem was that it never got wide adoption outside of defense contractor companies and aviation companies, and sometime back the Defense Department dropped the mandate that all new projects had to use Ada.
Ada is still being used in some fields, especially in some Defense Department projects, avionics and air traffic control, but it isn't in the TIOBE top 20 list of programming languages. Unless you're planning on making a career of working on defense projects, Ada probably isn't a language you should think about learning.
> Ada is still being used in some fields, especially in some Defense Department projects, avionics and air traffic control, but it isn't in the TIOBE top 20 list of programming languages. Unless you're planning on making a career of working on defense projects, Ada probably isn't a language you should think about learning.
I guess it depends:
1. Ada, associated with SPARK, constitutes one of the most cutting edge technologies when it comes to automated proof for embedded code. This has encouraged some very cutting edge users such as NVIDIA to invest into Ada/SPARK (https://blog.adacore.com/nvidia-blogpost-announcement)
2. Learning a new language is always interesting. If you are interested in embedded programming in general, there are few languages more interesting than Ada today IMHO. I would probably tell somebody "Learn C/C++, Ada and Rust".
Ada looks extremely similar in syntax to PL/SQL - Oracle's database-side programming language. In fact, I wasn't too surprised to find out that its original syntax was borrowed from Ada.
Wikipedia > "Ada was originally designed by a team led by French computer scientist Jean Ichbiah of CII Honeywell Bull under contract to the United States Department of Defense (DoD) from 1977 to 1983 to supersede over 450 programming languages used by the DoD at that time."
Wow, it is mind blowing to me that 450 different programming languages existed in the late 70's. Do we know what most of these were? Do most exist today or have they been lost to time?
Many were variants or specific implementations of other languages (like Algol), or assembly languages for numerous machines. Remember, this was pre-Internet. A lot of languages were developed because an office needed them for a specific application. Or they knew the theory (enough at least) of a language but didn't have an implementation for their hardware or OS, so they made a new one if they couldn't purchase one. And when you develop the language in tandem with the application, you end up with something custom and non-portable (or hard to port).
This still lives in mainframes to some extent: every mainframe has its own programming language due to differences in hardware and software and legacy.
According to an amazon reviewer [1], Sammet's book Programming Languages: History and Fundamentals (from 1969) already discusses ~120 different languages! And gives code examples in 30 of them.
Back in university (~2005/06) I still remember the "concurrent and distributed programming" course, held by an extremely opinionated professor who was an Ada enthusiast and spent half of the lessons bashing Java and its lack of proper constructs for concurrent programming.
We all at the time commonly agreed to hate on Ada :) (it was not a popular professor)
136 comments
[ 3.2 ms ] story [ 246 ms ] threadHe is not trying to learn Ada.
Don't get me wrong - I'm not claiming the reference manual is a good learning source, for that I would recommend Barnes's book, but that it's an example of a language specification. Having precise specs is a minimum requirement for a safe language. Rust is too complicated as a C replacement but arguably a good C++ replacement. Unfortunately, it's not well-defined (yet) for writing safe programs. Without spec you cannot even tell compiler bugs from intended behaviour.
[1] http://www.ada-auth.org/standards/ada12_w_tc1.html
And yes, the lack of a spec is a weakness in Rust. We've been working on it for a while, and are gonna push it even harder this year.
> Without spec you cannot even tell compiler bugs from intended behaviour.
So this is true, but it's also a bit more subtle than that. For example, "there should be no undefined behavior in safe Rust" is a design principle that, while we don't have a spec, can say if something is a bug or not. (And we do have a few of those bugs.) This is, of course, not as good as a full spec, but guiding principles can really help.
Steve is most likely more familiar with Rust than any other language - which is why I would expect comparisons between it and Ada - but he doesn't go out of his way to insist on Rust's superiority.
Steve if you're around: there is an error I think in your post, you write
> Ranged integers are something people always say Rust is better at than Ada
And I think you meant the opposite ;)
I am trying to understand Ada better. I draw some comparisons to Rust because that’s one of the reasons why I’m reading about it in the first place: people ask questions comparing the two and I have no idea of the answers.
I spent much more than five minutes here, even though the writing is short; the learning website has a lot of stuff! As I said I’m the intro, this is mostly just a log of thoughts. But it was a good solid half-day of investigation. I’ll be doing more of it in the future, too.
And, since you're here, you probably have a typo: “GNATT” in the paragraph about threads should be “GNAT”.
That is the other side of the coin.
If that interpretation comes across as negative, then I think you either must view most interactions with the world as negative or you've somehow managed to surround yourself with "yes" men...
Working in SPARK Ada and Prolog early in my career taught me the importance of understanding what the "philosophy" of a language was in order to use it well. After far too much time spent trying to make them behave like a different language it clicks and then you get productive.
I think it's made me much more tolerant of new languages and more forgiving of my struggles when first learning them. Some times it can take a while to understand what idomatic programs look like in a new language, especially when it's a very differnt model to ones you have been used to.
[1] https://en.wikibooks.org/wiki/Ada_Programming
[2] https://flyx.org/2012/06/13/adabindings1/
It really shows how valuable having that very active and mature core library or managed package library is to a language. I did the same learning path as the prior poster but then just ended up stuck.
(see: https://www.adacore.com/gems/gem-59 )
Playing compiler, the output should be
You can make variables in and out by saying that (literally). This will do what Steve expected:I was told that adding the identifier to the end of blocks is just a good practice, since the compiler can tell you if you misread the nesting and wrote the wrong name.
On Twitter the other day, someone suggested that this is because, when Ada was first made, this kind of analysis was truly to expensive, and so the guarantee was not made, and they're sticking to backwards compatibility, and modern implementation should basically always warn. That seems reasonable, but I have no idea if it's correct. I assume most real-world Ada scenarios treat warnings as errors.
It was a great victory of Java and C# to require this. Java's analysis is "buggy" and C#'s is complete.
That is a bit of a theme in Java. The type inference often has the same problem.
(Although the type inference is also actually unsound)
Or like Go only taking into account C, Limbo, and CSP.
TLDR: reading uninitialized data in Ada is safer than in C.
Reading an uninitialized OUT argument is a bounded error, which is much less dramatic than C’s undefined behavior: the semantics is that you’ll read an arbitrary value (which is obviously bad as far an program intent is concerned), but otherwise the language constraints still hold.
This is very different from erroneous execution, which is very similar to the famous undefined behaviors in C, in which all bets are off and anything can happen.
My mother (who found it amusing I was going to be coding Ada in 2008) gave me her old Ada books from the 80s (her employer at the time sent her to an actual course to learn the new DoD mandated language, back in the days when employers invested in their people), which I still have. I ended up programming in Ada up until 2012, when I managed to get a job using Java.
The language itself I rather liked (better than Java, for sure). It's the only language I've ever used that tended to produce programs that worked correctly on their first run (getting them to compile was the difficult part). The aerospace industry OTOH, I don't miss.
I've had the same experience with Rust. (Never used Ada/Spark myself.)
From my experience that is generally true with languages that have strong static type systems (like Haskell and Rust).
They also encourage designing with types in order to enforce business logic, which is something you don't get in any of the dynamic languages.
Python doesn't force you to do those things if you dont need the reliability for a prototype or one-off code.
But if you want to make a reliable system, even convert your prototype into a reliable system, you can.
There isn't anything special about the first run, other than emotionally.
Also, if we define "run" as everything that happens when you feed that source program to the machine, then your first run actually bombed with compile errors.
You can't sit there pretending that the compile errors are the only mistakes you made, such that your first compile-error-free run that made it all the way to program startup and through to successful termination is also bug-free.
If you were that good, you wouldn't be making trivial errors flagged by a compiler.
One example would be loops and off-by-one errors. For the case of For-loops on arrays Ada's solution arguably does so via the type-system; in Ada arrays "know" their own length, start- and stop-index and these are query-able via attributes.
So, given Function Sum( Input : Integer_Array ) return Long_Long_Integer you could for-loop on the parameter, querying the 'Range attribute -- yielding a possible implementation of:
Function Sum( Input : Integer_Array ) return Long_Long_Integer is Begin Return Result : Long_Long_Integer := 0 do For Index in Input'Range loop Sum:= Sum + Long_Long_Integer( Input(Index) ); End Loop; end return; End Sum;
And the entire problem is avoided via the type-system.
There a few things I don't miss: 1) It can be a little stressful, knowing that your software is controlling things that if wrong could go bad (people's lives are at stake). The strong process we had makes you abstract that away, but still its serious work.
2) Yesterdays technology tomorrow. We were using stable releases from years ago on hardware I couldn't buy in a a language hardly anyone uses (we were an Ada/C shop). I do like Ada, but it made it harder for employees let go to find new work.
it was somewhat satisfying when the end result got built and it was operational.
My software probably running today, somewhere. Even though I left a while ago.
It's software work run by hardware companies. They don't schedule or budget or staff correctly. They often put engineers (of any sort) into decision making positions that should belong to computer scientists (or at least those trained in programming). Writing software is often treated as "just typing" when it's really an engineering and design activity.
Waterfall is also pervasive as a project management methodology. Even "modified Waterfall" (Vee model and others) are still subpar. What's frustrating is that, on the physical engineering side, they actually get the idea and value of prototypes and iterative development/design. But back to my first point, they still view software writing as a manufacturing activity, and not a design activity. So software shops get compared to the production line and not the engineering offices.
Regarding 2: Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. And we don't have the money (from customers) to hire the old timers, they're enjoying retirement too much.
Exactly this. I got stuck doing Ada near the beginning of my career. Took forever to extricate myself from that trap.
You are treated as an interchangeable cog.
Most people who work outside the industry hear "I wrote a simulation model for a spacecraft attitude determination & control system" and think I was doing some really cool, challenging stuff. But as a software engineer, you really don't get to use your brain.
He was a pipefitter and he almost said what you just said word-for-word on a regular basis. If he had any corrections—well—he's just a lowly pipefitter, he can't be correct. Then he'd go out, work to their spec, the system would fail and he'd have to be called back in for overtime to fix it when they adjusted the spec to suit the problems he originally pointed out.
Nothing new under the sun, huh.
He was initially construction, and later maintenance on—well—all of the pipes.
So the situation wasn't as iterative. It was more, for ex:
* We need a new line for X process.
* Draft plans for new line.
* Receive [unwanted] feedback from fitters familiar with existing lines (having been in and out of them for n years)
* Disparage feedback and double-down on drafted plans
* Fitters implement plans
* Line fails (a number of times this step has nearly cost people their lives)
* Feedback of failure reverts to engineers
* Redraft plans with practical considerations applied
* Fitters implement fixed plans
AFAIU that even somewhat aligns with lean manufacturing—in that they adhered to the designed process according to the authority, and when defects were found they iterated.
I think the main complaint is that the fitters at this point act as almost an extension of the machine itself explaining why something will not work, and the given authority rejected any input at the outset—acting as the old priest caste, if you will.
I worked briefly for Toyota (subman. Toyoda Iron Works) and the process wasn't much different. The stakes were just lower as the parts were smaller, cheaper, and faster to adjust. If I, as an operator, attempted to raise issue with the engineering team I would have been laughed out of the room in the same way. †
† the engineering team had us set every M part aside for inspection 2-3 times a day so they could come check calibration. There was no other direct feedback loop that way from ops.
I did an internship in college at a company that wrote avionics software, and it taught me that I didn't really want to do that. My job is actually a step beyond "agile enterprise software development" in ambiguity - I'm a founder, which means that not only are my specs non-existent, but my product, customers, and business model are too, and my job description also includes customer development, sales, marketing, interaction & visual design, and enough legal to avoid completely fucking things up. But I've found that I like the highly ambiguous environment where nothing's nailed down and everything's a problem that needs to be solved in a hacky way yesterday.
Luckily the economy is broad enough that people can move around to the work that suits them best. Take advantage of that - if you find you really don't like a sort of work, do something else!
This gave me a good chuckle!
A related point is that training used to signify a ramp up time for an employee with an unfamiliar technology. Employees didn't go onto projects until they passed through a training course. Companies now expect zero ramp up time. Hence, they pass over highly qualified software engineers, who may not have a lot of experience in a particular technology, to get less experienced engineers who don't need training in the technology.
The fact that most employees don't invest in their people today, is egregious.
The fact that an employer like Boeing lets their developers "just pick it up on their own" doubly so.
And probably explains some of their quality issues.
At some point (1980s and 1990s in particular) things like retirement benefits started disappearing, replaced by 401k contributions and the like. Employees started moving more between companies so that long-term investment in employees became a problem. If I'm an employer and I spend 3 years getting you the equivalent of a graduate degree in software engineering (training on best practices, training in languages and design, attending conferences) and then you move, I have nothing to show for my effort.
You could add clauses requiring people to work for some period of time after receiving specific kind of training (like if you pay them for a degree) or requiring them to reimburse you if they leave early. But you can't do that for everything.
So companies have assumed that employees are mercenaries, and employees have become mercenaries. In the end, we still work 40+ hour weeks, but get worse compensation and companies refuse to invest in us.
They don't because the supply of workforce highly surpasses the demand, so it's easier to find another worker. In the domains, where it's not the case (mission critical software) things are different in general.
Better late than never I guess.
But yes, it's weird. First, he's not a designer of the language. Second, there are too many languages for anyone to be intimately familiar with all of them.
And third, there's just this weird bunch of very negative comments. What's up with that? You don't like Rust? (Not you, lukebitts, but the original commenter.) Fine. Don't use it. You don't like the publicity it's getting? You think your language is better? Languages are tools; they're not rock bands. Feel free to like and use yours. Rust doesn't take anything away from that. You don't like Steve? You think he's getting too much attention? He's getting it for useful, informative contributions. You want that kind of attention? Go and do likewise, rather than whining and sniping because someone else is getting attention.
There's also the difference between being familiar and knowing things in-depth; I was previously aware of the broad strokes of Ada and many of its features, but only at a high level. The point is to deepen this understanding.
(Also, I'm not on the language design team.)
I don't know why but after that talk I always assumed you played a role in some of the language design.
I mean, I think that's fair: usually, people who can speak deeply about the tradeoffs made for particular syntax or features are the people who were directly involved in making the decisions. I just read the discussions between all of those people. If we didn't have the RFC process, I wouldn't have so much context.
http://blogopod.com/image/2014/javascript-comparison-table.p...
The software world could easily go without javascript and be a less toxic, buzzfilled, electron bloated swarm.
The existing ecosystem may have been pretty good, all things considered. Fast ramp-up, with eventual shift into supporting bytecode efficiently so any language can run.
Would you rather be coding around the inconsistencies in the SmallTalk implementations of Microsoft, Google and Mozilla, or just delivering a bytecode package of your code in whatever your favorite SmallTalk implementation (or any other language) is?
BASIC would be better than Javascript.
C would be better than Javascript.
Literally anything else, would have been better than Javascript.
http://archive.oreilly.com/pub/a/javascript/excerpts/javascr...
https://www.destroyallsoftware.com/talks/wat
http://www.javascriptgotchas.com/gotchas/common-javascript-e...
https://medium.com/javascript-non-grata/javascript-is-a-dysf...
https://whydoesitsuck.com/why-does-javascript-suck/
https://softwareengineeringdaily.com/2015/12/09/javascript-t...
http://blog.thefirehoseproject.com/posts/why-im-angry-at-peo...
Yeah, I don't think so. No matter how bad Javascript is, C would be way worse. Every problem of C ported to the web so all those bad practices that are mostly harmless because they are usually in simple programs with no network access when local program all of a sudden being entirely exposed.
Since the university is known for its Areospace program, I guess that made sense to pick Ada as their primary language.
One of the things I'm a bit ticked about is that they moved the CompSci program from Aerospace to the School of Mines and Engineering. So, just as the drone era is starting they move CompSci to better align with other colleges. What a crock.
Still have my photocopied manual for BSD 2.9 on the PDP/11 - never imagined at the time that that Unix stuff would take over the world. Nice to have had that early exposure.
My early hate of Lisp was a direct result of them teaching it on the VAX. I was told the VAX had 4MBytes of actual memory and the each Lisp instance took 5. I played poker in the basement of Upson II while the damn thing loaded my program and played more while it ran. Being a lover of Forth at that point, tended to make me think Lisp was a bit of a hog.
Somehow the school got a Cray (I think from a oil company), but they weren't given the manuals right away. The manuals that they printed came from microfiche I had. I'm not sure if any students ever got to use it.
UND did give a unique experience in a CompSci degree.
Looking back, in the space of 3 years I got to work on quite a few completely different OSes (VSPC, VM/CMS, MS-DOS, VMS, Unix, whatever the Perkin-Elmer was) and languages (Pascal, 370 assembler, PL/I, Fortran, Lisp, Ada, C)
I wonder if kids nowadays get that kind of broad experience.
With the risk of having my foot planted in my mouth, how "systems-ey" is Ada? Could I conceivably write an OS in nothing but Ada (and obviously a bit of assembly to kickstart it), similar to something like Redox-OS in Rust?
[1] http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/node14.htm
Its been a while.
The ada runtime didn't have a lot of things built in so for our project we built a ada library that would call out to some C code that allowed ada to call to the OS for networking/shared memory/message queues and such. Sizing of types passed from ada to C was important, but wasn't too difficult. Ada also has a record type that seemed to map well to structs.
I suppose I'd have to do a big-ish project to know for sure how it compares to C as far as maintenance is concerned.
Ada compilers, versus Rust, used to cost a lot of money. Rust is novel so it doesn't have that historical baggage and reputation associated with it.
People view Ada as verbose (it is, I won't disagree), but it's not that cumbersome (in my experience). And reading it is a pleasure compared to reading a lot of other code. From a maintenance perspective, I greatly prefer it to C.
Static analysis tools and coding practices have made C and C++ safer languages than they used to be, even if they're not innately safe languages (or designed with safety in mind) as with Ada and Rust. So this mitigates the need (though drives up the costs if you want to do it right) to use a safer language in the fields that really care about safety.
From the history I've read, there was. Then at some point the US DoD the most vocal member, what created a very bad culture on the Ada community (based on waterfall methodologies and government contracts) that everybody learned to avoid.
AIUI, Ada toolchains have historically been commercial. GNAT was released in 1995, and i don't know how good it was, or is, compared to commercial versions.
https://www.muen.sk/
https://marte.unican.es/
https://en.wikipedia.org/wiki/BiiN
https://apps.dtic.mil/dtic/tr/fulltext/u2/a340370.pdf
https://www.researchgate.net/publication/220713695_Specifica...
Note: This one is also downloadable on ACM or IEEE. I got it off of one of them. Has good example of Gypsy language for verifying systems.
https://cs.uwaterloo.ca/~Brecht/courses/702/Possible-Reading...
At the time the programming language that became Ada was proposed, the Defense Department had somewhere around 700 programming languages being used in various projects. A project looking to add staff had very little chance of finding someone who knew the language being used. They had to hire an experienced programmer and expect that he would be able to get up to speed on the language being used in time to meet the (often unreasonable) deadlines. Ada was intended to replace many or most of those 700 programming languages. It sort of worked for a while. A lot of smart people worked on developing the language, and it was used in a lot of projects. The problem was that it never got wide adoption outside of defense contractor companies and aviation companies, and sometime back the Defense Department dropped the mandate that all new projects had to use Ada.
Ada is still being used in some fields, especially in some Defense Department projects, avionics and air traffic control, but it isn't in the TIOBE top 20 list of programming languages. Unless you're planning on making a career of working on defense projects, Ada probably isn't a language you should think about learning.
I guess it depends:
1. Ada, associated with SPARK, constitutes one of the most cutting edge technologies when it comes to automated proof for embedded code. This has encouraged some very cutting edge users such as NVIDIA to invest into Ada/SPARK (https://blog.adacore.com/nvidia-blogpost-announcement)
2. Learning a new language is always interesting. If you are interested in embedded programming in general, there are few languages more interesting than Ada today IMHO. I would probably tell somebody "Learn C/C++, Ada and Rust".
http://www.orafaq.com/wiki/Ada
Wow, it is mind blowing to me that 450 different programming languages existed in the late 70's. Do we know what most of these were? Do most exist today or have they been lost to time?
[1] https://www.amazon.com/Programming-Languages-Fundamentals-Au...
Some surviving ones are NEWP and PL/S, if you happen to touch an IBM or Unisys mainframe.