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

171–180 of 180 posts

Re: TypeScripting the technical interview

#171

Post by alexgrover »

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.

Coming back to this after the other thread cooled down a bit lol - to me, unknown actually implies that the function doesn’t care about the values more than any, as the compiler will enforce that they’re unused.

And in any case, I’d almost always lean towards the option with stronger type safety guarantees. Especially in a team environment when someone else may be modifying your code later. As a convention, I almost never use any.

Re: TypeScripting the technical interview

#172

Post by bruce343434 »

siriusfeynman wrote: post #72
tantalor wrote: post #69

Earlier quoted context omitted.

> N-Queens is a classic backtracking problem that gets asked a lot during interviews. https://fizzbuzzed.com/top-interview-questions-3/

Which is exactly the point, it's a leetcode question that tests whether you've memorised a bunch of leetcode interview questions

you're supposed to be able to come up with the solution by yourself

Re: TypeScripting the technical interview

#173

Post by WorldMaker »

aw9f70gae wrote: post #144
girvo wrote: post #73

Earlier quoted context omitted.

I know my mind is decidedly poisoned when I could follow the type definitions perfectly, and they reminded me of certain types I have written myself… ah, TypeScript, what have you done to me…

How does one even come close to such wizardry

Deep diving into lib.d.ts and DefinitelyTyped dealing with the weird boundary space between poorly typed JS and strongly typed TS can teach a lot these days.

Also, being able to recognize the Peano S-function on sight (and thus uses of Church-Peano numbers) is a fun part of that wizardry. (Maybe not necessary to remind the usefulness of the Lambda Calculus canon on a site named after one of the most famous combinators.)

Re: TypeScripting the technical interview

#174

Post by WorldMaker »

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.

It is true and it is terrible. Woe to be a programmer. The Church-Turing Theorem implies it is almost impossible for any languages exhibiting recursion to not be (Church-)Turing Complete. It is easy to forget how deeply, darkly, and deceptively simple the Lambda Calculus is. It is easy to forget that anywhere you may splice in something that even gently resembles the Lambda Calculus you may draw out the frightening runes of the many eldritch combinators many of which are indeed subject to accidental infinite recursion and The Halting Problem. (Including the infamous Y combinator.)

I have seen the Typescript "computing this type lead to what appeared to be infinite recursion and I gave up" errors. The compiler is well built, it mostly does not truly crash in an exceptional case like that, but it does have to use hard, practical heuristics to avoid getting stuck in infinite loops (including harsh stack depths and calculation timeouts for type checking).

Re: TypeScripting the technical interview

#175

Post by WorldMaker »

eyelidlessness wrote: post #105
TheCleric wrote: post #100

Earlier quoted context omitted.

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 {}.…

I think with Map the answer is somewhere between momentum ("we've always used objects as dictionaries") and some misapprehensions easily shifted with basic caniuse statistics. Map still feels "too new" to some developers, despite being ES2015 (8 years old now!) and available in every browser that supports the arrow operator for functions has Map (and Set) out of the box (no need for polyfills in 2023, ever).

Probably the only other reason I've seen is "JSON interop" is "hard" because Map doesn't natively serialize. I think `new Map(Object.entries(oldDictionaryObject))` and `Object.fromEntries(someMap.entries())` are sufficient for most serializer boundary cases (even without feeling fancy and doing that as a true JSON revivifier/resolver pair).

Re: TypeScripting the technical interview

#176

Post by jholman »

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…

I'm having trouble grasping what this has to do with bootcamps. Isn't that the totality of the value of your original comment, implying that you had some trick for identifying bootcamp graduates?

Re: TypeScripting the technical interview

#177

Post by cben »

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.

https://3fx.ch/typing-is-hard.html is a neat summary, and yes the situation is worse than most programmers would guess: Most industry languages, including "boring" reliable ones like C++, Java or Rust have _undecidable_ type systems;( and quite a few are unsound as well.)

This doesn't mean type systems are useless! But as GP said there are tradeoffs, and suspiciously many language designers gave up "clean" properties like guaranteed-terminating compiler, or you know actually guaranteeing run-time safety...

BTW, TypeScript documents where it's unsound and why consciously made those choices: https://www.typescriptlang.org/docs/handbook/type-compatibil...

Re: TypeScripting the technical interview

#178

Post by cben »

mrlkts wrote: post #129

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?

There are 2 components here. One is the "type metaprogramming" - (mis)use of the type system to implement to do compile-time computation, mainly by using parametrized types as kinda-functions + type inference for kinda-pattern-matching.

The other is building up basic "data types" by pretty standard lambda calculus > LISP route. "Understanding Computation" book has a great chapter 6 on that, which is available in blog & video forms on https://computationbook.com/extras - Here, Church numerals were used to represent numbers. - booleans & conditionals here didn't resort to the lambda representation you'll see in the book, but relied on type conditionals builtin to TypeScript. - The names "Cons" & "nil" are a ringer for LISP-like building of lists, and recursive processing of lists, from a "pair" data type.

Re: TypeScripting the technical interview

#179

Post by cben »

cben wrote: post #178
mrlkts wrote: post #129

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?

There are 2 components here. One is the "type metaprogramming" - (mis)use of the type system to implement to do compile-time computation, mainly by using parametrized types as kinda-functions + type inference for kinda-pattern-matching. The other is building up basic "data types" by pretty standard lambda calculus > LISP route. "Understanding Computation" book has a great chapter 6 on that, which is available in blog…

Sorry, i misspoke about "Church numerals". The book uses them to represent non-negative integers by lambdas but here that wasn't necessary, TypeScript allowed a simpler representation of N as a the type of an N-deep nested list.

What's common to both approaches to building arithmetic is starting from zero + a "successor" function T. That approach is called "Peano arithmetic".

I still recommend that post/video (and the book in general) but I have to admit there is no 1:1 correspondence to the TypeScript going on here.

Still, it'll teach you some general maneuvers for bootstrapping computation out of almost nothing , qnd once you're comfortable with those, you can read things like this TypeScript post, or aphyr's original Haskell post, which bootstrap computation out of sjighly different" almost nothings" and without following the details still have a high-level idea of where it's going (like the poor interviewer in the story ;-)

Re: TypeScripting the technical interview

#180

Post by eyelidlessness »

alexgrover wrote: post #171
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.

Coming back to this after the other thread cooled down a bit lol - to me, unknown actually implies that the function doesn’t care about the values more than any, as the compiler will enforce that they’re unused. And in any case, I’d almost always lean towards the option with stronger type safety guarantees. Especially in a team environment when someone else may be modifying your code later. As a convention, I almost…

To me `unknown` signals an intent to know, as in “I don’t know yet” (or put another way, “I don’t have any prerequisites for accepting this value, I can and will narrow it as appropriate”). In a codebase that otherwise takes type safety seriously, `any` in a type parameter (again to me) means “I don’t have any type narrowing agenda for this thing, it’s along for the ride and coming out the other side the same way it showed up”.
Post reply on HN