"Magic that sometimes works and sometimes doesn't is fun for small projects..." SQL has a magical compiler. It's actually a lot more magical in some ways than

"Magic that sometimes works and sometimes doesn't is fun for small projects..." SQL has a magical compiler. It's actually a lot more magical in some ways than GHC, because good implementations use statistics on the actual input data and a sophisticated cost-based optimizer. And SQL is certainly suitable for large projects. I mostly program in C, so you don't have to convince me that predictability of code fragments has its benefits. But it has a lot of costs, too. Sometimes, good performance fundamentally requires a lot of complexity, so if your compiler is not helping you (being "magical") then the complexity is forced on the programmer. Once the programmer takes on that complexity, they also take on the burden of additional maintenance cost and additional cost to add new capabilities forever. So, you have to consider whether you really have a net increase in predictability by using more predictable (but less helpful) tools. People complain about garbage collection and virtual memory and NUMA for the same reasons, but those are ubiquitous now -- dealing with the annoyances simply takes less effort than managing the memory yourself. You could argue that laziness, in particular, is not worth the trade-off (though it has worked out pretty well for SQL).