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

81–90 of 180 posts

Re: TypeScripting the technical interview

#81

Post by throw2311 »

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.

Re: TypeScripting the technical interview

#82

Post by Aeolun »

nicolas-siplis wrote: post #4

I remember reading the original version and thinking "Ah, this would be so much more grokkable if only I knew Haskell"... Delusions of grandeur are a marvelous thing!

Well, it certainly feels more grokkable than the haskell one. It’s like understanding is at the tip of my tongue instead of forever out of reach.

Still don’t understand anything though.

Re: TypeScripting the technical interview

#83

Post by Aeolun »

joenot443 wrote: post #6

Well written and super funny. Reminded me a bit of Scott’s writing, particularly the descriptions of the horrified interviewer. I’ve never worked in a Typescript shop, is there any truth to the satire here? The sea of confusing types to solve any problem?

I daresay the forest of types to validate our endpoint input/output is intimidating to many, but this post is on a whole different level.

Re: TypeScripting the technical interview

#87

Post by TheCleric »

eyelidlessness wrote: post #56
alexgrover wrote: post #37

Earlier quoted context omitted.

The problem with that is that when consuming of the dictionary, “doesn’t know” is actually more appropriate. If you then access Object.values(foo) in your method you are given an iterable of anys which is unsafe.

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.

Re: TypeScripting the technical interview

#88

Post by TheCleric »

oblak wrote: post #25
TheCleric wrote: post #18

Earlier quoted context omitted.

I tell my fellow developers at work: "Any is banned. If you want any, use JavaScript, and we don't use JavaScript here. Perhaps you haven't heard about unknown?" In my experience, 90% of the time when a developer uses any, they just don't know about unknown. 9% it's because they are lazy. 1% is because you are implementing something from an imported library, and they fell into the other 99%.

Use "unknown" and TS complains that you're treating something as an object. Use Object.defineProperties and TS complains because that stuff is invisible to it after how many years? I think you're right, of course, but TS is hardly perfect and treating its ways as gospel is not an improvement over JS. The "right ways" change over time and beliefs are not shared among everyone.

If you know what's in the object cast it as that type or be sure by saying if ('propertyName' in unknownObject).

TS is far from perfect. These aren't its ways (it provides any, so of course it's fine with it). These are my restrictions: if you're using a type system, actually use it. Don't lie to yourself and throw anys in your code.

Re: TypeScripting the technical interview

#89

Post by TheCleric »

eyelidlessness wrote: post #31
TheCleric wrote: post #18

Earlier quoted context omitted.

I tell my fellow developers at work: "Any is banned. If you want any, use JavaScript, and we don't use JavaScript here. Perhaps you haven't heard about unknown?" In my experience, 90% of the time when a developer uses any, they just don't know about unknown. 9% it's because they are lazy. 1% is because you are implementing something from an imported library, and they fell into the other 99%.

I make an exception for using any in type params which extend type params, eg const foo = >(dict: T) => … This is a good signal that foo maps over dict in some generic way that cares more about its dictionary-ness than its values. Sure, unknown works in that position too, but at least IMO the “doesn’t care” bit is more informative than “doesn’t know”. The latter might imply more type narrowing will happen than is the…

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

Re: TypeScripting the technical interview

#90

Post by eyelidlessness »

TheCleric wrote: post #89
eyelidlessness wrote: post #31

Earlier quoted context omitted.

I make an exception for using any in type params which extend type params, eg const foo = >(dict: T) => … This is a good signal that foo maps over dict in some generic way that cares more about its dictionary-ness than its values. Sure, unknown works in that position too, but at least IMO the “doesn’t care” bit is more informative than “doesn’t know”. The latter might imply more type narrowing will happen than is the…

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