Live data from Hacker News

The type system is a programmer's best friend

dusted.codes

11–20 of 467 posts

Re: The type system is a programmer's best friend

#11

> ... to prevent silly mistakes like multiplying $100 with £20 Honest question, what should multiplying $100 with $20 give?

2000 square dollars? If I'm choosing between ways to spend capital so as to improve the efficiency of a process, and that process currently produces five widgets per dollar, then the quantity I'm comparing to choose between my courses of action can be measured in widgets per square dollar.

Hiring a better engineer for more money may create an efficiency improvement of 1 widget per dollar, with an outlay of $1k extra for the better engineer, giving a total gain of 0.001 widgets per square dollar; hiring a worse engineer for much cheaper may represent an improvement of 0.1 widgets per dollar, at an outlay of $1, giving 0.1 widgets per square dollar.

Perhaps not the most intuitive unit, but it's not impossible. (Though since you can even measure it in dollar-sterling if you like, I suppose that doesn't make it a counterexample to "stop multiplying dollars by sterling".)

Re: The type system is a programmer's best friend

#14
>A string value is not a great type to convey a user's email address or their country of origin.

I can argue whatever type you use in place of a string will similarly be "not a great type". This can be argued in perpetuity because no type/map actually matches the reality it's encapsulating.

Type systems require you to build a Pretty Good Theory of your problem space so that your types can overlap with reality/actual usage as much as possible.

The problem is at planning/design time, you'll have a Pretty Crappy Theory of your problem space and can only get a Pretty Good one after having wrestled with it for a while.

A dynamic, more forgiving language, allows you to build what you can today with the theory you have, and then change it in the future when your theory gets disproven.

Re: The type system is a programmer's best friend

#16
There is an important difference between types and objects: types are basic building blocks. An email is not a basic building block nor is money. In the mature ecosystem of Java there are libs and standard libraries that handles these problems some are even in the standard library (timestamp with timezone, url...)

It would be nice to have stuff for these in the standard libraries but currencies are a moving target and needs constant update to handle the quirks of the real world. For the same reason it's extremely hard to create an "Address" class that handles every possible scenario.

In my book the string is a great way to store a country of origin because everything else depends on the usage of that information.

Re: The type system is a programmer's best friend

#17
post #7

>A string value is not a great type to convey a user's email address or their country of origin. So we have a type for "country of origin". And then some country that you have in the records splits up into 2 countries, what do you do then? Do you keep a list of all countries that ever existed and keep it up to date? This approach works good in some cases, but not always

Is the alternative to sweep it under the rug? In a stringly-typed world, what happens - do you just hope for the best? In a typed world, the problem ("the real world has ceased to conform to the model") is at least made plain so that you can decide what to do with it, because the model is actually… modelled.

Re: The type system is a programmer's best friend

#19
post #2

I don't understand. Isn't classes what the author asks for?

Lots of languages reify types as classes, but that's not necessary. You don't need classes to have types.

Using classes also leaves entire segments of type-expression on the table or makes them unwieldy e.g. https://en.wikipedia.org/wiki/Tagged_union

So it's orthogonal, classes are just one possible implementation of types.

Post reply on HN