TypeScripting the technical interview
161–170 of 180 posts
Re: TypeScripting the technical interview
#162Earlier quoted context omitted.
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…
Yep, sorry that’s what I meant.
> 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.
I’m not sure I understand.
> 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).
Sure, but I was referring to an exception I make for ignored parts of a type, in a type param. This example would be more analogous as:
boolean>
Which I hope makes my exception more clear, even if you don’t agree with it. It hopefully communicates that x is of interest and rest is not.> 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.
I was referring to never as the null set. Once you narrow anything—any, unknown, etc—to never, you can’t widen it to anything (without an unsafe cast of course).
Re: TypeScripting the technical interview
#163Pretty sad that computations on types look like C++98 in Typescript when C++ itself has moved on to have much more concise ways of performing computations on types in C++11 and 14 (see boost hana).
Interestingly TypeScript compiler doesn't use types for compilation (that's why you can have esbuild that compiles Typescript without understanding the type system). That is the end result of type computation is... Nothing, always, just like in OP. Template metaprogramming is all about code generation. You would expect them to look different.
Re: TypeScripting the technical interview
#164Earlier quoted context omitted.
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.
How do you get around properties assigned via Object.defineProperties recognised by TS, though? I really don't know. Is is an unrelated question
Re: TypeScripting the technical interview
#165An amazing read, and almost perfect! There's a bug in the Solve "function" due to which you'll get the right answer only for 1x1, 5x5 and 7x7 (I checked till 8x8). The base case makes a wrong assumption that there will always be a candidate available for the last row. If there are no candidates available, it should return Nil, and backtrack. Basically, replace Concat with candidates extends Cons ? Cons : Nil
I've corrected this, and credited you in the errata - https://www.richard-towers.com/2023/03/11/typescripting-the-...
Re: TypeScripting the technical interview
#166https://www.typescriptlang.org/play?#code/PTAEEkDsAsEMBsCmAa...
Re: TypeScripting the technical interview
#167Well 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?
In this case it's using the type system to calculate the answer to a problem, which is not useful because the type system can't output anything to the console or do other IO. The "answer" will only be visible in your IDE.
The type system is powerful and extremely capable because it had to support existing javascript patterns, like "this function takes a parameter that might be a string or might be a number or might be an array" and make them type-safe.
Re: TypeScripting the technical interview
#168Earlier quoted context omitted.
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.
any is the last resort. How do you get around properties assigned via Object.defineProperties recognised by TS, though? I really don't know. Is is an unrelated question
interface IOptionsX {
x: number;
}
interface IOptionsY {
y: number;
}
const testObj: IOptionsX = {x : 0};
Object.defineProperties(testObj, {
y: {
value: 100,
writable: true
},
});
if ('y' in testObj) { // Could also do `&& typeof testObj.y === 'number'` to be VERY sure.
const testObjWithY = testObj as typeof testObj & IOptionsY;
console.log(testObjWithY.y)
}Re: TypeScripting the technical interview
#169Earlier 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
Re: TypeScripting the technical interview
#170Earlier quoted context omitted.
any is the last resort. How do you get around properties assigned via Object.defineProperties recognised by TS, though? I really don't know. Is is an unrelated question
Here's how I would do it: interface IOptionsX { x: number; } interface IOptionsY { y: number; } const testObj: IOptionsX = {x : 0}; Object.defineProperties(testObj, { y: { value: 100, writable: true }, }); if ('y' in testObj) { // Could also do `&& typeof testObj.y === 'number'` to be VERY sure. const testObjWithY = testObj as typeof testObj & IOptionsY; console.log(testObjWithY.y) }