Hacker News Reader

Comment by deogeo | Hacker News Reader

> the ways Haskell & Rust enforce program structure is a huge cost

In my experience, it is the opposite of a cost - "worrying about types" doesn't slow me down. Instead, types help guide me, help reason about my code, and help documentation. Coding with types is, for me, faster than without.

In fact, I find myself worrying about types the most in dynamic languages - I'm never sure what I can pass to a function, or what a certain thing is, so I have to manually review what a simple type signature or inferred type would tell me.

View on HN

I agree. People forget that you can't avoid types. It's the shape of the data. Whether they are static or dynamic/uni, you still have them, and you have to deal with them. I'd much rather deal with it upfront, statically, at compile time. I find it works much better for me, and it helps me model my program. The compiler is a tool I use to ask questions about my program, and we work together to build the shape together.

> It's the shape of the data.

This is how far types are required to go. (And not even strictly - sometimes it makes sense to switch on the shape dynamically). The hype around types in contemporary languages goes far beyond mere shape. And that can lead to unnecessary program structure which can block further development.

This seems like too narrow a reading of OP's point. Rust imposes not only types, but also a particular tree-like program structure which makes it awkward to express lists, upward references, and other constructs.

Lets say I'm only responding to that narrow reading, and am not objecting to a wider interpretation.

If it was just simple type annotations, type synonyms for domain modeling, I’d agree. It’s not at all though. Just consider how extremely hard it is to set up systems of dynamic dispatch in Haskell.

I do however think the “types help me reason about code faster” argument is a lot of bollocks. Years of experience working in large enterprise Haskell & Scala codebases made me believe this is not true at all.

I do find types helpful in smoke testing greenfield code where it needs to deal with structured data and references. But definitely the more complex approaches to typing have sharply diminishing returns. The static invariants I start caring about in complex scenarios are more along the lines of contracts or structured concurrency, and I don't want to reason about those with types.

When is "dynamic dispatch" a business requirement? You clearly are trying to put square pegs in round holes for no reason other than habit.

Passing in a value containing s function isn't hard, but I very rarely want to do it.

> Just consider how extremely hard it is to set up systems of dynamic dispatch in Haskell.

What? Make a record of function values. Done.

You can also go with an existentially qualified type with type class constraints if you just want the moral equivalent of [Show _], say.

Reply on news.ycombinator.com