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

71–80 of 467 posts

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

#71

Post by hiAndrewQuinn »

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…

My favorite "easy win" find from learning Haskell last year was just the `newtype` keyword, which basically just let you alias primitive types with zero runtime impact.

`newtype Email = Email String` and `newtype Username = Username String` are just `String`s with guard rails.

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

#72

Post by an1sotropy »

Spivak wrote: post #65
an1sotropy wrote: post #50

Earlier quoted context omitted.

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…

But it shouldn’t be an error in any unit system. # oops my scaler has a unit x unit * x unit = x unit^2 The value isn’t catching this line of code since it’s potentially valid. It’s catching the line of code where you pass the result to a function that expects unit.

I agree, but the original article at dusted.codes hopes types will "prevent silly mistakes like multiplying $100 with £20".

I don't know what that author would think of multiplying $100 with $20, but my point is that this embrace of type systems is apparently not just about function interfaces; it also includes the operands of things like multiplication, and preventing that operation if the types are fishy.

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

#73

Post by PainfullyNormal »

Articles like this bug me. You've given me a list of why types are awesome. Great. Now, tell me what the tradeoff is. Nothing is free in engineering. To get something, you have to give up something else. Even grug[0] understands this.

[0]: https://grugbrain.dev/#grug-on-type-systems

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

#74

Post by wirthjason »

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…

I’m not sure the Chicago reference but if you’re talking about C++ the Units library is a good option.

https://github.com/mpusz/units

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

#75

Post by bigyikes »

PainfullyNormal wrote: post #73

Articles like this bug me. You've given me a list of why types are awesome. Great. Now, tell me what the tradeoff is. Nothing is free in engineering. To get something, you have to give up something else. Even grug[0] understands this. [0]: https://grugbrain.dev/#grug-on-type-systems

grug miss big brain benefit for types. Grug says the main benefit is auto completion, I think the real benefit is to making code changes.

If I update a type, the compiler will tell me every single location where I need to make a corresponding code change. For grug: change type give red squiggle, make change code good

Also, grug makes a good point about the temptations of generics, but I think they’re exaggerating the impact to the speed of development.

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

#76

Post by jmull »

Why is it better to have two email types, VerifiedEmail and UnverifiedEmail vs. one Email type with an "isVerified" field?

One type is probably going to align with storage and transport better, and you probably mostly want to treat verified and unverified email addresses the same except for some very specific situations. (E.g., maybe only your EmailBlaster cares, where it's like a privilege: some can send to unverified emails and some can't.)

This seems like a bad for types to me.

(It's all code you write and data you design -- types are just one tool... you need to think about they best tool, not get fixated on one, no matter nice it is.)

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

#77

Post by SaltyBackendGuy »

PainfullyNormal wrote: post #73

Articles like this bug me. You've given me a list of why types are awesome. Great. Now, tell me what the tradeoff is. Nothing is free in engineering. To get something, you have to give up something else. Even grug[0] understands this. [0]: https://grugbrain.dev/#grug-on-type-systems

> big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct

I forgot about this, thanks for the morning laugh. No such thing as a free lunch.

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

#78

Post by blandflakes »

jmull wrote: post #76

Why is it better to have two email types, VerifiedEmail and UnverifiedEmail vs. one Email type with an "isVerified" field? One type is probably going to align with storage and transport better, and you probably mostly want to treat verified and unverified email addresses the same except for some very specific situations. (E.g., maybe only your EmailBlaster cares, where it's like a privilege: some can send to unverifi…

I think you understood the use, but value the safety less than I do:

> maybe only your EmailBlaster cares, where it's like a privilege: some can send to unverified emails and some can't

A boolean flag is strictly inferior, because it is a runtime check. You can only ever be sure that you're processing verified emails at runtime, and there's no way to require that the code guards against that in all places. If they're different types, you can't even pass an unverified email to code that needs verified emails, so you eliminate the entire possibility at compile-time.

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

#79

Post by throway232lasdf »

treis wrote: post #42

The problem with this is the explosion of types when you start with combinations. Stuff like VerifiedEmailOptedOutOfMarketing. I can see a type system designed from the ground up to do something like this. But as a bolt on to existing languages it's pretty clunky.

    type VerifiedEmailOptedOutOfMarketing = { email: string; is_verified: true; is_opted_out: true; };

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

#80

Post by kajaktum »

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…

What? Would you rather have JSON as a string or as something like Map?

> No, if your idea of validating an email is more complicated than "should have an @ symbol"

Then how is just using a string any better? Would you rather litter the entire codebase with validations that this is indeed a valid email or just do it once at the entry point?

I think excessive type system hacks are bad too but they are more often than not the problem of the language where its unable to express certain concepts naturally (see C++ template hacks).

Post reply on HN