Hacker News Reader

Comment by z3t4 | Hacker News Reader

When learning about math vectors the code often looked like x Pos + y Vec. But when rewriting it in a language withot annotations it became hard to understand the code. So I argued about adding annotations to the language. But the other side of the argument urged to use better variable names. So I rewrote it as position+speed and it became even easier to understand. And I have never missed annotations since then.

View on HN

A variable name tells me what the person who wrote it thought it was at the time they wrote it.

A type tells me what it is in any version of the program that the compiler accepts.

If the type is something generic like Tuple, it doesn't tell you what it means. If it's a type with domain semantics like Speed or Velocity, then goto your issue with naming variables.

No, but it tells me what types the tuple elements are, and thus indirectly (I know where to look to find out), how I can use them, and what calling functions on them will do.

It doesn't tell me their significance for the business logic, that's what variable names are for.

It sounds simple on math vectors, but some systems are inevitably complicated and in constant flux.

If you are making a linear collection, backed by a resizeable array, your interface is clear.

If you are making something like an I/O subsystem of an OS, in 10 years your primitives suddenly may change. For example, flash storage replaces spinning disks, and you need to schedule block erasure preferably when user programs are idle. Now you need to find all the places blocks are detached from the file structure, excluding FS journaling, and change the logic there to accommodate new scenarios, trying to reuse as much code as possible for you everyday operations. In a statically typed language I can perform exhaustive search for all such cases in no time, and make guaranteed safe refactorings to deal with that problem. No so in dynamic languages.

The change happens even faster with 3rd party networked services/libraries, because their evolution is not held back by expensive experimentation.

Adding a speed to a position is a cardinal sin against dimensional analysis, the type model for physics. ;p

The speed is most likely implicitly multiplied by a unit time.

That's... exactly the kind of thing a type system is intended to stop you from doing.

Is it? I think it's fairly uncommon to use types to enforce correct units in calculations, and you need a pretty sophisticated type system to be able to do it.

I'm not saying it's a bad idea, just that it's not really a core application of type systems in real-world programming practice.

Sure, but the general idea that you should disallow undefined operations are a core application of type systems.

You don't need too advanced of a type system to implement what you're talking about. With the caveat that doing it in Java would make the code tedious to write ;-).

And there's some benefit to forcing you to make that explicit, so the reader doesn't have to assume that "most likely" that was the intended meaning.

Reply on news.ycombinator.com