Comment by seanwilson | Hacker News Reader

Comment by seanwilson | Hacker News Reader

Parent Full thread

> Changing one parameter or type on a class or function to refactor, and then just following the chain of compiler errors, reaching the end, and seeing that everything just works exactly how you want it to was a big eye opener to me.

Yup, "following the chain of compiler errors" mostly makes refactoring straightforward. Dynamic typing is fine when the codebase is small enough to keep it all in your head so you know what the impact of a change is. Once you've got enough code or you're not completely familiar with it, the cycle of changing the code, running it, diagnosing errors, changing the code some more while hoping you caught everything etc. becomes tedious and impractical. Simple renaming a field in JavaScript, Python or PHP is a nightmare if you want to guarantee nothing broke so I can't relate to how people don't appreciate strong typing. You're basically badly doing the job of the compiler manually by trying out all code paths yourself looking for errors.

We tend to use tests for just this case. You change anything you want, then see which tests break, and fix all the places.

I definitely agree that dynamic typing doesn't scale as well as static typing, though.

> We tend to use tests for just this case. You change anything you want, then see which tests break, and fix all the places.

Why not tests + static typing? Getting tests to point out breakages is attempting to do job the compiler can do for you but not as well. If you renamed a field in some places but not others for example, you'd have to rely on good enough code coverage to catch this plus deciphering a failing test is nowhere near as easy as a compiler error that pinpoints the exact line causing the problem. Tests take time to write and static typing is giving you many tests for free. You also miss out on automatic refactoring tools and autocomplete.

> rely on good enough code coverage to catch this

Wait, you don't enforce 100% coverage? (Sorry, couldn't resist ;))

I actually mostly agree, static typing is a huge boon for productivity, and certainly allows for less experienced (both new programmers, and new to the project) developers to become productive on a new codebase faster.

However, I think dynamic typing forces a certain familiarity with the codebase that can prove really useful. Yes, it slows learning down, yes it rules the lower end of the spectrum of developers out, but there are still benefits to this required familiarity.

Obviously, when codebases reach a certain size, this falls over. And even before they do, the drawbacks may be more than the benefits, but it's still something to consider.

My personal opinion right now is that these benefits don't exceed the drawbacks, that static languages are better, however I tend to flip flop back and forth on this every other month (or project).

> However, I think dynamic typing forces a certain familiarity with the codebase that can prove really useful. Yes, it slows learning down, yes it rules the lower end of the spectrum of developers out, but there are still benefits to this required familiarity.

Useful in what way? I don't see how static typing is going to make you less familiar with a codebase. Good use of types provides a certain amount of documentation for free as well.

> Wait, you don't enforce 100% coverage? (Sorry, couldn't resist ;))

I know this was a joke, but 100% coverage only means you've covered every code path, not that you've tested every case. Static types allow you to prove the absence of certain classes of errors. Of course, you still need tests for all of the classes of errors that your type system doesn't cover.

My intuition would stay that static typing would rule the lowest end of the spectrum of developers out, and that dynamic typing would allow that lower end to get started coding much more quickly, until reaching the scale at which the false economy becomes apparent.

But if you're writing tests (and writing documentation that documents the expected return type of methods, etc.) you're doing an error-prone replacement of work the compiler can be doing for you.

While I've always preferred static over dynamic, Powershell is what finally got me to actively disliking dynamic languages. Not strongly disliking, but enough that I'll put up with a bit of pain in order to use a static language over a dynamic language.

I made the mistake of trying to build a system in Powershell because the ability to remote into windows boxes was core to it. That was a mistake I didn't see coming.

Reply on news.ycombinator.com