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

51–60 of 467 posts

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

#51

Post by mixedCase »

Barrin92 wrote: post #39

>A string value is not a great type to convey a user's email address or their country of origin. These values deserve much richer and dedicated types this is a classic case of not needing more types but needing proper names . Types as concretions, i.e. simply collections of data or functions are a terrible idea because they're static and don't accrete. Data in the real world always does. This becomes very obvious whe…

> you just take your delivery out of the truck

Sorry, I accidentally took the delivery out of the email. You made them both have a deliver_to(address) method, you spent most of your comment talking about emails and the computer surely didn't stop my underslept human self from confusing an email address from a physical one.

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

#52

Post by cardanome »

Oh god, please just use primitive types. Don't make assumptions about things.

Everyone thinks they are so smart validating emails, phone numbers, zip codes and all until their great design goes live and they discover that users in the real world do not follow their assumptions.

I have seen that happen again and again. No, if your idea of validating an email is more complicated than "should have an @ symbol", I guarantee you, there is counter example that will mess you pretty system up. Have fun scrambling to fix that ticket.

Oh you think you know how an address and zip code should look like? No, you don't.

Please people, just use strings and call it a day. Why do you like to suffer?

I mean, sure, using the type system to protect you from mixing up units can be useful. Everything in moderation. Primitive types are good types.

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

#53

Post by mejutoco »

grumpyprole wrote: post #44
mejutoco wrote: post #21

Earlier quoted context omitted.

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

To compare them this way is likely to cause confusion. A type (of a term) represents the set of all possible values for a particular term. An "object" in OOP, does not have any formal definition, but is typically a first-class module with mutable state. As such, they can be represented by a term and therefore can have a type.

> they can be represented by a term and therefore can have a type.

It is informative, I see what you mean. Let me try again following your terms: An object is a type plus behaviour (mutable state).

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

#54

Post by creata »

musingsole wrote: post #8
henrydark wrote: post #4

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

Programmers will have immediate answers for you -- stated confidently as if to imply there is a spec somewhere when in fact no spec exists and the programmer you're talking to is peddling their own bullshit as gold.

A dollar times a dollar is a dollar squared. You don't need a spec for that!

For example, if you have a random variable that's in dollars, its variance would have units of dollars squared. People consider the variance of dollar estimates all the time.

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

#55

Post by revskill »

cardanome wrote: post #52

Oh god, please just use primitive types. Don't make assumptions about things. Everyone thinks they are so smart validating emails, phone numbers, zip codes and all until their great design goes live and they discover that users in the real world do not follow their assumptions. I have seen that happen again and again. No, if your idea of validating an email is more complicated than "should have an @ symbol", I guaran…

To me, type is for data abstraction, like we use generic for function abstraction.

Abstraction in this case, mean, for future changes, i just need to change in one place, the Email type abstraction instead of searching and replacing every ussage of primitive email string.

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

#56

Post by chii »

cardanome wrote: post #52

Oh god, please just use primitive types. Don't make assumptions about things. Everyone thinks they are so smart validating emails, phone numbers, zip codes and all until their great design goes live and they discover that users in the real world do not follow their assumptions. I have seen that happen again and again. No, if your idea of validating an email is more complicated than "should have an @ symbol", I guaran…

> if your idea of validating an email is more complicated than "should have an @ symbol", I guarantee you, there is counter example that will mess you pretty system up.

unless you are writing an email server. Then you would need to do this properly.

In other words, validate the data that is in the domain of your application. If your app simply _sends_ email, then it's not your domain, and don't need to validate, as long as the receiving end of the email (aka, the email server) accepts it.

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

#57

Post by usea »

an1sotropy wrote: post #50
Smaug123 wrote: post #11

Earlier quoted context omitted.

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…

Is this getting downvoted? bummer. You have provided a real example, which I was looking for, of why one might need to express a square dollar; thanks. I wonder if the people who want to argue "types save you from bugs" see your example as very unwelcome, since they'd want to use "squared dollars" as an example of something nonsensical that should be flagged as a type error. I hope those people can reflect rationally…

I also enjoyed the square dollars example.

A type system is merely a tool to encode information to help better model things. If you want to prevent multiplying dollars together, types can help you do that. If you want to enable multiplying dollars together, types can help you do that, too.

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

#58

Post by Barrin92 »

mixedCase wrote: post #51
Barrin92 wrote: post #39

>A string value is not a great type to convey a user's email address or their country of origin. These values deserve much richer and dedicated types this is a classic case of not needing more types but needing proper names . Types as concretions, i.e. simply collections of data or functions are a terrible idea because they're static and don't accrete. Data in the real world always does. This becomes very obvious whe…

> you just take your delivery out of the truck Sorry, I accidentally took the delivery out of the email. You made them both have a deliver_to(address) method, you spent most of your comment talking about emails and the computer surely didn't stop my underslept human self from confusing an email address from a physical one.

then you should complain and check what's in your mail. The fact that a delivery method is generic isn't a problem, delivering things from A to B is a generic task. The recipient of the packet handles the content, the deliverer doesn't care what's in the box. deliver_to ought to be reusable, there shouldn't be 50 versions of it.

When we send json over the wire do we rewrite methods globally to make sure we're all in sync about the content? No, you as the message recipient make sure that what you got makes sense and how to deal with it.

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

#59

Post by grumpyprole »

mejutoco wrote: post #53
grumpyprole wrote: post #44

Earlier quoted context omitted.

To compare them this way is likely to cause confusion. A type (of a term) represents the set of all possible values for a particular term. An "object" in OOP, does not have any formal definition, but is typically a first-class module with mutable state. As such, they can be represented by a term and therefore can have a type.

> they can be represented by a term and therefore can have a type. It is informative, I see what you mean. Let me try again following your terms: An object is a type plus behaviour (mutable state).

I am saying that an object has a type, rather than is a type or some augmentation of it.

An object is a term-level construction and therefore is not really comparable to a type. Types can be given to both state and behaviour. For example, a function type describes pure behaviour.

Note that statically-typed OOP languages have a name for the nominal types of objects: "classes". One could say that a class is a type representing both state and behaviour.

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

#60

Post by graypegg »

I’ve always grokked primitive types as mapping to different concepts used when storing values in memory.

A string is some bytes in a line with a terminator at the end.

An integer is a group of signed or unsigned bytes.

An enum value points at another value with a pointer.

Etc.

What I think this describes is some validation classes, which don’t need to be built into a language’s runtime. Primitive types have a real reason for existing when compiling these apps, a validation class doesn’t. It can just be a library, in which case this is a nice API for validation!

Post reply on HN