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

101–110 of 467 posts

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

#101

Post by nezirus »

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…

Dunno, but adding verified attribute with a setter which executes verification step looks simpler to me and covers 80% of the use cases.

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

#102

Post by PainfullyNormal »

dkarl wrote: post #98
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

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're making? I would argue they haven't. You need to know what you're getting and what you're giving up before you can decide whether something is worth using at all. There are too many articles hyping the upsides of technology X, but nobody asking what the downsides are.

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

#103

Post by BiteCode_dev »

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

I must be grug. Just forgot I wrote because dumb brain.

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

#104

Post by gary17the »

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 fixing them takes at least ten times more effort than getting rid of bugs by not making them in the first place, through expressing the problem at hand with a strong type system.

When you also consider the never ending necessity to introduce change to an already written software system, thus the necessity to refactor code (in the sense of altering the previously assumed meaning of its idioms), the critical advantage of a strong type system becomes self-evident.

(Yes, Rust 4ev3r! ;))

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

#105

Post by mrkeen »

ReflectedImage wrote: post #86
mrkeen wrote: post #43

Earlier quoted context omitted.

No, there should only be the one EmailAddress type. If it's not valid, it's not an EmailAddress. Does having an EmailAddress type guarantee you won't accidentally accept crap? No, but when you get it wrong, you edit the validation in one place in the system.

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 EmailAddress from another external class, that means external classes are free to bypass validation and construct an invalid EmailAddress. Putting the validation/construction inside EmailAddress lets you force construction to go via validation.

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

#106

Post by saagarjha »

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

How can the downsides of having to wear a seatbelt possibly be apparent if the upsides are so mysterious they need an article to spell them out? People have a quick aversion to things all the time. Sometimes the actual benefits need to be carefully explained. (“You are statically likely to be in a car crash. Wearing a seatbelt multiplies your chance of living through it.”)

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

#107

Post by ironSkillet »

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

That grugbrain post was so funny and enjoyable to read, thanks for sharing.

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

#108

Post by dkarl »

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

They aren't going to learn that in a day or a week or a month. Maybe a year if they're extremely bright or are in a perfect environment for figuring it out, but most people take years. This article is a few minutes out of that hypothetical best-case year. If it gives them food for thought for a week, it'll be time better spent than 99% of what they could read, certainly better than if they read a comprehensive article that went 98% over their heads and got them hung up on things that they weren't yet able to experience and understand.

Besides, they aren't going print this article out and take it to a cave in the mountains to learn about type systems for a year. They're going to read other stuff along the way.

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

#109

Post by bjourne »

eyelidlessness wrote: post #23
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.

Sure but the requirements given by the author are exactly represented by, for example, Java's class system. So why is the author dreaming about something that has existed for 20+ years?

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

#110

Post by c54 »

gary17the wrote: post #104

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.
Post reply on HN