Hacker News Reader

Comment by twblalock | Hacker News Reader

Think of static typing as an autogenerated set of unit tests that ensure that for any given function, all arguments of the wrong type will be rejected.

For example, if a function accepts a string as an input, test it by passing in all other possible primitives and classes and ensure that the behavior is strongly defined and results in the expected exception class.

Then realize that if you haven't written all of those tests by hand in a dynamic codebase, you don't actually have code coverage. Anyone who works on your codebase could pass you an argument of the wrong type, and it might be in a code path that is rarely invoked and you will find out it's broken in prod.

View on HN

> Think of static typing as an autogenerated set of unit tests that ensure that for any given function, all arguments of the wrong type will be rejected.

My point is that you wouldn't write such unit tests in the first place. Unit tests should test behavior, not types.

How a function reacts to the wrong type being passed as an input is part of its behavior.

Otherwise the behavior is undefined, and that is really bad.

That's just a less likely case of giving a function the wrong input values, which is also undefined.

So no it's not much worse than usual.

No, it's actually different, because in a statically typed language it would not even be possible to write code that would pass the wrong types of inputs, because it would not compile!

Also, if there are input values of the right type that cannot be handled properly, that should also be tested! That is the kind of thing tests are for!

Example: you write a function that divides two numbers. It's not possible to divide by zero. You should absolutely have a test that passes in a divisor of zero and asserts that some kind of custom DivideByZeroException is thrown. If you know that certain inputs are out of range, you should test them explicitly -- otherwise you're being sloppy. If there is a large number of inputs out of range, you should test all of them, and you can use a `for` loop if you have to.

The difference is, if you have a valid input out of range, that is all you need to test -- the language itself takes care of all the "wrong type" tests for you. Otherwise you have to write them yourselves, and if you don't, you don't actually have good coverage. I understand that it is customary in dynamic languages to not write those tests, but that is merely another argument for the superiority of static typing.

If you pass the wrong input values to a function, it will in 99% of all cases give you the wrong result, throw an exception, etc.

Passing the wrong type is considerably rarer than the wrong value so need not be considered.

Well one programmer using dynamic typing can deliver the output of three programmers who use static typing.

That why people use dynamic typing, from a business perspective it's a far more compelling argument than the one you are making.

What you are saying all breaks down with larger codebases.

A codebase with 1000 people working on it benefits dramatically from static typing. Everyone who has tried to do the same thing with dynamic typing has learned that. And quite a few companies that started off with Python had to rewrite everything in Java.

If you honestly think that nobody ever passes the wrong type, you've never worked on a complex dynamic codebase with a lot of people. It happens all the time.

The more modern solution is to break the large codebases into self contained microservices. In which case dynamic typing scales indefinitely.

I've worked on dynamically typed codebases for a long time. Passing the wrong type is very rare. I mean how would the code pass the unit tests if it was passing the wrong type?

How are the interfaces between these microservices defined? Without types? Lol

The interfaces do have types (and also proper versioning) but the internal code to the microservices does not.

Think about that for another second and see if you can spot the obvious huge flaw there.

I think you will be disappointed with the basic types: int, str, bool being used in one line per 1000 lines of code.

> Passing the wrong type is considerably rarer than the wrong value so need not be considered.

Passing the wrong value doesn't just happen randomly. It happens because of errors in logic many of which can be caught with a strong static type system.

But most can not.

K, I'll take your word for it.

Then static typing is merely a terrible set of unit tests not worth implementing.

Reply on news.ycombinator.com