I absolutely agree that programming in the large is about the time dimension, or, as Google puts it [1], "Software engineering is programming over time." But I

I absolutely agree that programming in the large is about the time dimension, or, as Google puts it [1], "Software engineering is programming over time." But I do think the author recognizes that - their argument is about the fact that despite Haskell giving you less short-term productivity it also discourages worst practices that will impede future programmers. However, that still leaves us with the truth you found, that you don't see this in practice. There should really not need to be any "convincing." And it's not that people aren't allowed to use it: we all know of stories of an old application that is inexplicably business-critical, isn't in a language the company otherwise uses because someone got away writing it in a language they happened to want to try, and hasn't been rewritten, and that language is basically never Haskell. I've been pondering Google's observation and I think my conclusion is that software engineering is the art of making good APIs for future programmers. The core part is still that software engineering is the sort of programming where someone (possibly future-you) will base their work on your program, and therefore the value of the program is in how it is written and not just whether it gets today's job done. But the future programmer can always choose not to base their work on your code and do the same work you did, and the goal is that you should be making their job easier. And, in turn, the future programmer may or may not be doing software engineering, which is to say, they may just wish to consume your base code and solve that day's problem without making things better for yet another future programmer. (This is common when a project either temporarily or permanently does not expect much future development; you need to keep it running and respond to slight changes in business requirements, but it's not worth doing the engineering work to generalize your task.) In this view, it's actually important that your language facilitate both best practices and worst practices! If the language forces you to write good code all the time, then it's very hard to make things easier for future programmers, especially future programmers who are not trying to do software engineering. If it takes me five days to solve a problem well in Haskell because I can't do any worst practices, but adapting it to next month's problem also takes me five days because I still can't do any worst practices, I didn't do any software engineering - I didn't make my job any easier. One of the interesting things about Python and Ruby is that they're languages that very much optimize for worst practices (short, untyped scripts with no abstractions and dynamic variable definitions and so forth), but they also happen to give you facilities for best practices if you want. Both of them have grown very good optional type checkers in the last few years, mostly written by large tech companies that have been programming in the very large in those languages, in both time and space, and needed to deal with their code. Both of them have optional linters. Both have facilities for good abstractions like optional record types - but both also give you plain old maps. And so forth. (By contrast, consider shell, which is fantastic for programming, that is, solving immediate problems, but completely unsalvageable for software engineering, that is, building APIs for others. There is no good way to bring order to hundreds of thousands of lines of shell, even if you wanted to.) So, the Python/Ruby software engineer can build APIs for the future Python/Ruby programmer by using best practices in the long-term core they write, but the future programmer is absolutely free to use worst practices to solve their immediate problem if indeed they're solving an immediate problem. Or they can contribute to the long-term core using best practices. That seems like the happy medium here. And it's also very interesting that, as far as I know, they never set out to do this explicitly; they just happened to have just enough facilities for abstraction that over time people built more as they found themselves needing them.