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

111–120 of 467 posts

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

#111

Post by jstimpfle »

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

> Would you rather litter the entire codebase with validations that this is indeed a valid email

Why would you? Just use it. For most of parts of the program it's not relevant to the computation whether the string is a "valid email", whatever that means. It's a string.

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

#112

Post by howenterprisey »

PainfullyNormal wrote: post #102
dkarl wrote: post #98

Earlier quoted context omitted.

I don't think every article has to "teach the controversy." This is an article for programmers who don't know the upsides of types. What's more, for a programmer who doesn't get the value of types, the major downsides are already apparent, at least at a basic level. Doesn't this make my code more verbose? Doesn't this get super confusing sometimes? It's an article design to help certain programmers learn a particular…

> What's more, for a programmer who doesn't get the value of types, the major downsides are already apparent, at least at a basic level. How could the downsides possibly be apparent if the upsides are so mysterious they need an article to spell them out? > It's an article design to help certain programmers learn a particular thing Have they actually learned that particular thing if they don't know the tradeoffs they'…

I don't know what to tell you. The downsides are apparent. There is no logic theorem that says the upsides and downsides need to be equally as apparent.

The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff. Nobody's talking about the downsides of type systems except to the extent that they're worth talking about: see the comments here every time someone compares the type systems of Python and Rust.

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

#113

Post by rowanG077 »

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

Of course there are thing that are free. Assembly is free over machine code which is free over punch cards.

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

#114

Post by henrydark »

creata wrote: post #54
musingsole wrote: post #8

Earlier quoted context omitted.

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.

And dollars times pounds is similarly a unit of covariance

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

#115

Post by rowanG077 »

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…

You are talking about validation not types.

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

#116

Post by tel »

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…

It's because you can write these types:

    recognize : String -> UnverifiedEmail
    validate : UnverifiedEmail -> VerifiedEmail
    send : (VerifiedEmail, Message) -> ()
You can then use visibility controls to universally guarantee that recognize and validate must be called before send. No test can ensure this is true.

Under the presumption that send should only perform work on verified emails, the alternative is not being able to be confident that emails passed to send are pre-verified. This means that send must check this flag, and therefore have the ability to fail due to non-verification.

This isn't inherently a problem, but it can lead to a failure to separate concerns. If one part of your system is responsible for parsing and validation and a separate part responsible for interacting with the sending machinery, it's unfortunate if the latter part can fail due to a failure to verify the email. These systems have now implicitly shared responsibility.

You can try to guarantee that no email is passed from the first system to the second without being verified, but this can be challenging. It's a universal property. Tests can show the presence but not the absence of bugs.

But those types we showed at the beginning provide exactly that guarantee.

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

#117

Post by rowanG077 »

jstimpfle wrote: post #111
kajaktum wrote: post #80

Earlier quoted context omitted.

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…

> Would you rather litter the entire codebase with validations that this is indeed a valid email Why would you? Just use it. For most of parts of the program it's not relevant to the computation whether the string is a "valid email", whatever that means. It's a string.

"Just use it" is what lead to the big SQL injection fallout and even today we pay the price as not even a year ago thousands of crucial service were vulnerable via log4j because of the "Just Use It" mantra.

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

#118

Post by c7b »

hardwaregeek wrote: post #95
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

Sure there are tradeoffs, but I disagree that it’s always so balanced. When people moved from assembly to high level languages presumably there were tradeoffs but in retrospect it’s a pretty clear cut choice. I’m not saying typed languages are as big of a shift as high level languages but it’s possible they are the unequivocal right choice.

Does that also hold for people doing data science in Jupyter notebooks? They're also programmers, arguably.

At this point in the trajectory of software engineering, it's fair to assume that most of the low-hanging fruits have been picked, and solutions that are unequivocally better would have to bring something fundamentally new to the table (which types are not at all). Most solutions will be picking a particular point on a trade-off isocurve.

Apart from that, it's always fair to ask someone who's strongly proposing something what the downsides are.

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

#119

Post by Smaug123 »

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

> Why is it better to have two email types, VerifiedEmail and UnverifiedEmail vs. one Email type with an "isVerified" field? You obviously have no idea what a type is. type VerifiedEmail = { email: string; is_verified: true; }; type UnverifiedEmail = { email: string; is_verified: false; };

In fairness this takes an unusually strong type system to express, doesn't it? Typescript can do it, but I don't think e.g. Haskell98 can do it out of the box in an analogous way? (Of course, it's hard to prove a negative and I'm not super familiar with Haskell, but my evidence is that I'm pretty certain F# can't.)

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

#120

Post by Jtsummers »

pfdietz wrote: post #64
djha-skin wrote: post #40

The most successful languages are typed but weakly so. Just enough type system to avoid the biggest class of bugs, not enough to get in your way all the time. Golang strikes this balance very well. Too little typing, and your Python unit tests get too heavy to run after every commit. Too much, and you have to read a book on category theory before you can figure out how to grab that one field using Lenses in Haskel. E…

I want to point out that in practice, Common Lisp is also to some extent statically typed. The compiler will issue warnings if there are forms that it can determine (at compile time) would cause type errors at runtime. It's common practice to not accept code unless these errors are eliminated (one can even set up your compile system to abort when they are found.) What it will not do is reject the program unless it ca…

That's dependent on the implementation, SBCL is particularly good at it. Others may just let things pass like:

  (defun foo () (* 1 "aoeu"))
In SBCL gives me this:

  ; in: DEFUN FOO
  ;     (* 1 "aoeu")
  ;
  ; caught WARNING:
  ;   Constant "aoeu" conflicts with its asserted type NUMBER.
  ;   See also:
  ;     The SBCL Manual, Node "Handling of Types"
  ;
  ; compilation unit finished
  ;   caught 1 WARNING condition
But in CCL it gives me no warnings at all and only triggers an error at runtime.
Post reply on HN