6 ms·
> with strong typing "Refactoring is easier". This is incorrect. I can't tell if you're just trolling, but have you ever done a large refactor in a dynamically
by xedrac 7y ago
> with strong typing "Refactoring is easier". This is incorrect.
I can't tell if you're just trolling, but have you ever done a large refactor in a dynamically typed language such as Python? It's a runtime minefield, taking a huge amount of testing effort to gain any level of confidence that you got it correct. In a language like Haskell or Rust, it's usually as simple as getting the thing to compile.
- wellpast 7y agoThis is exactly my point. If your goal is to optimize for a future “big refactor”, then your problem is a present-day skills problem, not a PL issue.
- bam365 7y agoIt seems like you're arguing that dynamically typed languages are best because they don't get in the way of programmers who are good enough to pretty much never screw it up in the first place. Am I misunderstanding you?
- wellpast 7y agoMore or less, yes. But I also worry about the team that thinks a statically typed language is going to save them. I think at the end of the day you have to do this job well or you don’t get any guarantees. I’ve seen people make equal messes in strongly typed languages and dynamic; the PL is not the thing. But one thing that is true is that strongly typed languages tax you strongly; anyone who says otherwise (and enthusiasts often do) is lying even if to themselves as well.
- lacampbell 7y agoIME a code base with high test coverage lets me refactor far more securely than an expressive static type system. Static typing is useful, but if I had to pick one it would be tests all the way.
- wellpast 7y agoI will say that immutability helps a lot. Clojure is dynamic but immutable-oriented, and refactoring with deferentially transparent S-expressions is a delight— + you don’t need type system for this.
- verttii 7y agoThe cost of a high test coverage could be an additional 3x lines of code for the tests. While you still need tests with an expressive type system you can basically cut the code coverage to a fraction. And maintain the same level of confidence in refactoring.
- lacampbell 7y agoWhile you still need tests with an expressive type system you can basically cut the code coverage to a fraction. Where on earth do you get the idea that static typing lets you cut the code coverage to a fraction? I am going to need specific examples to believe this claim.
- lmm 7y ago> Where on earth do you get the idea that static typing lets you cut the code coverage to a fraction? I am going to need specific examples to believe this claim. I don't know how I can give a "specific example" when the example is effectively my whole programming career (most of which was proprietary codebases). But it matches my experience: code with static types and a fraction of as many tests ends up with fewer production bugs than code with substantial test coverage in a dynamic language. Think about how much of your code contains actual business logic rather than just plumbing, and imagine never having to test the plumbing parts, only the actual logic. For most functions there's only one possible thing for that function to do, the type tells you that it does that thing, so there's no need for a test. E.g. a (parametric) function that takes a set and returns a sorted list can only ever sort that set or return an empty sorted list, so the only thing you need to test is that the returned sorted list is non-empty. https://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... gives some examples (in Java - deliberately using a language where types are very inefficient to show that they're effective even then).