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

101–110 of 180 posts

Re: TypeScripting the technical interview

#101

Post by nine_k »

throw2311 wrote: post #81
cjbprime wrote: post #12

In case folks miss the link at the top of the article, this is translated from an old 2017 post by Aphyr. That post was in Haskell, where it's not too surprising that you can do serious computation inside the type system. This new post translates the ideas to TypeScript, which is more widely known, and which I once heard described as having "accidentally Turing-complete" types: https://github.com/microsoft/TypeScript…

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.

Re: TypeScripting the technical interview

#103

Post by nine_k »

8n4vidtmkvmk wrote: post #47
dec0dedab0de wrote: post #3

So he wrote all that for the typescript lsp to respond with the answer, but when it compiles down it's nothing? And we're using runes as variables just because? That is pretty neat, and silly. I also think it highlights my natural aversion to static type checking in dynamic languages. I know that I could get sucked into writing a bunch of code for the checker, instead of using my energy for making the application wor…

this is why i love ts when not working for a megacorp. when the ts gets too cray i just nope out. throw an any or as in there and get on with my day. wouldn't pass a code review but i don't care

In a megacorp, an SRE in production would have to deal with a rare error condition which the compiler tried to complain about.

But in a smaller shop, oncall are developers, that is, ourselves.

Re: TypeScripting the technical interview

#104

Post by throw2311 »

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.

Yes, this is why unsafe exists. It tells the typing system to take a hike and let the natural Turing completeness of types happen. Trying to explain to people who don't understand higher order functions that types are the first rung of an infinite ladder of meta languages is like trying to explain the colour blue to nematodes.

Re: TypeScripting the technical interview

#105

Post by eyelidlessness »

TheCleric wrote: post #100
eyelidlessness wrote: post #97

Earlier quoted context omitted.

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

> What about just defining it as object?

That’s pretty much the intent of the constraint. I don’t have time to sit with a type checker right now, but I don’t think we disagree as much as you might think. I arrived at this from years of trying to find the best way to express types which are as strict as possible with as much clarity as possible.

Unfortunately the object type is basically any non-null value, as is {}. They both intuitively mean what I want. They also inherently allow PropertyKey keys, which is effectively Record, which is looser than the “dictionary” type I often want to accept in these scenarios.

A better question (for me, and maybe you and maybe all of us who want type certainties) is why we even accept dictionaries in object shapes when Map is the obvious expression of that type. I’ve repeatedly wanted that and shied away from it because it requires too much change for very little gain.

Re: TypeScripting the technical interview

#106

Post by jholman »

trhr wrote: post #74
rexpop wrote: post #55

Earlier quoted context omitted.

This is a jab (insult), and I've flagged it, but I am also curious. If you could, please describe the qualities of a "bootcamp" grad by which you recognize them? Edit: especially pertaining to type inference, I guess?

If you wanted to have a conversation, you wouldn't have flagged it. So, no.

I didn't flag it, and I'm curious too.

Re: TypeScripting the technical interview

#107

Post by eyelidlessness »

TheCleric wrote: post #100
eyelidlessness wrote: post #97

Earlier quoted context omitted.

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

Completely aside from these details, thank you for stepping back and discussing this in good faith. It made a discussion that was going badly feel at least like communication. I appreciate that, and I’m glad to land at a place where we’re not necessarily on the same page but we’re at least recognizing we have similar priorities. Cheers!

Re: TypeScripting the technical interview

#108

Post by trhr »

jholman wrote: post #106
trhr wrote: post #74

Earlier quoted context omitted.

If you wanted to have a conversation, you wouldn't have flagged it. So, no.

I didn't flag it, and I'm curious too.

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 to do, so I'm going to take a shortcut" may not be the sign of a bootcamper, but it's certainly the sign of a shitty dev.

Either way, it's not someone I'll ever work next to. Elite teams don't hire people who think like that. We hire junior devs who are like "I write idempotent commits with good titles and descriptions, and I and use strict typing everywhere." Because it's easier to be teach them "actually, nobody's ever going to read your description. You can usually leave it out. You could use 'any' here. Just ticket it to be fixed so you can replace it later."

Point is 'any' shouldn't pass a code review without someone asking "why'd you use 'any' here." If you have a great answer, it will pass the code review.

Re: TypeScripting the technical interview

#109

Post by efficax »

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.

yes, all turing complete type systems make it possible to define type structures that would cause infinite loops, but typically they are able to detect this and refuse to compile

Re: TypeScripting the technical interview

#110

Post by 8n4vidtmkvmk »

trhr wrote: post #108
jholman wrote: post #106

Earlier quoted context omitted.

I didn't flag it, and I'm curious too.

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 'any' or 'as' inside the function, then go for it.

Post reply on HN