This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation.
It requires you to be perfect at Waterfall ( https://en.wikipedia.org/wiki/Waterfall_model ).
Real-world problems laugh at such idealism.
This is simply bs. Haskell is actually a language (that I know of) where, IMO, your initial choices matters least. And that's because it's gives you great refactoring experience.
Yeah right! I don't have to refactor extensible code.
Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code.
Why are you spending so much of your time refactoring code? Because your language isn't extensible!
Not a fan of TDD, eh?
Not a fan of silver bullets.
But your comment is still odd. Refactoring seems to be a core tenet of modern programming (regardless of TDD). In TDD in particular it's a central part of how you work, and so your remark sounds odd unless you also claim you don't believe in TDD :)
Don’t know what the state of Haskell refactoring is now but it looks like until very recently “great refactoring” was “change one thing and then manually fix compiler errors”.
Point me to something like that, for, lets say, Python. For example to error when I misuse return value of a function. Or when I decide that this string is no longer a string but a customer name. Or when my function will call IO operation, but it's not allowed to do so. Or when I add new field to a record and its not fully constructed somewhere.
- We are a statically typed language with significantly better support for refactoring than anything else out there
- But...
- Let's say Python
Let's say Java, why don't we? A language with significantly better support than "change one thing and manually fix compiler errors".
See IntelliJ's capabilities: https://www.jetbrains.com/help/idea/refactoring-source-code.... (there are 23 subsections)
And even Python's capabilities are significantly better than manually hunting through compiler errors (though obviously not as extensive): https://www.jetbrains.com/help/pycharm/refactoring-source-co...
On topic: Oh, these are great and I wish Haskell had more of that.
But these are "dumb" actions, really. How about:
* writing terrible code to get something working, then breaking it down and putting it back up as something production ready
* changing core data structure and updating all the code that uses it
* solving some problems in separate projects and combining them together
* copy-pasting code from another project and adjusting it to a current project
All of the above of course without running the program once in between, without changing the desired program's behavior etc.
And no, I don't think you can't do that in Java, I just think that Haskell is better at it.
* writing terrible code to get something working, then breaking it down and putting it back up as something production ready
Automated: Extract method, move code, pull members up/down, rename etc.
* changing core data structure and updating all the code that uses it
Depending on what exactly you're changing. From as simple as automated "update type signatures of all affected functions and methods" to automated "rename" to yes, hunting down compiler errors
* solving some problems in separate projects and combining them together and
* copy-pasting code from another project and adjusting it to a current project
Once again, depending on what and how you combine, using the things from above.
There are more powerful tools than "oh, let's run the compiler for each change and manually fix all the errors". The flow should be "let's run all the automated refactorings and then run the compiler to see if those missed something". And these automated refactorings are often reversible with a simple Cmd/Ctrl-Z.
Ah, yes. And many of these are available even for dynamically typed languages (but not as powerful and sometimes with caveats, for obvious reasons).
Java and Python are simply not languages that encourage (or even make possible) writing code that is easy under those changes. In Haskell you have immutability (if something is declared, that's its final value, so I can simply move it around), purity (code that is basically context independent), dumb data structures (no "enterprise boolean" with nontrivial internal state and ceremony to initialize), functional (no code attached to mutable data that may implicitly require data to be in special state), no nulls in flow control (that are invisible to a compiler, so yea good luck moving function around that expects no nulls), ergonomic creation of data/types (so you don't have strings/integers everywhere that are opaque to a compiler).
There is no contest, really. Maybe with some modern languages like Rust or TypeScript, but I haven't tried those.
However, most changes/refactorings I usually encounter are due to trivial problems that can be automated. And I'd love to have those tools for FP where a lot of changes are still just that: rename a function or a field in a data structure, extract a function, rename/move a module, update type signatures etc.
However, it looks like the stronger the static typing, the worse are the tools :) Not enough manpower to take care of them, perhaps?
As for Haskell, I think, it's a combination of manpower (so popularity, really) and the fact that the compiler wasn't developed with tooling in mind.
Thanks for conversation, stranger, and have a nice day!
This is interesting because another popular argument against Haskell is "Haskell's type checker can only check trivial properties that can be automated".
Either automating trivial things is valuable or it's not, and the anti-Haskell camp seems not to agree on which!
In Ruby it's changing the attr_accessor line.
In Haskell objects are immutable, so you need lenses.
Only if you choose to isolate all side effects from each other. Actually Haskell makes refactoring really easy, so you can adapt your implemention to changing requirements easily.
I wanted to make point that that #4 is not true.
Amortizing the up-front cost of design, into a continuous cost of refactoring every time the requirements change doesn’t make the original claim false.
You are still paying the price of rigidity.