> If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.
All of this is up to the implementation in practice. The codebases I work on generally follow the pattern that exceptions may be thrown but may not be caught*, and thus they practically serve as terminate. And we absolutely get stack traces in our core dumps (Linux, both GCC and clang), and basically all of the complex debugging I do starts with a coredump stacktrace.
* We follow this pattern for a few reasons, (1) it is generally safer for us to assume that libraries we consume (STL included) will behave as expected with exceptions enabled, (2) "don't catch exceptions" (or if you must, catch the as close-to-throw as possible) is a simple way to avoid exceptions-for-nonexceptional-cases control flow, and (3) most of the C++ codebase is exposed through bindings in Python, and propagating errors as exceptions is the only Python-friendly way to handle it.
There are a bunch of other problems with this comment, but this part in particular is laughably wrong.
> Our ships are designed to operate in the Pacific or North Atlantic, not the Persian Gulf.
Nearly every type of ship in the USN has spent considerable deployment time in the Persian Gulf. They are absolutely "designed" for deployment there. What "prevents" their deployment there is that it does not make tactical or strategic sense to put highly capable warships during a war in a tiny waterway when said warship is capable and effective at operating from outside said tiny waterway. Put a CBG in the Persian Gulf and it becomes just about as expensive to defend as an air base on land (much more so, given the logistics involved). That same CBG operating in the Indian Ocean against the same targets has tens of thousands of square miles in which to operate and avoid detection and attack, and never need to fire a missile in self-defense.
In January 2026, the US Naval Institute wrote [1]:
> Rising ocean temperatures will change operating environments in every theater. But planning for specific effects requires first understanding the fundamental dynamics of warming seas. Two key indicators are the average sea surface temperature and the number of extreme-temperature sea surface events called marine heat waves.1 (See sidebar.)
> These conditions will affect four major aspects of Navy operations at sea: crew, equipment operability, ship maintenance, and environmental intelligence.
and (emphasis added)
> Carrier strike groups have reported environmental challenges while operating in the Arabian Gulf, Persian Gulf, and Gulf of Oman. Firsthand accounts from sailors describe crew members unable to stop sweating on the flight deck or in engineering spaces.
and
> As sea surface temperatures climb, ships will require more maintenance. Higher temperatures accelerate corrosion of ship hulls and ballast tanks and can lead to increased biofouling along the hull and in heat exchangers.
As for:
> That same CBG operating in the Indian Ocean against the same targets has tens of thousands of square miles in which to operate and avoid detection and attack, and never need to fire a missile in self-defense.
"Crews can't stop sweating on the flight deck" is exactly like saying "the middle east is hot and people sweat in the sun there". It has very little to do with the ships and everything to do with a climate that is hot (which, rather obviously, effects almost everyone in the region). If you want an actual example of a meaningful operational problem cause by a warship not suited to operations in hot waters, see the Type 45 (and even that is finally being fixed).
> That's just another way of saying what I said: they can't operate at close range and must instead use stand off weapons instead of, say, gravity bombs.
It really isn't. Outside of rare cases where mid-air refueling is unavailable, standoff weapons are used to reduce exposure to enemy air defense, not to increase range. Your airwing uses exactly the same gravity bombs to strike a target 10 miles from the carrier as they do at 50 miles or 100 miles or 200 miles.
Famously, of course, not at all the case, with Enterprise, Saratoga, and Ranger all surviving. Yes, losses of pre-war carriers were severe (Lexington, Yorktown, Hornet, and Wasp).
Anyone who describes hydrocarbon fuels and high-test peroxide oxidiser as a stable and proven combination is a charlatan trying to sell you something questionable. If you want a proven liquid fuel combination that works in missile environment conditions with well-behaved ignition, Hydrazine/UDMH+N2O4 is the king.
Solids are better from a storage and deployment standpoint in almost all cases; anyone making a sincere case for liquid fuels should be making it on the basis of munitions that are best designed around them (notably, of course, most of the long range cruise missiles that have received the most hand-wringing about stockpile depletion are already air-breathing jet-fueled). The actual stockpile issues wrt solid rocket fuel are high-performance SAM/ABM interceptors, and those would require complete redesigns to make liquid-fueled equivalents.
> Solids are better from a storage and deployment standpoint in almost all cases
The article says this. Liquids are better from a production perspective. In the Cold War, storage and deployment dominated. That need isn’t gone today. But it’s supplanted in priority by the need to be able to rapidly produce these munitions.
> those would require complete redesigns to make liquid-fueled equivalents
Again, the article acknowledges this. It’s saying we can do that faster than we can get another AP production facility online, and even then, we’d still be unfavorably production constrained compared to China.
Solving a chemical manufacturing problem in the US has GOT to be easier than taking on additional operations and mechanical complexity for every single missile in combat theatres.
The article cites permitting and procurement snafus for why it's so hard to stand up new AP plants, but the same procurement process would apply for new liquid engine designs with all their moving parts, no?
> Solving a chemical manufacturing problem in the US has GOT to be easier
Why? We are currently scaling rocket-engine production for the launch industry. We aren’t doing the same for anything like AP. I don’t think anyone would blink at a well-resourced effort to build a new small-satellite launch vehicle in a couple years, for instance.
> Satellite launch is so much easier than storable SAM/ABM
Sure. But the hard part of SAM/ABM doesn’t need to be in the propulsion for many use cases, e.g. those where heightened readiness states are predictable. We’re using storable missiles for use cases where that storability isn’t adding any value.
Where exactly is that storability not needed? In the VLS cells of USN warships? In the missile canisters of field-mobile SAM batteries being driven cross-country (which, for survivability on the modern battlefield need to be moving a lot more)?
The only real cases a non-storable SAM/ABM is viable are where the target being protected is so small and so known that (1) all missile infrastructure on/near the target is vulnerable and (2) sufficient advance warning is available to handle liquid fuels as needed. There is really only one case of this: Guam. I think there is a case that a dedicated unique-to-Guam liquid-fueled SAM/ABM farm would go a long way to addressing stockpile and magazine depth concerns.
Which means US servicemen handling extremely dangerous chemical oxidizers under fire. This stuff reacts explosively with everything, including common metals and anything organic.
Admittedly, it allows you to sidestep the regulatory hassles with handling those chemicals in the US, we can order troops to do all sorts of non-OSHA bad ideas, but wouldn't it be easier to just do the dangerous chemical handling on US soil, on a 9-5 in factory?
Are we talking HTP+Kerosene or UDMH+N2O4 here? The article said HTP in which case you have 1% breakdown to water per year which will be an ongoing problem for stockpiles. N2O4 is nastier but more stable when contained.
Either way, you're going from "dangerous chemistry in the plant" to "dangerous chemistry in the plant, through a global logistics network, and in operations". The solid rocket fuel is pretty stable after it's built, just don't light it on fire or drop it too hard. Room temperature oxidizers are terrifying.
To be clear, I know a good amount about rockets and less about missiles. I’m standing on this hill. I won’t die on it.
> Are we talking HTP+Kerosene or UDMH+N2O4 here?
I’m thinking kerosene or even methane. UDMH is a toxic mess.
> you have 1% breakdown to water per year which will be an ongoing problem for stockpiles
Sort of? It’s a nuisance. Not a dealbreaker. Certainly not an issue compared to running out of munitions.
> to "dangerous chemistry in the plant, through a global logistics network, and in operations"
The dangerousness of an energetics plant is not comparable to that of managing HTP. (And at a certain point, LOX becomes economically competitive for base protection.)
> solid rocket fuel is pretty stable after it's built, just don't light it on fire or drop it too hard
It’s great while you have them. Then you run out. That’s the current situation. Lots of perfect for a while, and then rationing while the enemy gets free hits.
Put two militaries against each other, one which can mass produce and fuel liquid rockets against one with fewer solid ones, and the former has an attrition advantage while the latter has a readiness one. If one only has solid-fueled rockets being made at a tiny clip, where the AP all comes from one plant, they become an easy adversary to defeat.
> I’m thinking kerosene or even methane. UDMH is a toxic mess.
Methane is absolutely out because of pressures/temperatures involved in keeping it liquid for any useful length of time. It would require both significant on-site gas storage as well as a gas compression plant to produce liquid methane on demand, both considerable additional targets (and very fragile ones at that). Kerosene + additives (e.g. RP-1 and JP-8) is the only really viable storable "friendly" hydrocarbon.
In practice, Hydrazine/UDMH + N2O4 is going to be much easier to handle safely than you think (Hydrazine itself is probably safer to handle than Ammonia, and there's a lot of Ammonia handled out there). You fill and seal the tanks at assembly, and outside of rare leaks the handling is fairly benign. Most notably, basically every major military has, as some point in the 20th century, done so - including aboard USN carriers, famously a very skeptical customer from a handling standpoint. Even today, every single F-16 (about 2000 in active service with about 25 operators around the globe) carries Hydrazine in the onboard EPU, and those operators are prepared to service (and handle leaks) safely.
While they aren't pleasant chemicals by any stretch, Hydrazine/UDMH + N2O4, by virtue of its immediate hypergolic behavior, is actually quite well-behaved from a fire/explosion safety standpoint, which is practically a larger concern than toxic fumes (consider how many other things in and around a combat environment can produce toxic gasses). Hydrazine/UDMH + N2O4 ignite promptly on mixing, and thus don't accumulate in an explosive mixture to be ignited later like alternative fuels and oxidizers.
I feel like the whole point is what's most economical/practical. Liquid engines are better than solids on specific impulse, throttling/relighting, this is great if you're going to orbit but solids are better for transport/storage and the downsides are minimal for interceptors or boost-stage for ramjets.
What liquid situation changes that? What liquid would be more economical? My instinct is towards minimizing operations outside of the US, keep it simple stupid and just go solid, but could it actually be reasonable to have, say, sealed containers of fuel/oxidizer of whatever type inside the missile and you "pull the pin" to uncap them and start mixing in the ignition chamber?
> could it actually be reasonable to have, say, sealed containers of fuel/oxidizer of whatever type inside the missile and you "pull the pin" to uncap them and start mixing in the ignition chamber?
No. The economics really shine if you can mass produce dry engines and then fuel them on site, ideally with locally sourced or even on-based manufactured oxidizer (if you’re going LOX).
Barring that, though, not being limited by AP would make the last comment’s hydrazine path acceptable.
The munitions that (1) are currently solid-fueled and (2) represent a stockpile depletion issue are all SAM/ABM interceptors. The only new liquid-fueled missiles worth the development effort are a liquid-fueled ramjet equivalent to the MBDA Meteor and air-breathing hypersonics.
> It’s saying we can do that faster than we can get another AP production facility online
Oh boy, have you seen how long SAM/ABM development takes? The critical munitions that actually need to be designed here would be liquid-fueled equivalents to THAAD, PAC-3, SM-2, SM-3, and SM-6. Not yet-another-cruise-missile which is already liquid-fueled.
> critical munitions that actually need to be designed here would be liquid-fueled equivalents to THAAD, PAC-3, SM-2, SM-3, and SM-6
Correct. If we design it now we can build it at massive scale within a decade. If we stick to the current, broken model we might be able to 4x in the same timeline.
No, if a process allocates an infeasible amount, malloc fails and the process needs to deal with the failure (which is what already happens, "malloc doesn't fail on Linux" is only really true for smaller-than-page-size allocations). The point being made is that the system should account conservatively for all memory that can be used, not just the optimistic underestimate that overcommit enables (i.e. the plane should always carry enough fuel for contingencies, and landing with extra fuel is a good outcome).
> And I'm sure bipedal walking was also basically solved in the 1980's.
It isn't even efficiently solved now, in the general case. Bipedal walking on approximately flat surfaces with minimal geometry constraints is basically solved, but complex terrain and/or constraints on foot placement require slower methods that wouldn't really be considered "solved".
That's right, environment conditions play a huge role and modulate efficacy to a great degree. And the same applies to pathfinding with osbstacle avoidance otherwise we'd all have our robot maids and self-driving cars already.
But we have the theory down pat, is what I was trying to say. There's a lot of engineering still that remains to do, but e.g. Dijkstra's algorithm... works.
I had a longer comment in place of the one I made above, that tried to caveat this a bit more. I also linked to this survey:
A Comprehensive Survey of Path Planning Algorithms for Autonomous Systems and
Mobile Robots: Traditional and Modern Approaches
That's just one review, there's more. The striking thing is that there are so many approaches for robotics path planning. That means a) it's a problem for which many solutions are known but b) there's not one dominant approach. One reason for that is what you point out, that it doesn't always work that well.
And that's just path planning, i.e. figuring out where to walk. Gait is a whole other ball game, figuring out how to get there.
The reality of robotics is that the existence of the theory often means little about practical feasibility. I have myself joked about problems being solved in the '80s, but the joke is really something closer to "all of the interesting problems in planning and control were solved in the' 80s and known to be intractable", because the theoretical complexity is just prohibitive.
The last 40 or so years haven't really moved the needle on theoretical complexity, but we have developed new methods and improved existing methods (and also computers have gotten massively better) such that a much larger subset of the problem space is actually practically solvable. Even still, it is almost trivially easy to go from a practically-solvable problem to a practically-unsolvable one, and much of the confusion that exists in the popular understanding of robot capabilities is the result of the solvable/unsolvable line being so close and subtle.
On the topic of bipedal (and quadrupedal) locomotion, I think you could actually argue that we very much do not understand how to solve the problem, and exhibit #1 is that basically everyone (Boston Dynamics included) is giving up on MPC-based control and adopting RL-based controllers which seem to work better but are much less comprehensible from a theory standpoint.
I think the move to RL-based controllers is just the latest trend tbh. There's papers to be written, so they will be written. I can't say I have seen a huge improvement in performance and they suffer from really poor generalisation certainly compared to planning and MPC.
I agree with your comment- the planning problem is in PSPACE and while there are techniques like relaxations and width-based search that allow large portions of it to be solved there are areas that remain intractable (although I'm not sure about width-based search; I haven't really tried it). But we have to distinguish between different kinds of task.
Robot navigation is a broad field, but just going from point A to point B is really hard to see as an open problem. You stick a PID controller on a robot and set some waypoints and it will happily roll, float or fly between them. Or, like I say, just do A* or Dijkstra's. Problems begin if there is anything between A and B. If it's a solid, immovable object, then that's OK. If it moves, things start to get tough. If you want a big chunk of metal moving safely in a dynamic environment full of independent agents that also go about their goals... good luck with that. Terrain, weather, visibility etc just add variables to the problem and that's bad, variables are bad, we don't want variables.
So when I said "solved" above I was really talking about "walking between arbitrary waypoints" as per the OP's turn of phrase. I might have played a bit fast and loose with "arbitrary" because obviously if one waypoint is in a tornado and the other in a volcano... But navigating between waypoints is a solved problem. It's what you do while you navigate between waypoints that's the open problem [1].
Bipedal (and quadrupedal) walking is similar but that's more robotics and less planning and so I know less about it. Still, Asimo could almost walk up a flight of stairs on its own in the '80s. Again, if you assume nice, clean, flat laboratory conditions, we know how to get a legged robot to walk. I know, I've played around with NAO and a tiny robot dog from Hiwonder. They can walk around, dance, get up on their own, shake your hand, play with a ball etc. How cute. Then of course there's all the kung-fu fighting, somersaulting, cartwheeling etc robots doing the rounds on social media. But again the problems begin as soon as you want those kinds of system to do something useful in the real world, where they need to physically interact with solid objects and moving obstacles.
So what I'd say to hedge a bit on what I commented above is that basic path planning and bipedal gaits are solved but those turn out to be only part of the problem of robotic autonomy which is itself still wide open [2].
Which is a good thing. We gotta have something to work on.
_______________________
[1] Of course, sometimes all you need to do is go boom at the far waypoint. I think sometimes people forget we have very effective autonomous navigation systems: specifically, self-guided missiles. When it's fine for a system to destroy itself when it reaches its target and causing maximum damage is a bonus, that simplifies a hell of a lot of stuff that can't be taken for granted with, e.g., self-driving cars. But, at the end of the day, a self-guided missile is exactly a system that goes from point A to point B autonomously. Fire and forget, that sort of thing.
[2] And when I say "bipedal gait is solved" I'm no saying I like the solution. I'm still smarting that my Passive Dynamic Walking project didn't get funded.
Not necessarily. Depending on angle and water depth, multi-return LIDAR can give you returns from both water surface and the road surface beneath, in the same way multi-return LIDAR can produce returns from vegetation and the ground beneath.
> The FDA's approval process is stymied by a CYA culture that fails to adopt the risk profile it needs to in order to potentially save large contingents of sick and dying.
Except the history of FDA approval here is that it has been too accepting of drug candidates for Alzheimers with very weak evidence of efficacy and serious side effects. This particular field would probably be better off if the FDA took a harder position on efficacy, rather than deferring to drug companies and patient/caregiver groups that desperately want something.
I would like to see the FDA get rid of their binary "Approved" approach.
Instead, at the start of a treatment on a patient, an analysis must be done of all available data, and the treatment only allowed if the error bars put it within the realm of the best treatment available.
That means at the start when not much data is available, it is easy to give it to a patient. But over time as more data comes in it gets harder and harder to do so if the treatment is ineffective or harmful.
Data should be collected and analyzed in real-time - it should be a matter of hours between some life event like a death feeding into the dataset used for decisions on new patients.
The struggle is the high level regulatory bodies (with the exception of aberrations such as the current admin's approach to appointment) generally select for individuals with a low risk tolerance. Low risk tolerance is generally incompatible with speed - it's a miracle the covid vax and treatments were approved as quickly as they were in 2020.
Biggest example of this risk aversion is the peptide craze going on (the most famous of which are GLP-1 antagonists). It's pretty much a wild west where people read a low-sample animal study, and buy a drug that's "for research only, not for human consumption" off of a compounding pharmacy in China.
Few human studies because even if you have willing and enthusiastic volunteers it's too expensive and creates legal liability. And the FDA cannot approve it without a high bar of evidence (for effective treatment and low risk) and costly, time consuming reviews. Because of this, there is a black market for the things and people are basically being their own test subjects.
> The struggle is the high level regulatory bodies (with the exception of aberrations such as the current admin's approach to appointment) generally select for individuals with a low risk tolerance.
This may be true, but I don't think it's the major driver of conservatism. Two thoughts/observations:
1) Bodies like the FDA face a strongly skewed set of incentives. If they take a risk on something and people get hurt, they face huge public criticism. If they take a risk on something and it's all fine, very few people care or notice. As such, they are strongly driven to not make a public mistake - which drives ever more conservatism.
2) FDA can actually be innovative compared to other health authorities. Breakthrough therapy designation, Project Optimus, Project Frontrunner, and others - show this. However, they've got a strong 'not invented here' mindset - they flatly refuse well-meaning individual innovations from pharma companies, if they're not compatible with FDA's guidelines. And they're heavily bureaucratic, meaning the innovations that do appear are usually following years of process (which probably links back to #1).
What you say is something that is actually already happening.
There is no longer a binary approval/non-approval status. Drugs and treatments that address terminal conditions often get special status. Drugs for rare diseases definitely get special treatment.
In addition, many studies now use continual data collection and evaluation. If the results are very good or very bad, that can be recognized much more quickly and with fewer people exposed to risk than previous types of studies. Reaction to negative events doesn't happen in hours, but it isn't all that far from that.
This does happen. SAEs are reported in real time, and they do halt trials sometimes. Also, there is often a condition of approval that requires ongoing data collection for adverse events post-approval.
The depressing part is that these "modern practices" were essentially invented in the 1960s by defense and aerospace projects like the NTDS, LLRV/LLTV, and Digital Fly-by-Wire to produce safety-critical software, and the rest of the software industry simply ignored them until the last couple of decades.
All of this is up to the implementation in practice. The codebases I work on generally follow the pattern that exceptions may be thrown but may not be caught*, and thus they practically serve as terminate. And we absolutely get stack traces in our core dumps (Linux, both GCC and clang), and basically all of the complex debugging I do starts with a coredump stacktrace.
* We follow this pattern for a few reasons, (1) it is generally safer for us to assume that libraries we consume (STL included) will behave as expected with exceptions enabled, (2) "don't catch exceptions" (or if you must, catch the as close-to-throw as possible) is a simple way to avoid exceptions-for-nonexceptional-cases control flow, and (3) most of the C++ codebase is exposed through bindings in Python, and propagating errors as exceptions is the only Python-friendly way to handle it.
reply