Hacker News Reader

Comment by suby | Hacker News Reader

You didn't provide an argument for why static typing is not worthwhile, merely that it won't solve all of your problems -- thus, you concluded, dynamic typing is better.

Yet static typing does very much catch issues, so I really don't see where you're coming from with this.

View on HN

If I'm being generous then maybe 5% of my developer time is spent chasing type errors. And then most of those "type" errors would be errors that no reasonable type system would have a chance of catching - like keys missing from associative arrays. I'm competent enough to not need the compiler to tell me banalities like that age is a number or name a string. The overhead of having to deal with types is many times larger than those 5%.

>And then most of those "type" errors would be errors that no reasonable type system would have a chance of catching - like keys missing from associative arrays.

what? in a language with ADTs and exhaustiveness checking, accessing a key from an associative array will give you back an Option type and the compiler will force you handle the code path where the key is missing.

unless I've misunderstood what you meant, this is a canonical showcase of what modern static type systems are good for.

and in your parent post:

>a list that must not be empty, etc. No, not even dependent types can guarantee these invariants.

what do you call haskell's NonEmpty then? https://hackage.haskell.org/package/semigroups-0.18/docs/src...

    data NonEmpty a = a :| [a]

I think you're underestimating what static types can do. it's funny you mention "blub" in that post ...

So static type system are conservative. If variable v is supposed to have type T and the compiler cannot deduce that it for sure is then a type error is generated. Hence you need option types because static type systems are not powerful enough to deduce whether a given nullable variable actually can be null or not. In effect, the compiler throws its hands in the air and says "Nope too hard, you do it for me." So the programmer has to insert runtime checks in the form of pattern matching clauses for option types even when it is trivial for a human to prove that a reference won't ever be null. The compiler admits defeat and instead forces the programmer to use runtime type checking.

It's mostly the same with nominative NonEmpty types. Any value the programmer has instantiated with one of NonEmpty's type constructors have type NonEmpty - everything else don't. For sure, you could create a NonEmpty class in Java too, but it would still be up to the programmer to enforce the type's semantic during program execution. If the variable L has type NonEmpty (list) then it's bloody obvious to a programmer that the expression pop(push(push(L, x), y)) also has type NonEmpty. To a compiler figuring that one out is mostly impossible.

> So static type system are conservative. If variable v is supposed to have type T and the compiler cannot deduce that it for sure is then a type error is generated. Hence you need option types because static type systems are not powerful enough to deduce whether a given nullable variable actually can be null or not.

Option types serve other purposes, like composability; tracing program flow can determine the points where a nullable type either (a) will always be null, or (b) will never be null, and many type checkers for type systems with nullable types (or, more generally, non-discriminated unions, nullable types are just one example.)

Reply on news.ycombinator.com