TypeScripting the technical interview • Hacker News Board

Re: TypeScripting the technical interview

#121

Post by eyelidlessness » Mon, Mar 13, 2023, 5:26 AM UTC

consilient wrote: post #113

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

> It just implies “I’m only looking at your keys not your values”. That's what `unknown` is for. `any` behaves like `never` (in covariant positions), which is exactly the opposite.

I don’t think that’s how `any` behaves in any position, but I’d be happy to be corrected. Please show me how `any` is treated as `never`.

Re: TypeScripting the technical interview

#122

Post by trhr » Mon, Mar 13, 2023, 5:43 AM UTC

8n4vidtmkvmk wrote: post #110

trhr wrote: post #108

Earlier quoted context omitted.

People who think code reviews are a thing imposed upon them by higher ups trying to make their job harder and not things designed to make their job easier don't understand how dev works at scale. People who would do things that "wouldn't pass the code review" for smaller companies are a primary reason so many smaller companies get hard-fucked when they have to scale. Arbitrarily deciding "this is too much work for me…

FWIW I do both. I work for a top tier tech company and I write pretty commit messages, test my code, and all that jazz. But for the side-project I do at home? You bet I'm cutting corners. I also think the guts of a TS function don't matter much though. Write a test to confirm the behavior is correct, and then make the return type and argument types correct so that people can call it without hassle. If you need to use…

I'm a Principal at a 2nd tier tech company.

My personal projects are more rigorous than my work projects. I don't have time to maintain them, so I have to be sure to not fuck them up.

Re: TypeScripting the technical interview

#123

Post by winrid » Mon, Mar 13, 2023, 5:47 AM UTC

Well written. I laughed hard at "he asserts, wrongly".

I wish TS didn't evolve into this complexity. Library types that should be simple turn into a machine you have to understand (for no good reason).

Re: TypeScripting the technical interview

#124

Post by illiarian » Mon, Mar 13, 2023, 6:33 AM UTC

nine_k wrote: post #101

throw2311 wrote: post #81

Earlier quoted context omitted.

All useful type systems are turning complete. The only people who don't realise are those that want to rewrite everything in rust.

Were this true it would be terrible, because Turing-completeness necessarily includes non-termination. This would mean that a compiler would crash, or get stuck in an infinite loop.

This also probably means that you really need to start writing tests for your types :)

Re: TypeScripting the technical interview

#125

Post by consilient » Mon, Mar 13, 2023, 6:47 AM UTC

eyelidlessness wrote: post #121

consilient wrote: post #113

Earlier quoted context omitted.

> It just implies “I’m only looking at your keys not your values”. That's what `unknown` is for. `any` behaves like `never` (in covariant positions), which is exactly the opposite.

I don’t think that’s how `any` behaves in any position, but I’d be happy to be corrected. Please show me how `any` is treated as `never`.

Here's a close to minimal example:

    const anyToNeverHelper = (t: any): number & T => t
    const absurd: never = anyToNeverHelper(0)

Re: TypeScripting the technical interview

#126

Post by eyelidlessness » Mon, Mar 13, 2023, 7:26 AM UTC

consilient wrote: post #125

eyelidlessness wrote: post #121

Earlier quoted context omitted.

I don’t think that’s how `any` behaves in any position, but I’d be happy to be corrected. Please show me how `any` is treated as `never`.

Here's a close to minimal example: const anyToNeverHelper = (t: any): number & T => t const absurd: never = anyToNeverHelper (0)

This is a good example of how `never` is treated as `never`. Everything is assignable to the bottom type and intersecting with it will always be the bottom type, by definition. It’s also a good example of how the top type `any` casts to whatever you choose, because that’s also by design. Both types are vacant, the bottom type is infectious. That’s a good thing. And it works the same way with `unknown`, which it also should because once something is known to be part of the null set it should stay known as the null set.

Re: TypeScripting the technical interview

#127

Post by lozenge » Mon, Mar 13, 2023, 8:13 AM UTC

irrational wrote: post #66

lozenge wrote: post #43

Earlier quoted context omitted.

Only if you want to get hired.

I’ve been hiring developers for decades at a Fortune 100 company and have never engaged in such nonsense. Unless you are hiring people to program chess sets, the question in the article is foolish. If you want to test their problem solving or coding skills, give them a problem from the actual work they will be doing at your company.

Username isn't accurate - you should be called rational.

Re: TypeScripting the technical interview

#128

Post by hmcamp » Mon, Mar 13, 2023, 8:31 AM UTC

Thanks @ycitm. I learned a lot from this post!

Re: TypeScripting the technical interview

#129

Post by mrlkts » Mon, Mar 13, 2023, 8:45 AM UTC

I've got a CS related degree, but I'm a mostly self-taught dev, and not understanding 90% of the code really makes me reevaluate my career choices. Where and how can I learn this stuff?

Re: TypeScripting the technical interview

#130

Post by consilient » Mon, Mar 13, 2023, 9:07 AM UTC

eyelidlessness wrote: post #126

consilient wrote: post #125

Earlier quoted context omitted.

Here's a close to minimal example: const anyToNeverHelper = (t: any): number & T => t const absurd: never = anyToNeverHelper (0)

This is a good example of how `never` is treated as `never`. Everything is assignable to the bottom type and intersecting with it will always be the bottom type, by definition. It’s also a good example of how the top type `any` casts to whatever you choose, because that’s also by design. Both types are vacant, the bottom type is infectious. That’s a good thing. And it works the same way with `unknown`, which it also…

> Everything is assignable to the bottom type

Other way around: everything is assignable to the top type (`unknown`), and the bottom type (`never`) is assignable to everything.

> It’s also a good example of how the top type `any` casts to whatever you choose

Which is precisely why `any` isn't the top type: if you allow `any`, then types no longer form a lattice, and there is no bottom or top.

If you restrict yourself to a sound fragment, then `unknown` is the top type. Compare `(x: unknown) => boolean` (two inhabitants up to function extensionality) to `(x: any) => boolean` (infinitely many inhabitants).

> And it works the same way with `unknown`, which it also should because once something is known to be part of the null set it should stay known as the null set.

But `unknown` isn't the null set: it's the "set" (insofar as we're pretending that types are sets of values, which isn't quite true) of all terms.