Hacker News Reader

Comment by azangru | 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.

View on HN

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.

Reply on news.ycombinator.com