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

231–240 of 467 posts

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

#231

Post by jmull »

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…

(Replying to my own post)

Wow, lots of great, thoughtful replies, thanks!

But I'm not convinced...

Maybe it's just a bad example (this is what the main article is about, though)... Generally speaking, you need to be able to send emails to both verified and unverified emails. The difference is in what the email you are sending is about. That's why VerifiedEmail as a type doesn't make a lot of sense to me.

You'll need sendToUnverifiedEmail(email: UnverifiedEmail) and sendToVerifiedEmail(email: VerifiedEmail), and have code to get the right type to pass to the right function the in the right circumstance...

You've got the same potential for getting this stuff wrong, whether you express it in a type or in imperative code or however you express it.

Replies are generally assuming the type part of the code is bug-free and the imperative part of the code is not, which just isn't reasonable.

Also, the static vs. runtime stuff is irrelevant to this example: the verified status of an email address is a runtime property that cannot be known at compile time (OK, I'm assuming you don't hard-code verified email addresses). I.e., due to a bug, a value of type VerifiedEmail could be created for an email address that is not really verified. Then, your static checks for VerifiedEmail don't help you at all.

Further, "verified" vs. "unverified" is really a business concern around when it's OK to send certain kinds of emails to the address. It has a fairly standard definition, but there are qualifiers for email addresses that are at least as important to a business that aren't. E.g, did the owner of the email address opt in to marketing emails? Or opt out? Or did not express a preference (yet)? Are you going to have types for those? You'd have to have 3 X 2 types to encode that... that's (verified, unverified) X (opted-in, opted-out, didn't specify) types. Then your business adds a new kind of email, securityAlerts, so now you've got (verified, unverified) X (opted-in, opted-out, didn't specify) X (gets-security-alerts, doesnt-get-security-alerts). Oh wait, some emails shouldn't go to banned people. So now you've got: (verified, unverified) X (opted-in, opted-out, didn't specify) X (gets-security-alerts, doesnt-get-security-alerts) X (banned, not-banned). And you need a "send" for each type, called at the right spot.

So...

Are the types really helping here?

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

#232

Post by pjmlp »

highwaylights wrote: post #145
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’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

Yeah, the same culture worships using their powerful computers in 2022, the same way I was using Xenix in 1993.

Talk about progress.

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

#233

Post by tsimionescu »

tremon wrote: post #226
tsimionescu wrote: post #184

Earlier quoted context omitted.

Note that most such solutions break (or become much much much more complex) if you want anything more than simple arithmetic from them. For example, matrix multiplication with typed values (where each element of the matrix can have a different type/unit of measure) is extremely ugly code, and basically no such library supports it - even for matrices of fixed size (say, code that could multiply 3x3 matrices with 9 typ…

matrix multiplication with typed values (where each element of the matrix can have a different type/unit of measure) Is this really a common occurrence? In most situations I've come across, it's the matrix itself (rows/columns) that has a unit of measurement, not the invididual columns. Tensors, rotation matrices, lighting maps: they all use the same units of measurement.

Matrix multiplication is often used for solving systems of linear equations, and you often have systems of linear equations involving different physical quantities (such as position, speed, time and mass if solving some classical mechanics equations, or pressure, volume, temperature, and time for thermodynamics etc).

And while it may be relatively common to start out and end up with matrices that have a single unit for each row (but different units on different rows), intermediate results will often end up with different combinations of units in each element.

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

#234

Post by jmull »

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; };

This is expressing the same value in two different ways. That's worse, not better.

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

#235

Post by titzer »

noveltyaccount wrote: post #151
highwaylights wrote: post #145

Earlier quoted context omitted.

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code…

Wait until you learn about these 2002 technologies called "extract method", "inline method", "encapsulate fields", "extract interface", "extract local", "inline local", "rename", plus about 200 code inspections...

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

#236

Post by afiori »

Izkata wrote: post #207
jstimpfle wrote: post #194

Earlier quoted context omitted.

As much as I can just happily ignore JSON because I don't do webdev, I think there is a strong case to make that lists should be implemented using a native list, array, or vector class. But I won't argue because it's not necessary. The possibility for argument already proves my point. My point is to show that "the type system" provides endless rabbit holes, and often is just a waste of time. There are a lot of situat…

> The possibility for argument already proves my point. Was just correcting something wrong: > But as a heads up, Map couldn't be representation of all valid JSON documents. So, > As much as I can just happily ignore JSON because I don't do webdev I think this is why you're going wrong here. JSON is pretty much a solved problem, and Map is pretty close to how it's used in Java and other languages that don't have nati…

JSON is often interpreted as dictionary but is serialized as key-value pairs, for JSON itself this is not a big problem as everybody agrees not to produce JSON documents like {"a":1,"b":2,"a":3} so most people do not care about how their parser reads them.

In cases like URL queries or HTTP headers it is not such a clear cut. There it is common both to use duplicated keys and to use JSON-like dictionaries to read them.

Personally I never had bugs due to this: PHP does the "right" thing with duplicated keys and I never encountered it in node, but it bugs me that we use this kind of lossy[0] representations.

[0] in JS in particular the object are not really adequate to be used as dictionaries, inheritance and predefined keys aside there are also special magical attributes that behave in special ways Object.getPrototypeOf(Object.assign({}, JSON.parse('{"__proto__":null}')))===null;

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

#237

Post by hither_shores »

tsimionescu wrote: post #187
mrkeen wrote: post #48

Earlier quoted context omitted.

Right, but if you told your professor you sometimes represent distance in Volts (to make your calculations simpler) you'd get some funny looks. You could even double-down on it: "Have there been any studies that prove that using units of measure helps you get the right answer?"

Funnily enough, there are some applications for converting mechanics problems to analogous electricity problems to leverage circuit simulation software such as PSPICE to help solve things like transcendental equations.

Yes, but the mapping doesn't change the relationship between the units of measure, which is the actual meaning as far as the type system is concerned. It's just a change of names.

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

#238

Post by titzer »

bluGill wrote: post #149
highwaylights wrote: post #145

Earlier quoted context omitted.

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

I'm adverse to debuggers as i've more than once caught myself following a rabbit hole of steping through code instead of thinking. IDEs have some use, and static analysis has proven to catch the same mistake over and over, but only as the authors of those tools have discovered that false positives cannot be allowed ever, once there is a false positive the tools is worthless.

Yes yes, indeed. The ability to look at what's happening step by step really hamstrings my imagination. Sorry, no. A debugger is a microscope! It will help you find problems faster and will seed your imagination by filling in what is really going on. It's an augmentation, like any tool. Or do you prefer to stare into space blindfolded?

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

#239

Post by tsimionescu »

hither_shores wrote: post #237
tsimionescu wrote: post #187

Earlier quoted context omitted.

Funnily enough, there are some applications for converting mechanics problems to analogous electricity problems to leverage circuit simulation software such as PSPICE to help solve things like transcendental equations.

Yes, but the mapping doesn't change the relationship between the units of measure, which is the actual meaning as far as the type system is concerned. It's just a change of names.

Sure, I wasn't meaning to detract from the comment above, just to point out what I thought was an interesting related fact.

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

#240

Post by Barrin92 »

hither_shores wrote: post #175
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…

> this is a classic case of not needing more types but needing proper names. Those are types.

no. a type is a description of a set of values and its associated operations. Types impose global meaning on entities in your program. When something belongs to a certain type receivers of arguments of that type lose control over how to interpret them. Thus types introduce coupling.

Names are just labels attached to an entity for the purpose of identification and readability, they don't impose meaning.

Post reply on HN