Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScripting the technical interview

richard-towers.com

Post reply on HN
Print view View original

91–100 of 180 posts

Re: TypeScripting the technical interview

#91

Post by TheCleric »

eyelidlessness wrote: post #90
TheCleric wrote: post #89

Earlier quoted context omitted.

Any doesn't mean "doesn't care". Any means "YOLO, do whatever you want, I'm one of those cool parents who'll let you smoke and drink beer."

What is the distinction?

The distinction is just because you "don't care" about the values right now, nothing stops the next developer (including future you) from needing the values.

So now you've gone from not caring to "enabling someone to shoot themselves in the foot" if they don't read the types of the parameters carefully. That's the difference.

Re: TypeScripting the technical interview

#92

Post by eyelidlessness »

TheCleric wrote: post #87
eyelidlessness wrote: post #56

Earlier quoted context omitted.

If the function is doing something with the values which is unsafe, sure. My point was the more relaxed constrain on the type signature can be used to imply it’s only concerned with the dictionary’s keys.

Then use unknown. Either you know what's in the dictionary and can type it or you don't. Stop being lazy.

I’m not being lazy? I am taking extra time and expending extra energy to make sure the metadata I put in code is as informative as possible. In this use case `any` carries more information. I use `unknown` in place of `any` exactly as it’s intended wherever I’m able.

Also, please don’t continue to be a jerk at me.

Re: TypeScripting the technical interview

#93

Post by eyelidlessness »

TheCleric wrote: post #91
eyelidlessness wrote: post #90

Earlier quoted context omitted.

What is the distinction?

The distinction is just because you "don't care" about the values right now, nothing stops the next developer (including future you) from needing the values. So now you've gone from not caring to "enabling someone to shoot themselves in the foot" if they don't read the types of the parameters carefully. That's the difference.

The case I was trying to convey doesn’t narrow the actual type for anything outside its own function body. Any footgun that exists after the function call already existed before it. It just implies “I’m only looking at your keys not your values”.

Re: TypeScripting the technical interview

#94

Post by TheCleric »

eyelidlessness wrote: post #92
TheCleric wrote: post #87

Earlier quoted context omitted.

Then use unknown. Either you know what's in the dictionary and can type it or you don't. Stop being lazy.

I’m not being lazy? I am taking extra time and expending extra energy to make sure the metadata I put in code is as informative as possible. In this use case `any` carries more information. I use `unknown` in place of `any` exactly as it’s intended wherever I’m able. Also, please don’t continue to be a jerk at me.

Okay I'll stop being a jerk and engage in good faith. I'll assume you think this is a valid use case for any and it communicates something important.

My counterpoint is this: communication involves two things, someone stating a message and someone receiving a message. You are doing part one. Is part two occurring? It may be because of certain conventions in your codebase or team, but I've personally never seen any used in that manner ever, so I would not receive your intended message.

If I were in the same situation I would use unknown and add a comment stating that the type is of no importance since I'm only worried about the keys. That way my message is clear and I prevent future developers from having to debug code where they assume the value is of a certain type and start accessing parameters and methods that do not exist.

Re: TypeScripting the technical interview

#95

Post by TheCleric »

eyelidlessness wrote: post #93
TheCleric wrote: post #91

Earlier quoted context omitted.

The distinction is just because you "don't care" about the values right now, nothing stops the next developer (including future you) from needing the values. So now you've gone from not caring to "enabling someone to shoot themselves in the foot" if they don't read the types of the parameters carefully. That's the difference.

The case I was trying to convey doesn’t narrow the actual type for anything outside its own function body. Any footgun that exists after the function call already existed before it. It just implies “I’m only looking at your keys not your values”.

I gathered what you meant. My point is what stops the next developer working on your codebase from adding code in the body of your function that accesses the values of the object in an unsafe way?

Re: TypeScripting the technical interview

#96

Post by TheCleric »

TheCleric wrote: post #94
eyelidlessness wrote: post #92

Earlier quoted context omitted.

I’m not being lazy? I am taking extra time and expending extra energy to make sure the metadata I put in code is as informative as possible. In this use case `any` carries more information. I use `unknown` in place of `any` exactly as it’s intended wherever I’m able. Also, please don’t continue to be a jerk at me.

Okay I'll stop being a jerk and engage in good faith. I'll assume you think this is a valid use case for any and it communicates something important. My counterpoint is this: communication involves two things, someone stating a message and someone receiving a message. You are doing part one. Is part two occurring? It may be because of certain conventions in your codebase or team, but I've personally never seen any us…

As an addendum if the function only needs the keys I would possibly just have the parameter be a string[] that expected the user to call object.Keys to pass to.

That way the function isn't asking for parameters it doesn't really care about.

Though I do get the appeal of having the function call object.Keys if it's called frequently so as not to have to sprinkle that call everywhere.

Re: TypeScripting the technical interview

#97

Post by eyelidlessness »

TheCleric wrote: post #94
eyelidlessness wrote: post #92

Earlier quoted context omitted.

I’m not being lazy? I am taking extra time and expending extra energy to make sure the metadata I put in code is as informative as possible. In this use case `any` carries more information. I use `unknown` in place of `any` exactly as it’s intended wherever I’m able. Also, please don’t continue to be a jerk at me.

Okay I'll stop being a jerk and engage in good faith. I'll assume you think this is a valid use case for any and it communicates something important. My counterpoint is this: communication involves two things, someone stating a message and someone receiving a message. You are doing part one. Is part two occurring? It may be because of certain conventions in your codebase or team, but I've personally never seen any us…

> You are doing part one. Is part two occurring?

Valid feedback. I even thought of adding it myself, because implied stuff isn’t obvious. I felt it worth communicating because there’s value in what’s implied that isn’t available in the type system. To the extent I have team members consuming the same code, I would definitely communicate the intent. To the extent I have reviewers who read the code, I do discuss it.

To the extent this is in a type parameter position, the onus is on the person writing the function signature and… well if they don’t want a footgun, they have every opportunity to not gun their foot. But that’s entirely opt in by the time they’ve reached that point.

Re: TypeScripting the technical interview

#98

Post by eyelidlessness »

TheCleric wrote: post #96
TheCleric wrote: post #94

Earlier quoted context omitted.

Okay I'll stop being a jerk and engage in good faith. I'll assume you think this is a valid use case for any and it communicates something important. My counterpoint is this: communication involves two things, someone stating a message and someone receiving a message. You are doing part one. Is part two occurring? It may be because of certain conventions in your codebase or team, but I've personally never seen any us…

As an addendum if the function only needs the keys I would possibly just have the parameter be a string[] that expected the user to call object.Keys to pass to. That way the function isn't asking for parameters it doesn't really care about. Though I do get the appeal of having the function call object.Keys if it's called frequently so as not to have to sprinkle that call everywhere.

Yeah unfortunately it’s ergonomically A Thing to just accept object as input even if you only care about keys. Otherwise I’d have the exact signature you describe.

Re: TypeScripting the technical interview

#99

Post by eyelidlessness »

TheCleric wrote: post #95
eyelidlessness wrote: post #93

Earlier quoted context omitted.

The case I was trying to convey doesn’t narrow the actual type for anything outside its own function body. Any footgun that exists after the function call already existed before it. It just implies “I’m only looking at your keys not your values”.

I gathered what you meant. My point is what stops the next developer working on your codebase from adding code in the body of your function that accesses the values of the object in an unsafe way?

A bit of trust. I’m not aware of a type system that protects my coworkers from my bad decisions, only those humans do that.

Re: TypeScripting the technical interview

#100

Post by TheCleric »

eyelidlessness wrote: post #97
TheCleric wrote: post #94

Earlier quoted context omitted.

Okay I'll stop being a jerk and engage in good faith. I'll assume you think this is a valid use case for any and it communicates something important. My counterpoint is this: communication involves two things, someone stating a message and someone receiving a message. You are doing part one. Is part two occurring? It may be because of certain conventions in your codebase or team, but I've personally never seen any us…

> You are doing part one. Is part two occurring? Valid feedback. I even thought of adding it myself, because implied stuff isn’t obvious. I felt it worth communicating because there’s value in what’s implied that isn’t available in the type system. To the extent I have team members consuming the same code, I would definitely communicate the intent. To the extent I have reviewers who read the code, I do discuss it. To…

I think at this point we'll agree to disagree.

I will offer this as a middle ground that I'm not even 100% sure will work since I'm not in front of a TypeScript interpreter.

What about just defining it as object? Would work for object.Keys, but not sure how the function consumers would get along with it.

Post reply on HN