Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

`satisfies` is my favorite TypeScript keyword (2024)

sjer.red

Post reply on HN
Print view View original

201–210 of 217 posts

Re: `satisfies` is my favorite TypeScript keyword (2024)

#201

Post by locknitpicker »

ibejoeb wrote: post #197
locknitpicker wrote: post #112

Earlier quoted context omitted.

> If it's correct, it's not a maintenance nightmare, and it will alert you to problems later when someone wants to use it incorrectly. You're confusing things. It is a maintenance nightmare because it is your job to ensure it is correct and remains correct in spite of changes. You are the one owning that mess and held accountable for it. > If you're writing first-party software, it probably doesn't matter. But if you…

> Whoever feels compelled to write unintelligible character soup... I see it differently. That's the name of the game. Language design is always striving toward making it more intelligible, but it is reasonable to expect pros to have command of the language.

> I see it differently. That's the name of the game. Language design is always striving toward making it more intelligible, but it is reasonable to expect pros to have command of the language.

No, that's an extremely naive and clueless opinion to have. Any basic book on software engineering will tell you in many, many ways that the goal of any software engineer is to write simple code that is trivial to parse, understand, and maintain, and writing arcane and overly complex code is the Hallmark of an incompetent developer. The goal of a software engineer is to continuously fight complexity and keep things as simple as they can be. Just because someone can write cryptic, unintelligible code that doesn't make them smart or clever: it only makes them bad at their job.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#202

Post by CharlieDigital »

hermanradtke wrote: post #185
CharlieDigital wrote: post #181

Earlier quoted context omitted.

Zod is quite unpleasant to use, IME, an has some edge cases where you lose code comments. From experience, we end up with a mix of both Zod and types and sometimes types that need to be converted to Zod. It's all quite verbose and janky. I quite like the approach of Typia (uses build-time inline of JavaScript), but it's not compatible with all build chains and questions abound on its viability post Go refactor.

> we end up with a mix of both Zod and types and sometimes types that need to be converted to Zod In my code, everything is a Zod schema and we infer interfaces or types from the schemas. Is there a place where this breaks down?

Not that I know of aside from code comments (which I like), but I much prefer writing TypeScript to Zod

Re: `satisfies` is my favorite TypeScript keyword (2024)

#203

Post by baxuz »

epolanski wrote: post #3

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…

Being a JS/TS one-trick pony all my career, how does it compare to other languages? I don't really see much difference, except if comparing with some C++ shenanigans.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#204

Post by FlyingAvatar »

plaguuuuuu wrote: post #191
shortrounddev2 wrote: post #163

Earlier quoted context omitted.

The every day practice of software engineering has little to do with the academic discipline of computer science. What makes a good software engineer is not usually the same thing that makes a good CS major

but then you wind up with an entire repo, or an entire engineering team utterly hobbled by a lack of expressive typing (or advanced concepts generally) and debased by the inelegance of basic bitch programming.

Disclaimer: I'm not the OP, and there are certainly places where using recursive type definitions is justified.

My interpretation of OP's point is that excessive complexity can be a "code smell" on its own. You want to use the solution to match the complexity of the job and both the team that is building it and the one that is likely to maintain it.

As amused as I am by the idea of a dev team being debased by the inelegance of basic bitch programming, the daily reality of the majority of software development in industry is "basic bitch" teams working on "basic bitch" problems. I would argue this is a significant reason why software development roles are so much at risk of being replaced by AI.

To me, it's similar to the choice one has as they improve their vocabulary. Knowing and using more esoteric words might allow adding nuance to ideas, but it also risks excluding others from understanding them or more wastefully can be used as intelligence signalling more than useful communication.

tldr: Complexity is important when it's required, but possibly detrimental when it's not.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#205

Post by rjh29 »

imiric wrote: post #136
rjh29 wrote: post #109

Earlier quoted context omitted.

The idea is to make libraries preserve as much type information as possible, as a principle. Once type information is erased it can't be restored. For regular application code you don't need to use those features.

But regular application code also contains libraries. Type information is useful even if you're the only user of those APIs. My point was more related to the level of expressiveness required of a type system in order to allow a programmer to produce reliable code without getting in their way. I think TypeScript leans more towards cumbersome than useful. For example, I'm more familiar with Go's type system, which is o…

They're completely different languages, Javascript is dynamically typed, not sure how useful such a comparison is. TS's type system evolved out of a desire to encode the type relations of JS functions, often native ones, which are very dynamic and polymorphic. When writing application code you can keep things simple, but trying to represent all the ways types can change for the native libraries is harder.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#206

Post by SkyPuncher »

epolanski wrote: post #3

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…

I stopped doing anything advance because I realized nobody actually wanted to do all of the advanced stuff. None of the NPM community does anything more than the basics.

Frankly, I prefer it that way. A lot of the advance stuff doesn’t actually enable any new functionality. It only shortens the code paths for implementing.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#207

Post by lloydatkinson »

locknitpicker wrote: post #150
lloydatkinson wrote: post #7

Earlier quoted context omitted.

TypeScript codebases I've seen generally seem to have the widest demonstration of skill gap versus other languages I use. For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse. For these developers, the `type` ke…

> For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse. I think you're confusing things that aren't even comparable. The primary reason TypeScript developers use the likes of `any` is because a) TypeScript focus…

I think you’ve misunderstood what I wrote entirely.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#208

Post by lloydatkinson »

rtz121 wrote: post #169
lloydatkinson wrote: post #7

Earlier quoted context omitted.

TypeScript codebases I've seen generally seem to have the widest demonstration of skill gap versus other languages I use. For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse. For these developers, the `type` ke…

> For example, I don't ever see anyone using `dynamic` or `object` in C# I have bad news for you

Is your bad news that you primarily have to work in bad codebases? If so, sorry to hear that.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#209

Post by ibejoeb »

locknitpicker wrote: post #201
ibejoeb wrote: post #197

Earlier quoted context omitted.

> Whoever feels compelled to write unintelligible character soup... I see it differently. That's the name of the game. Language design is always striving toward making it more intelligible, but it is reasonable to expect pros to have command of the language.

> I see it differently. That's the name of the game. Language design is always striving toward making it more intelligible, but it is reasonable to expect pros to have command of the language. No, that's an extremely naive and clueless opinion to have. Any basic book on software engineering will tell you in many, many ways that the goal of any software engineer is to write simple code that is trivial to parse, unders…

I see where you're coming from. Do you think some of these books could help obviate some of my naivete and cluelessness?

Re: `satisfies` is my favorite TypeScript keyword (2024)

#210

Post by samdoesnothing »

locknitpicker wrote: post #192
samdoesnothing wrote: post #92

Earlier quoted context omitted.

Pushing everything to types like this creates a different burden where you're casting between types all over the place just to use the same underlying data. You could just clamp velocity to 200 in the callee and save all that hassle.

> Pushing everything to types like this creates a different burden where you're casting between types all over the place just to use the same underlying data. TypeScript does not perform any kind of casting at all. What TypeScript supports is structural typing, which boils down to allowing developers to specify type hints in a way that allows the TypeScript compiler to determine which properties or invariants are met…

If you have some `ConstrainedNumber` type, you will need to cast between it and `number`, either with a type assertion or with a type guard. In either case, when you use bespoke types everywhere you kill code reuse.
Post reply on HN