I understand the practical ramifications quite well: It's complicated as all hell to implement some very simple, and well known algorithms which rely on mutati

I understand the practical ramifications quite well: It's complicated as all hell to implement some very simple, and well known algorithms which rely on mutation and explicit memory management. Take, for example, QuickSort: "sorta looks like quick sort" http://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell http://www.haskell.org/haskellwiki/Introduction#Quicksort_in... "actual quick sort w/ in place memory mutation" http://www.haskell.org/haskellwiki/Introduction/Direct_Translation http://www.haskell.org/haskellwiki/Introduction/Direct_Trans... The short, few-liner Haskell version is beautiful. It's also not the same algorithm. So then you whip out the larger "direct translation" version and, suddenly, you're wishing for C. This story repeats itself over and over again. For example, try implementing the Fisher-Yates shuffle. Now, in practice, you don't need in-place swaps. And you can argue code style and YAGNI and pre-mature optimization and practical implications and day to day use and parallelization and whatever etc. Yada yada yada. I'm not saying there is anything wrong with Haskell. I'm saying that foundation of Computer Science lies in the study of data structures, algorithms, and computability. Software Engineering basically boils down to a search and optimization problem: Find the data structures and algorithms which (1) minimize the weighted average of costs and (2) maximize the value that the solution generates. Haskell's approach to Software Engineering presupposes the cost savings to isolating mutation (and other purity concerns) as a requirement. I'm simply advocating future language developers consciously address the problem of finding those optimal data structures and algorithms in minimal time, with an eye for the fact that data structures and algorithms are a fundamental law of computation.