I agree in principle, but here's two big (and heavily opinionated) real-world phenomena that push back:
1. As a die-hard function programmer believe most everything out there is designed poorly---not because everybody incompetent but because anything working with poorly designed languages and libraries must itself necessary be less well designed. Bad abstractions breed other bad abstractions! To write near-ideal software usual an excise of ripping up the foundations---so a lot of refactoring.
2. We learn good design best by refactoring. When righting new code, functionality and elegance are competing goals, but when refactoring elegance can be tackled in isolation. Furthermore, refactoring is an opportunity to prove (to oneself and others) that given abstractions indeed make code better. Finally, it's hard to distill good design to principles beyond "don't repeat yourself" and "make bad things impossible", but refactoring offers an opportunity to try things and see what works.
I've found it next to impossible to get it through ( some ) people's thick heads that refactoring is not a sign that something was done wrong the first time around.
>> We learn good design best by refactoring.
Exactly. This is often when the true value of a design pattern becomes crystal clear in an applied ( rather than theoretical ) sense.
I haven't done any statically typed functional programming. I'm interested in some parts of functional programming, mostly as they related to replacing raw logic with functions.
Well C++ definitely rewards care and effort in a similar way. Haskell and Rust (to get specific) are good for me cause they allow one to write much more air-tight abstractions, raising the upper limit on what my constant refactoring can yield. No more of that "all abstractions leak" bullshit!
1. As a die-hard function programmer believe most everything out there is designed poorly---not because everybody incompetent but because anything working with poorly designed languages and libraries must itself necessary be less well designed. Bad abstractions breed other bad abstractions! To write near-ideal software usual an excise of ripping up the foundations---so a lot of refactoring.
2. We learn good design best by refactoring. When righting new code, functionality and elegance are competing goals, but when refactoring elegance can be tackled in isolation. Furthermore, refactoring is an opportunity to prove (to oneself and others) that given abstractions indeed make code better. Finally, it's hard to distill good design to principles beyond "don't repeat yourself" and "make bad things impossible", but refactoring offers an opportunity to try things and see what works.