What's Worked in Computer Science

How do you know? By "worked" the author means "has unambiguously turned out to be a good idea with very significant benefits". That some people really like something and are able to write good, working programs with it doesn't mean it's "worked" in the sense discussed.

First, each of these languages is "functional" in a very different way, so much so that even their inclusion in the same category is tenuous. Second, none of these (except maybe Erlang) has been used extensively enough in large-scale projects to give us a definitive answer regarding the actual benefits.

That functional concepts are finding their way into the mainstream is very true, but some of these have also been associated with OO for a very long time now (in fact, they've been a part of OO longer than three of the four FP languages you list have existed). Smalltalk, the most OO of OO languages, had anonymous functions from the beginning, and would tell you that anonymous functions are just as much OO as functional. TCO is not very mainstream, and as Guy Steele demonstrated, is just as relevant for OO as it is for functional. Also, adoption of some concepts doesn't mean FP as a paradigm has worked (the bigger problem is that FP doesn't even have a definition; it is continuously redefined to mean whatever it is people associate with languages that call themselves FP).

In short, we're not sure quite yet, hence "maybe".

Trying to google Capabilities+Computer+Science turns up a lot of noise.

The solutions where capabilities are truly most promising have no embedded competitors. I'm looking at things like SELinux here. Few other solutions (except e.g. Macaroons) are actually capable of making correct authorization decisions in scenarios involving 3+ principals: the competition is broken, and vicariously, so are most authorization systems which try to solve 3+ principal authorization problem correctly.

You may as well be arguing that memory safe / garbage collected languages lost to C circa 1995. C is broken and programs written in C will always be full of holes as compared to equivalent programs in memory safe languages just in the same way as authorization systems not built to handle 3+ principals will make wrong decisions. This is why it's 2015 and we're still dealing with CSRF.

If you implement SELinux at your job like I do, and have some informed criticism about how Capsicum is unneeded because SELinux is great, I'd love to hear it! But I'm guessing that isn't the case... I am also guessing it's an area the OP is not particularly informed about.

As someone who's once been there (not power plants but ensuring the safety of systems whose failure may endanger the lives of many people), it's much more complicated than that. If by "results oriented" you mean "look at nothing but the bottom line", I think you're disrespecting a lot of people by assuming (with little evidence) that this is indeed the process. I can tell you that it isn't, and not just in safety-critical software. Of course, there may be some bad people as in every field, but I've seen no evidence to suggest that "decision makers" are on average any worse at their job than anyone else. We were result-oriented in the sense that we preferred not to let anything that didn't have industry-proven benefits into our system.

Ironically, it is sometimes the safety-critical systems (well, some classes of them) that can afford to take more risk, because they have the resources to build a new system and then run it in production alongside the old one only it's outputs are not piped to real actuators (we called it a "shadow system"), and do that for a long time (a year if not more) before flipping the switch. "Plain" software usually can't afford to be so patient.

> The whole point is that good decisions lead to bad outcomes and bad decisions lead to good outcomes all the time

Of course. Our disagreement is on what constitutes a good decision.

> politics pushes people to react strongly to results, ignoring this fact.

I don't think so. I've been a decision maker (though not alone, and sometimes didn't have the final say) in both safety-critical settings and less risky ones, and it's not politics but often the lack of a better metric. I can assure you that we've extensively studied the reasons for each failure or success to the best of our abilities and never looked just at the bottom line if we had any more information. We took quite a few calculated risks (changed our numerical algorithms, chose the yet-unproven-at-the-time real-time Java over C++ for a safety-critical, hard-realtime system and more), but always opted for things that had been proven in the industry (or tried to prove them ourselves). It's not politics that led us to that, but lots of experience. That's because things that work in the lab fail in the field more often than not. Ignoring that fact is just stupid (or, rather, shows a lack of experience in the field), especially when the stakes are high (and they're always high to some degree in the industry).

Besides, why risk anything on something that doesn't have strong evidence of significant benefits? We look at people like you to show us those benefits, and if you don't -- or you think you've found clear benefits, but those benefits simply aren't significant enough for us -- why take any risk? We gladly risk quite a bit when there's good reason to believe the payoff would be large enough. Even that (let alone battle-testing) is something some of the things you'd put in the "works" category have yet to demonstrate.

That is something we in the industry tell researchers all the time. If you're content doing pure research, do it and don't whine about us not adopting your work. If not, and you would like us to use your stuff, there's a lot more you need to do than your pure research, like extensive applied research with empirical results, and, most importantly, it requires understanding the industry's needs (e.g. in the industry something is not adopted because it is "better"; it will only be adopted if it is better enough to offset the adoption cost plus associated risk). But what you can't do is have it both ways -- do only the pure research and whine about us not using it. Doing so shows a lack of understanding of what the industry is, and reflects badly on those researchers much more than on the industry (which, BTW, has made amazing achievements in software).

The industry adopts brand new stuff all the time when the researchers do their job properly (well, to be fair, for some it's a lot easier). Suppose I'm a decision maker and someone says to me, my new sorting algorithm would be 20% faster for the data you're sorting. Well, the adoption cost is nearly zero, I can test they payoff rather easily, there is risk involved but it's mitigated by my ability to switch back, so I find the 20% payoff to be high enough and I go for it. This happens all the time. In fact, millions of people will soon switch to a brand new -- and rather ambitious -- GC algorithm (granted, one that's been tested for nearly a decade). But then some other guy shows up and says, my new programming language would make your development better. How much better? I ask. Much! he says. Talk to me in numbers, I say. By how much would my development cost be reduced? Hmm, he says. I'm not sure; 30%... maybe? So I look at the adoption cost (huge), risk (very high), and find that 30% to be rather low, but let's suppose it's borderline good-enough. Only he's not even sure about the 30% because he has no experience with large systems and he's never even tested his claim. Maybe it's 5%, maybe 70% and maybe -20%! So let me tell you that in that case, I will be very results oriented, look around, see that practically no one else uses that language and those who do see payoffs nowhere near high enough, so I pass[1]... and that's when you say I'm motivated by politics, hostile to academia and afraid of new stuff.

[1]: True, it isn't fair. Technologies with high adoption costs incur a much higher testing burden and are required to yield much higher payoffs than those with lower adoption costs. But that's no one's fault, and just the way it is. Researchers in those fields should keep on working, realizing that their payoffs would be high enough to be adopted by the industry every 20 years instead of every 5 as in low-adoption-cost cases.