Live data from Hacker News

The type system is a programmer's best friend

dusted.codes

121–130 of 467 posts

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

#121
post #110

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

I agree with this, yet look at some of the extremely salty comments in this thread. People are upset that something might be useful and that they might benefit from learning it or changing their ways.

Some of the salt might come from experiences using dynamically typed languages that later had some amount of stronger typing added on.

No matter how well that's done, it creates friction somewhere in the process interacting with existing code.

That is, I can agree that an inherently strongly typed language has benefits, while also being skeptical about bolted on additions.

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

#122

Earlier quoted context omitted.

> 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 s…

> The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff

This is why engineering/software articles in general (this one included) needs to bring up tradeoffs more often. No, "learning more stuff" is not a downside or a tradeoff, it's just a fact of learning anything.

That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a tradeoff. That is becomes easier to write large, messy programs because programmers feel more safe in the future to refactor, is a tradeoff. Trying to fix each one of those tradeoffs also come with their own tradeoffs, and so on.

These are "apparent" for me, when talking about languages using static types vs dynamic languages, but it is not apparent for everyone. So when bringing up these "obvious" upsides, also bring up the "obvious" downsides, as it seems quite a lot of people don't see it as "obvious" as we do.

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

#123
post #105

Earlier quoted context omitted.

If that place is the EmailAddress type, then you have built your system wrong. You check that stuff when the data enters the system.

If you can construct an EmailAddress, then you have a valid EmailAddress . That's the point. If an EmailAddress can be a valid or invalid email address, then just leave it as a String (since that can also be a valid or invalid email address). > You check that stuff when the data enters the system. Yes > If that place is the EmailAddress type, then you have built your system wrong. No If you validate & construct an Em…

My advice: Relax and don't argue. People who don't understand that constructing an EmailAddress type is also validating the raw email string (in this case) will never understand it. They'll remain convinced for a very long time, possibly the rest of their lives, that they know better. That passing a string around is fine as long as either you always validate it everywhere (yes, kill your performance, that's smart) or that they validated it once and they pinky swear to never change the value and to always call validate before passing it into the system.

Let them find subtle errors in their programs over time, it's job security for them. They don't want to move on to new and more interesting things they just want to keep fixing the same shit for the rest of their careers.

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

#124

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

There isn't a reason why you shouldn't write something like $100 * (£20 / £47) as "int dollars = 100 * 20 / 47;". Note that this expression assicates to the left instead of the right, which can be the right thing to do if doing integer arithmetic. But it would not work with a strongly typed setup as in your example.

In my experience trying to prevent accidental mistakes is a waste of time and often makes our lives miserable. Catching the rare bug by doing complicated work in the type system when it would have been easy to find in normal code anyway is not worth it.

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

#125

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

Based on the author’s examples and the JS-ish looking code in the article, maybe PureScript in general and row types in particular, uh, 4ev3r?

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

#126
post #121
post #110

Earlier quoted context omitted.

I agree with this, yet look at some of the extremely salty comments in this thread. People are upset that something might be useful and that they might benefit from learning it or changing their ways.

Some of the salt might come from experiences using dynamically typed languages that later had some amount of stronger typing added on. No matter how well that's done, it creates friction somewhere in the process interacting with existing code. That is, I can agree that an inherently strongly typed language has benefits, while also being skeptical about bolted on additions.

Makes sense. People have been burned. Probably there are lots of people who think about typescript environment setup and source maps when they think about typing, or who think about python's "isinstance(str, foo)". Or who think that it's overly complicated arcane nonsense with weird terminology (lookin at haskell). Or that types specifically refer to borrow checker woes in rust.

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

#127

Earlier quoted context omitted.

> 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.

You don't understand what I said.

I say, don't make assumptions unless you need them. Formatting an email address in an HTML document would work by wrapping it in the appropriate tag. (which implies html-quoting it correctly, but that is unrelated to email syntax).

Sending an email using an API would work by passing the email as a string to the API.

Looking up an email address from an address book using a pattern to match would be implemented with normal text search.

It doesn't matter if the email is "valid" or not. Don't overthink it.

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

#128
post #110

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

I agree with this, yet look at some of the extremely salty comments in this thread. People are upset that something might be useful and that they might benefit from learning it or changing their ways.

It's weird to me how scanning the comments all seem to refer to systems with 100k-ish LoC and dozens of contributors.

A big chunk of my job is writing node microservices in AWS Lambda. I do everything I can to avoid shared library code, since past experience tells me there be lots of dragons (mainly in when and how to push or pull lib updates to components). I have a very tiny shared lib that I try to never touch and definitely never introduce breaking changes.

Unit tests are a breeze since I never have to cast objects or worry about generics, etc.

Typescript would slow me down so much and add absolutely no benefit. Maybe I'm misinterpreting though and no one is claiming Typescript would benefit here.

We also have some C# lamdbas and I find writing unit tests for those so much more of a pain - since the shared libs have generics and I'm always casting things. But admittedly I don't know all the tricks.

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

#129

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…

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

This question can't be answered without additional context. What are the requirements?

But as a heads up, Map couldn't be representation of all valid JSON documents. Lists are valid Json as well AFAIK. So I think this is making a point.

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

#130

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

How have I not seen Grug before, wonderful! Thank you!
Post reply on HN