181–190 of 391 posts
Typescript is for me one of the most overengineered programming languages. Why did JS not follow the way python and php did? Integrate types in the main language but make it optional.
Thank god they didn't follow the way Python did.
Earlier quoted context omitted.
WASM is the easiest target because you don't have to emulate an entire computer.
But in this case he kind of did anyway (at least the video makes reference to "L1 Instructions Cache").
Earlier quoted context omitted.
By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.
The "invert a binary tree" thing is a reference to a tweet by Max Howell [1] where he complains that he didn't get hired by Google even though he wrote Homebrew, which he estimates 90% of their engineers use. Howell describes himself as a "dick" [2], hadn't been involved with the Homebrew project for years, and has since gone on to write the NFT-based package manager Tea [3] and pkgx [4], which is an "everything app"…
I have had maybe two interviewers ever mention anything on my GitHub, which I usually include on my application/resume.
Earlier quoted context omitted.
Seems to also work without any: type Values > = T[keyof T]
Sure, there's many other ways to type it, but none adds any kind of additional safety or strictness over Record which was my point that `any` is the correct type in many cases, except when it widens a type. But in my case it's not widening anything, in Record , B can already be `any`thing. People tend to see it as an unsafe escape hatch (which is how it is abused), but it's just a set of all possible types.
`unknown` is the set of all possible types (it's the top type[0]). `any` goes beyond that—it basically turns off the type checker[1][2].
[0]: https://en.wikipedia.org/wiki/Top_type
[1]: https://tsplay.dev/mA9vXm
[2]: https://www.typescriptlang.org/docs/handbook/2/everyday-type...
One of the top comments in the video: > If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree The industry's hiring process is so messed up that this is completely believable. "We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for."
> I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well.
Earlier quoted context omitted.
Seems to also work without any: type Values > = T[keyof T]
Sure, there's many other ways to type it, but none adds any kind of additional safety or strictness over Record which was my point that `any` is the correct type in many cases, except when it widens a type. But in my case it's not widening anything, in Record , B can already be `any`thing. People tend to see it as an unsafe escape hatch (which is how it is abused), but it's just a set of all possible types.
[1] https://www.typescriptlang.org/docs/handbook/2/everyday-type...
[2] https://www.typescriptlang.org/docs/handbook/release-notes/t...
Nothing will ever top this for typescript types. This is the pinnacle. An entire virtual machine and system memory with garbage collector in types. Turing Completeness is one level, but being able to run Doom is the real test of whether a programming environment is complete and robust. Absolutely stunning to see TypeScript's type system get there.
Well we haven't implemented a web browser capable of running javascript in the typescript type system yet. Quick, someone tell this author it's not possible.
Earlier quoted context omitted.
Thank god they didn't follow the way Python did.
Python keeps the types at runtime, that's why no TypeScript framework will have a developer experience anywhere near something like FastAPI.
Earlier quoted context omitted.
Yes, but having a mechanic or engineer who's worked on the racecar your driver is in would be very helpful on your team.
And we're also not driving race cars, we're the pit crew... So you kinda do want mechanics... Like, literally, we build and fix the thing you're selling. We do not USE the thing we're building by and large.
Yes, thankyou, that's quite obvious judging by the quality of most software.
It really is amazing how bad most software made for non-developers is. Like, as software engineers, we understand how essential version control is. We made git and github for ourselves. But nobody has bothered building that functionality for people who edit word documents all day. Or people who edit video, or animators, or 3d modellers, or 100 different jobs. Word and google docs have track changes. But they don't let you bounce between branches or make pull requests. You usually can't time travel, or bisect, or git blame, or any of the other things we take for granted. My partner works in a CMS all day at work. Every change she makes is pushed directly to production. There's no review process. No staging. No testing. No change control or rollback. If anyone messes something up, they get blamed for "taking down the app". As a software engineer, I look on in horror.
I believe the more cognitive distance there is between 20-something silicon valley tech bros and your particular use case, the worse your software is going to be. If you're a manchild living in san francisco who can't be bothered driving, doing your laundry or shopping for groceries, you're in good hands. There is a startup that will solve your problem! But the further from that "ideal" you get, the worse. Here in Melbourne, I can't use my iphone to pay for public transit. Google maps couldn't really handle roundabouts (traffic circles) for a decade and change. (I guess they don't have those in California). Unicode support was only added recently because of Emoji. Until then, a huge amount of software butchered non-english text. I shudder to think how badly most software probably handles right to left languages. And the list goes on and on.