Hacker News Reader

> A better test suite can have exponential more value on maintainability than types.

A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types.

The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase.

Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.

I always say that Types are not there for the truly expert programmer. They are there for the rest of us. It's a lot easier to pick up code and understand it when you at least have an inkling as to what a variable or parameters needs to have to function.

Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.

I think "truly expert programmer" is hypothetical. I don't think I encounter many programmers that prefer to eschew typing unless it's a quick one-off script. Typing your code takes maybe 1-10% of the time it takes to right (if that). It provides far more value than tests. Just like Rust's ownership model in the type system provides much better results than C++'s implicit ownership model + tests.

That's exactly my point. There are very few people that are real experts, people that can see code and reason everything in their heads with little or no help. There really aren't any. Everyone thinks they are, but they aren't. Having types helps the rest of us understand what is going.

I always say that Types are not there for the truly expert programmer. They are there for the rest of us.

I would say exactly the opposite - beginners pick languages without [much] typing because it is or at least it seems easier to get started. When you step out of toy program territory you will start to appreciate the value of types.

> beginners pick languages without [much] typing because it is or at least it seems easier to get started

It's hard to tell whether the reason beginners pick languages is because they are not typed or because they are immediately practical (such as javascript, php or python). Christopher Allen's and Julie Moronuki's Haskell Programming from First Principles is targeted at complete beginners. Harvard's CS50, which starts with C (well, Scratch, technically; then C), also targets beginners.

You don't see much lisp among beginners, despite the absence of type notation.

> It's hard to tell whether the reason beginners pick languages is because they are not typed

No, it is not hard to tell. Programming beginners positively do not choose languages by evaluating concepts that they have no clue about.

> You don't see much lisp among beginners, despite the absence of type notation.

Lisps are simply not widely promoted to beginners; there aren't enough people to do that.

Beginners end up learning whatever is thrust at them most frequently and loudly. Basically, the non-beginners more or less decide that for the beginners.

> I always say that Types are not there for the truly expert programmer.

Machine-verifiable documentation about the intended I/O of functions and shapes of structs and objects is hugely fucking valuable to everyone. Your documentation isn't good enough if it doesn't include that, so it may as well be in a format that a machine can read, validate, and use to help out every single person who ever has to read or touch that code.

no-one is a truly expert programmer 100% of the time.

Types catch a lot of stupid errors that anyone can make, regardless of skill level.

They also localize guarantees. If your data has a type, you don't need to understand the full path it took to arrive in your function to be able to work with it. With dynamic types, you can only hope that a value has the type you need unless you explicitly check every time.

> Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability.

> But unfortunately it does not bring that much value.

If you mean adding these things post-hoc, yes the value is limited. If you start with types, and you embrace them as a design and testing tool, they can literally change the kind of code you write in the first place.

People talk about how convoluted TS types are, but the reality is that’s because they’re describing convoluted JS. TS-first code tends to be a great deal more straightforward, because you define the interface before implementing it.

In other words, if you start out with static types and think about them first, you’ve likely already got a good architecture and test suite.

I guess there are differences between how static typing is implemented.

I've been using Elm for the last 2 years and it's not that I don't fight the compiler, but I constantly use it to guide me while refactoring. Elm code is extremely readable and types (including Maybe, Result, etc.) just give so much confidence and control to the programmer. While working with an Elm code base, refactoring is a constant, joyful, safe act.

It is true that in many cases good tests help. However often when I work with Python (using type hints), I need to write a unit test just to ensure a contract that I could explicity state using types in Elm. It doesn't feel right.

Unit tests aren’t a replacement for static types. Tests aren’t machine readable so you lose all those nice IDE refactoring features and have to manually keep them up to date. Also running a test suite takes time, it takes a lot longer to run a test suite than it does to get live typecheck, which means you cannot use tests while you are editing. And you probably don’t want to clog up your test suite with endless “x is a Y” tests.

In general dynamic types incentivize the status quo and promote codebase ossification, and somewhat ironically make rapid prototyping harder.