I am referring to your post arguing for the virtues of declaring static types on everything to benefit refactoring:
And this reaction when I said refactoring really isn’t an issue and very manageable due to sound structuring:
Hence your world vs mine.
I don’t live my life in my editor refactoring type declarations and I don’t want to.
I think of functional programming as being algorithms (mostly reducers over a state) and that they really don’t care what the type is, as long as there is a pattern match on the function or operator (which is still a function pattern match). It’s very much about value semantics and constraints, not static types.
The last thing I want to happen in our ecosystem is getting caught up on manually managing static type hierarchies, type unification, and all the “fun” that brings. Sometimes I may have to pass a Dog, sometimes a Poodle, and sometimes a Gorilla. Do I need to list each of these types everywhere or do I create a “generic” Animal type? Is an Amoeba an Animal too? What about Plants?
I say N-O to where this ultimately leads, and yes I am resisting static type declarations in favor of type inferencing in the hope others can see value in such an approach too rather than thinking classic static types is the only way.
I am saying there is another way through inferencing which can avoid many of the problems of declaring static types.
That is the point, I don’t want manual static typing which is what you seem to be arguing for, and which leads to the maintenance problems I have articulated.
It is quite ok.
I accept that we both have different viewpoints and a significant difference of opinion even though we both desire better compile time checking. That much we can agree on I think.
I knew it was likely inevitable and I’m still learning some stuff! Also, thanks to