Hacker News Reader

> The thing with typing is that it gets hyped, but in practice, it matters very little.

I guess typing is moot when all the code and the tests are written, but having types sure does help while you're writing that code and those tests.

It helps avoiding typos, but most are well indicated by the code highlighting of the code editor, even for Python.

It helps to use the right data type when 'connecting' two objects. But it constraints the usefulness of code that can rely on the behaviour of the objects instead of the type.

It clutters the code: you have to read (and write) way more text. Which makes errors more probable.

It forces to think about primitive data types, so steals time maybe better spend thinking about higher data structures (list, dictionary,...) or algorithm.

YMMV.

I did not mean output as in the actual result of running the code. I mean looking at two pieces of code that functionally may do the same thing but the code itself is written in a completely different style.

One of the other differences I have seen, but didn't specifically mention, is unit tests themselves. The web app probably has a ton of them. The Jupyter notebook probably does not. Which is fine, the language is being used for different purposes.

But an advantage of having those types in place is that you can do the static analysis to ensure everything is being used correctly within your codebase. And then you can have your unit tests concentrate on the actual usage rather than other stuff. There is no need to check for / test with a null value when you already know that function is never being passed a null value. And adding those hints has helped me many times with catching edge cases before they even happen where the existing unit tests were never going to hit that edge case.

> aim to have 96%-99% code coverage

I find this sort of optimism both cute and frustrating. The reality is that almost no company is willing to foot the bill for such a level of code coverage as it makes writing the application take easily 2x as long. Sure, it'll theoretically be more provably correct, but the cost difference isn't easy to swallow. The reality is more like you have good path coverage for a small subset of business critical code with the rest of the code getting tested at a more macro level with integration and functional testing. And that's not even touching on the theory vs reality of how much better the code will be with those unit tests. Writing _good_ tests is harder than most people think. Writing tests that have good path coverage and good input fuzzing is _really_ hard. Writing a test that checks the box for 'code coverage' can be done trivially in many cases, but provide no real value.

>The reality is that almost no company is willing to foot the bill for such a level of code coverage as it makes writing the application take easily 2x as long

This is only true if the codebase uses some highly inefficient setup that makes writing/running unit tests a pain.

And a general corporate policy for many companies, including big ones like Amazon, is to aim for >90% coverage with strongly typed languages like Java, regardless.

> Both science code and web application code don't really need typing or really type hints.

Where "science code" is "this python script I'm working on for my PhD and no one else is ever going to use it", sure. Where "web application code" is "I need to get an MVP out for Tech Crunch Disrupt", sure. Where neither of those things are true - if your grad student project code becomes the basis for sucessive grad students' projects, or gets popular in industry, or if the web application code underlies a company for a few decades - for sanity's sake you want type hinting. Tests only go so far, and if I have to run a piece of code's test cases before I know what the code actually does, instead of just reading it, something smells rotten.

Unit tests might be exhaustive in 'lines of code covered' but never in 'possible inputs'.

That is, did you remember to check for null? Did you remember to write a test for floating points in languages that just have generic number types?

I don't see the value in relying on unit tests to enforce types.

It might be possible, but it relies on the programmer to:

1. Remember all of the types (was this an int? Or a float? Or a int | null union?

2. Implement exhaustive tests for each type

3. Remember to update the tests when something changes.

4. When reading code, if the types emitted are not specified, having to examine the unit tests to determine the type limits.

And the advantage of this is that it saves me a few keystrokes so i can write:

X = 5

Instead of

int X = 5

Hypothetically, given developer tooling, which would you prefer to make sure your code is as correct and robust as possible?

1. Language with strong type features.

2. Testing packages that automatically include fuzz tests and null tests to ensure correct behavior?

Granted most of my experience in production level software involves backend services, which essentially means json transformations 95% of the time, Ive rarely ever seen an error that results in the service saying everything is ok but returning a wrong result. For example in the case of null fields, something downstream fails and errors out - this is easily caught by testing.

Well I would prefer to have both. I don't think we need to choose.

However, I think tests are high-maintenance. Often they consume the same amount of time to write as the actual business code.

I don't know how automatic null checking tests would work. Wouldn't you need to specify what happens if a null is input?

In contrast, I find the cost if typing very low for the value it delivers. Unless the code is very ephemeral (like a one off script) then I highly prefer typing.

> That is, did you remember to check for null?

What static typed language, apart from SQL, does automatic null checking?

C#