> I think this is why functional languages don't tend to get traction while the multi-paradigm languages do. Given a choice between purity and pragmatism, most engineers will pick pragmatism.
Well, it's obvious to the working corporate-employed programmer, not so obvious to the ivory-tower theorist.
The short argument is that the entire point of a program is to take inputs and produce outputs. Making the consumption of inputs and the generation of outputs a second-class citizen in the language with the goal of "purity" just makes it that much harder for a program to perform its primary task.
> Making the consumption of inputs and the generation of outputs a second-class citizen in the language with the goal of "purity" just makes it that much harder for a program to perform its primary task.
You have this backwards. I/O is second class in every language except Haskell and languages with type and effect systems. Those are the only languages where it's a first-class citizen, which is to say that I/O computations are values that can be passed around, interpreted and otherwise recognized or operated on in various ways.
The problem is that people are used to the second class status and don't understand the additional power first class status gives you, or the patterns needed to make it extensible and maintainable.
Well, it's obvious to the working corporate-employed programmer, not so obvious to the ivory-tower theorist.
The short argument is that the entire point of a program is to take inputs and produce outputs. Making the consumption of inputs and the generation of outputs a second-class citizen in the language with the goal of "purity" just makes it that much harder for a program to perform its primary task.