Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The type system is a programmer's best friend

dusted.codes

Post reply on HN
Print view View original

21–30 of 467 posts

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

#21

Post by mejutoco »

croo wrote: post #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 an…

IMO the difference between types and objects is that objects have state and behaviour, whereas types only have state.

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

#22

Post by musingsole »

Ygg2 wrote: post #10
mhaberl wrote: 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

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.

It's a very related problem.

I agree: All models are wrong; some are useful.

A string is a wrong model for an email address. But it's a pretty useful one.

A custom type sitting lonely in an isolated codebase IS ALSO A WRONG MODEL. Arguably, it might be more a useful one than a string. But that's debatable.

And on that debate, I'll argue a string is a better model because it is a better UNDERSTOOD model by more PEOPLE than whatever MyEmailClassForThisProject you just came up with.

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

#23

Post by eyelidlessness »

bjourne wrote: post #2

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

Depending on the language yes, or probably, or definitely not. A class is one of several ways to represent a type. Some languages have structural type representations and a class/instance is equivalent to a “plain old ___ object”; some languages have types but no notion of classes at all.

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

#24

Post by Ygg2 »

musingsole wrote: post #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…

> I can argue whatever type you use in place of a string will similarly be "not a great type".

All Types are wrong, but some are useful.

Will Money type solve all problems? Is it better than decimal, from POV of prevention of mistakes - yes.

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

#26

Post by mhaberl »

Ygg2 wrote: post #10
mhaberl wrote: 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

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.

> You can have your name change as well, or your calendar can change

What do you mean by that?

Having a type for "country of origin" would mean that the type gives you limits on what values it can hold (any country known to ever exist) so you can not say something like:

Country c = "Foo"

because Foo is not a country.

I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names.

The calendar example I don't get. We already have "date" types in almost all languages so that "works", although it can be used as example of how hard is to implement some types.

-----

So I say: >> This approach works good in some cases, but not always

And you say: > Does that mean we stringly type everything?

Come on now. "Not always" does not mean "Never"

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

#27

Post by masklinn »

sanp wrote: post #25

Question: isn’t a rich type system as described here similar to OOP?

The essay uses a class-oriented type system (they're clearly a .net developer), but the same ideas very much exist in non-OO type systems.

And the richest and most expressive type systems are arguably specifically non-OO. Nor are OO languages necessarily statically typed (Smalltalk, Self, Python, Ruby, Javascript, ...)

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

#28

Post by musingsole »

Smaug123 wrote: post #17
mhaberl wrote: 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.

In a stringly-typed world, you still end up with a purpose-tuned model of what an email is, how it's used, and what error cases are -- these just aren't implemented as qualities on a type.

There's a dozen approaches for it, many from the functional programming paradigm. But an example of one approach would be that your consumer functions become responsible for interrogating the data they'll act on -- through assertions or other verification means.

Comparing to the real world: my metal foundry doesn't yell if it gets a non-metal Type of material. But, the logical process it follows (heating to 1000+ *C) takes care of all but a handful of corner cases when you give my foundry the wrong data type.

The choice to wrap all the logic into a "Type" and then get mad when the model logic exists elsewhere is just a choice. And a weird one people get VERY OPINIONATED about.

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

#29

Post by masklinn »

mikewarot wrote: post #3

I once attended a meeting where a Professor from a University somewhere in Chicago gave a brilliant demonstration of using a similar type system for dealing with values in Electrical Engineering. It made quite sure you couldn't do things like add volts and amps. [Edit] it also handled things like parallel resistances, etc. It was in C++ if I recall correctly. This is a great idea, that I've haven't had cause to use y…

FWIW that's a pretty basic application called "units of measure". Some languages like F# have that natively.

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

#30

Post by Ygg2 »

musingsole wrote: post #22
Ygg2 wrote: post #10

Earlier quoted context omitted.

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.

It's a very related problem. I agree: All models are wrong; some are useful. A string is a wrong model for an email address. But it's a pretty useful one. A custom type sitting lonely in an isolated codebase IS ALSO A WRONG MODEL. Arguably, it might be more a useful one than a string. But that's debatable. And on that debate, I'll argue a string is a better model because it is a better UNDERSTOOD model by more PEOPLE…

> It's a very related problem.

It's not. You have the same problem regardless of type you place there.

> A string is a wrong model for an email address. But it's a pretty useful one.

Depends on use case. Perhaps it's an overkill in this toy example.

I've real life use cases with untrusted user input where having raw string as untrusted and some kind of verified type as trusted would eliminate whole swath of errors.

Post reply on HN