Hacker News new | ask | show | jobs
by MoreMoore 524 days ago
I think what a lot of people miss is that this ripple effect always exists. Whether you have strong types or weak types, it's hard and often impossible to avoid.

All strong types do is make it explicit at compile time (and with static analysis), instead of leaving it to be discovered in tests or at runtime.

This is why I'll use Python for small one-off scripts but anything that will be in regular use I prefer to do in Java. Even though I have many more years of experience with Python.

2 comments

As someone who works in C# and TypeScript, I suspect that people who work in weakly typed languages either:

- Don’t have big projects.

- Have lots of unit tests to cover some of what a C# or Java compiler would have caught through static analysis.

- Don’t even consider doing certain kinds of refactoring (which would be trivial on a strongly typed language) because they have no way of knowing what will break.

4th option, they are just better than you are at managing dynamism.
Even ignoring for a moment that I consider being highly practiced at dynamism a largely pointless skill while strongly typed languages exist, sooner or later a code base which is always growing will reach a certain size where even the very best person in the world at dynamism will have to resort to unit tests to cover what a compiler can do for free, or just accept that certain refactoring or changes to the code base are unreasonably expensive to do with any reasonable level of confidence.
I'm the guy with a huge javascript codebase, written before typescript existed, and I have none of the problems you describe. Huge refactors are also not a necessity in every codebase, if the code was written well to begin with. And so far using typescript in other projects has not produced the supposed benefits a lot of people say are inherent with typescript. There is no magic happening that saves me from writing bad code, because I wasn't writing bad code before typescript. Refactoring isn't all that difficult either, even without tests. But I guess YMMV.
Good code becomes bad when the requirements change sufficiently in ways the original design didn't anticipate.
Great, but that doesn't describe every Javascript project or use of Javascript. If you're describing big changes, chances are a refactor isn't what's needed, a rewrite is. And even when requirements change, it doesn't mean Javascript can't be refactored. It depends on the skill of the team. If you want to hire idiots then you're going to need more than strong types to get anything shipped. I doubt types would really help that much in some places because programmers love to invent their own footguns.
> Huge refactors are also not a necessity in every codebase, if the code was written well to begin with.

If dynamically typed languages only worked well in absolutely pristine codebases that never saw any hacks or poorly thought out solutions, I'm not sure they'd be actually useful in most real-life settings. Of course, people refactor all the time in dynamically typed languages as well.

They probably are also more beautiful too huh?
Is it really too much to ask to use the correct terms here, static and dynamic typing?

Strong and weak are sort of coherent as a spectrum, but they aren't a typology, and they do not in any sense or in any case reduce to static vs. dynamic types. Conflating them is not useful: I can make a good case that Julia's type system is stronger than C's, but Julia is dynamically typed and C is statically typed.

There's no reason to keep doing this. It's a malapropism, we could just.. not say that. Especially in a thread which is specifically about types.

Sorry, you're right of course. I was on the phone and in a hurry and just took the terminology of the comment I was responding to without thinking about it. Static and dynamic typing are the correct terms. Strong/weak typing is the difference between Python and C++, which are (inversely) dynamically and statically typed respectively.