Thanks for responding! I really wasn't hoping you'd think my rambling is worth responding to. > Imagine if we put up with bridges that collapsed because "most

Thanks for responding! I really wasn't hoping you'd think my rambling is worth responding to. > Imagine if we put up with bridges that collapsed because "most engineers are nowhere near prudent enough..." Most developers don't develop nuclear reactor control software. And I'm saying this, not because your statement about education is wrong, but because there's a cost-benefit analysis going on, and traditionally correctness was too expensive. This is due to insufficient tools, a very strange mindset ("That seems like a failure of education."), plus the path-dependence of the real world (the whole history of computer programming somehow led to a lot more close-to-the-metal imperative code and programming languages than "here are the correct abstractions and let's see how far can we go with them" ones). Also, as far as I know we need dependent types to be able to easily model a lot of invariants that would help with many kinds of programming errors. (Of course validating safely composable components would go a long way - like that project targeting some subset of Rust, but that's basically what static analysis is. And there's a whole industry that tries to bolt-on this kind of correctness verification after the code has been written.) ... All in all, I'm simply pointing out that the Haskell ecosystem is still not exactly approachable. You say it's because education, and people's choices, and other reasons. (Which is tautologically true.) But that doesn't help much. In my experience programmers get better when tools get better, and it makes sense to learn them, when it gives them sufficient value. (Correctness, productivity, ergonomics, performance, hipness and whatnot, and all of that on a reasonable time-horizon.) This whole comment thread started out from talking about jargon, and about the value of having mathematically exact, precise (correct) concepts as definitions used for everyday programming, and my observation is that programmers and programming as an occupation don't have the need/want for such high level concepts and correctness, and on top of that, even if everyone wants better programming tools, somehow the obvious answer isn't rewrite it in Haskell. Maybe the gap is [stil] too big [in the average case]. Maybe the very strong static typing, and pure FP (and the basically necessary immutability) and jargon, and unfamiliarity is still too constraining, too "expensive" to learn and use.