On paper, this all makes a lot of sense.
What is going to happen when these airplanes start falling out of the sky because they are just too old?
50 years is a long time for a piece of machinery. There will be many failure modes that will be discovered in these planes.
The C-130 was thought to last forever. Until about 10 years ago, well used planes being used for firefighting starting having structural failure in flight. Suddenly, organizations flying the older airframes decided that it was no longer effective to take the risk of failure.
Civil aviation does not have the same inspection process that the military does.
The old heavy tankers were all being flown at their limits for decades with nothing more than a dude with a flashlight looking at the insides of them and going "yurp, this is good to go!"
On Air Force aircraft, to include the B-52, thousands of inspectors either look at every single critical part on a regular basis or use random sampling to establish estimated fleet health levels.
I'm willing to bet that each individual B-52 has more paperwork on it and more eyeballs that have seen x-rays and ultrasounds of it than every single aerial firefighting platform in the world combined.
B-52s are basically ships of Theseus at this point. About the only original part left by the time they're retired will be the build plate with the serial number on it.
Firefighting is uniquely hard on airframes. It imposes all sorts of loads on aircraft that they just don't experience in "normal" operation. For maintenance purposes, one well-known (V)LAT operator I'm familiar with treats one hour of firefighting ops as 7 hours of flight time.
Ada will probably go the way of the dodo as Dependent types catch on. It's phenomenal how ahead of it's time it was, and continues to be. Contracts are an absolute killer feature, and I see a lot of people who are otherwise very serious about memory safety scoff about logical safety, not understanding just how powerful that construct really is.
Fair, I guess the list was “languages that I know were popular at one point but I don’t know anyone really using now”.
Ada definitely does seem pretty cool from the little bit I have read about it. I’m not sure why it’s fallen by the wayside in favor of C and its derivatives.
It's easy to get lost in the modern way we look at compilers and toolchains, but it wasn't always like this. Free compilers basically didn't exist 30+ years ago. Certainly none of the free compilers were good. For the longest time, your only options for Ada compilers were priced at government contractor-levels (think $10k per seat... in the 80s).
It's also an extremely complicated language, while C isn't. A single, moderately skilled programmer who can at least make their own FSM parser can write a reasonably complete C compiler in the space of a month. There's no hand-rolling your own Ada compiler. Even just complying with SPARK is a herculean task for a team of experts.
This is much the same reason I'm highly skeptical of Rust as a replacement systems language to C. A multitude of very talented folk have been working on writing a second Rust compiler for years at this point. The simplicity and ease of bootstrapping C on any platform, without any special domain skills, was what made it absolutely killer. The LLVM promise of being easily ported just doesn't hold true. Making an LLVM backend is outrageously complicated in comparison to a rigid, non-optimizing C compiler, and it requires deep knowledge of how LLVM works in the first place.
Ada was mandated by the DoD for a bit. My understanding is that, in practice, this involved making a half-hearted effort in Ada, failing and then applying for a variance to not use Ada.
I actually met a programmer who worked on military jets. According to her, Ada is only used anymore for the older jets that were already programmed in it, and she worked in C++.
No need to be so dramatic. Shitheads will make software fail in any language. Memory "safety" will not help you correctly and in timely manner calculate position of flight controls for example.
One can write reliable, and I mean airtight good enough for medical devices and nuclear deterrence, in basically any even vaguely modern language (think Algol-60 or later). It’s simply a matter of disciplined design and running on hardware that’s sufficiently predictable.
Most aerospace stuff is. The thing is, they have reams of very specific rules about how it's coded, how to verify that code, and how to verify the compiler of that code, and how to verify the code output from that compiler. It's not an easy process to replace, but its proven reliable just by all the commercial planes flying every day without falling out of the sky.
In theory, something like Rust could do the job instead, but they'd still have to verify the entire chain. Rust is for the rest of us to get something half as reliable as that while also being able to write more than two lines of code per day.
Often, I'm sure, but there are large code bases in Ada still. It's a shame, it looks like a really great language I would love. But it's a chicken and egg problem. If only Mozilla had decided on Ada instead of Rust! :-)
The one shop that really used it is now open to C++ and I expect Rust. But their projects tend to last a long time: 3 generations have flown in one of them, etc.
I agree that many modern Fortran codes aren't truly "modern" Fortran, but in my experience most codes have at least been ported to Fortran 90, even if they largely keep a lot of Fortran 77 baggage (especially the type system and indentation!). In all of my experience, I've really only encountered a single Fortran code being used currently that is actually Fortran 77 in the flesh. That said, I still think many Fortran codes would benefit from using more modern features, since so many are stuck in the past and are difficult to maintain for that reason.
Just because it can be measured, doesn't mean it should be.
These 'measures' would be much more useful if they were used to determine the control limits of the software process being used.
'hours from pull request to merge' for an open source project is silly. who cares? 'number of commits a month'? who cares. what is the value of those commits.
why the focus on 'constant churn of software'? I don't see it.
I get where you're coming from, and can see a lot of people seeing it that way.
But to me, metrics like 'PR to merge time' help highlight bottlenecks, even in open source. It’s not just about churn, it’s about ensuring contributions are flowing smoothly. Quality matters, but so does making sure contributions don’t stall.
The commercial aircraft part of McD was dead when the merger happened. The had a cash cow called the "MD-80", which was a derivative DC-9. That had stopped selling.
Boeing got more value out of the defense part of McD.
This isn’t any better. Are you an IC? All you’re probably saying is, “the people that I work with more directly, that share the same organisational context as me, that I personally can relate to, etc are good, and the other ones aren’t”.
reply