TypeScript’s quirks: How inconsistencies make the language more complex • Hacker News Board

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#161

Post by chmod775 » Sat, Feb 01, 2020, 2:24 PM UTC

IggleSniggle wrote: post #88

chmod775 wrote: post #68

Earlier quoted context omitted.

This. My network code uses them everywhere on the client side. It's frankly amazing. Your server side code should have runtime validation though. You can't and shouldn't rely on TypeScript there for security reasons.

I don't quite follow. Discriminated unions allow you to derive the type from the runtime validation. If the runtime finds these properties then it must be one of these , but if it finds those then it's one of those. If it can't fit into one of those type buckets as defined by runtime validation, then its . The types flow from the validation algebraically.

I'm assuming you don't understand why you shouldn't use discriminated unions for server-side validation?

Client (JSON) messages will pretty much always start out as any, and you can't assume they fit your union any way shape or form. Taking the Cat|Dog example from the article, a client may pass {"kind":"cat", "bark": "woof"} and if you just go blindly from there to the union and then try to narrow that down, you've got yourself a problem.

You should use a library like JOI (or type guards with custom validation) to first make sure it fits your union type, then you can go wild with discriminated unions.

I always wanted a library that could perform runtime validation given a typescript type, but so far typescript doesn't expose enough type information in decorators for this.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#162

Post by BorisTheBrave » Sat, Feb 01, 2020, 2:26 PM UTC

kjtekn wrote: post #150

nicoburns wrote: post #127

Earlier quoted context omitted.

Type systems can be thought of as low-cost (in terms of dev time) declarative tests. Which should leave you with less to test in your actual tests. They also give much quicker feedback than tests.

No longer enjoying programming is a cost nobody can afford to pay. When I read the long list of c#, I mean typescript documentation, it gives me PTSD from c# and java, which people used to hate here, but now suddenly like and let me tell you it has nothing to do with microsoft social engineering.

Devs should enjoy writing trivial tests? Heaven forbid businesses might care how quickly something is delivered?

Let us know when you are willing join the rest of us in the real world.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#163

Post by cryptica » Sat, Feb 01, 2020, 2:27 PM UTC

lazarljubenovic wrote: post #155

cryptica wrote: post #132

>> Real world JavaScript is inconsistent, messy, and complicated JavaScript is consistent. Expressive languages such as JS are consistent in their permissiveness. It doesn't stop developers from doing irrational things like comparing objects with numbers just like TypeScript doesn't stop developers from writing all other kinds of flawed logic. TypeScript basically only protects code from typos. The worst bugs I see i…

You obviously never wrote TypeScript with strict flag turned on. It does control flow analysis, not just typo checking.

It does 'Control Flow Based Type Analysis' - Meaning that it only analyzes control flow for the sole purpose of determining type correctness which adds almost no value to the project.

It doesn't prevent asynchronous control flow issues like for example;

- Having two different parts of the code simultaneously (asynchronously) mutating the same object and causing data inconsistencies.

- Your code starts a new asynchronous job (e.g. setInterval) in the background without killing the previous/existing job which was launched earlier.

- An event listener was registered for the same event multiple times (e.g. from inside another event handler) without unregistering the previous listener and so every event now triggers multiple updates instead of one (and CPU usage keeps going up and you have a memory leak).

- It doesn't tell you when you forgot to trigger a specific event

- Or guarantee that two different parts of your code never run in parallel (asynchronously) when mutating some state.

- Or that you missed an edge case and forgot to update a specific instance's property

- Or that you were modifying the original instance of the object instead of merely a copy/clone of it as you assumed (or the opposite was necessary and you made the reverse assumption)

Only a human brain can prevent those issues (and the list of such difficult issues is practically infinite; my list is a tiny sample) and those are the real issues in software development, not typos and auto-completion.

Unless you're a web developer and your job only involves writing static webpages, you are likely to encounter much more difficult problems in your career besides not having automatic method name completion or typo prevention mechanisms. These problems I described above are complex enough that they make all the problems solved by TypeScript seem negligible. TypeScript's compile time delay becomes a bottleneck when trying to debug and resolve real difficult problems.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#164

Post by lscharen » Sat, Feb 01, 2020, 2:43 PM UTC

cryptica wrote: post #126

twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

I still don't see the value added by TypeScript. My JavaScript tests catch typoed property names every time. I can't remember the last time I merged code with a typo in a property name. IMO, if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.

If TypeScript is used against bog-standard JS code, I can definitely appreciate your point.

For me, TypeScript really started to shine once I started taking advantage its generic support, higher-level utility types like Pick and Optional (and really anything involving keyof), and creating static type checks via the unknown and never types.

This is especially effective when working on legacy JS code bases where unit tests and other good engineering principles were not used well, or at all.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#165

Post by marcosdumay » Sat, Feb 01, 2020, 2:44 PM UTC

hopia wrote: post #157

sjy wrote: post #50

Earlier quoted context omitted.

I’m not a very skilled Haskell programmer, but every time I’ve tried to parse JSON in it I’ve felt a strong urge to switch back to Python or JavaScript. There are libraries that make it easier but I think it’s always going to be hardly to get started with JSON APIs in a language with a powerful and strict type system. Of course, that extra up-front effort might be worth it in the long run due to the benefits of type…

Aeson parsing seems straightforward to me, not sure it could be easier in any language. Serialization from your endpoint is automatic, based on your data types. The real benefit of using a well typed language here is that you only need to parse the data once at this point, after that the type system makes sure the data is of correct format everywhere else in your codebase.

Aeson is not straightforward at all. Just try doing what the GP is saying he wants to do, you will discover you can't.

It is a very good library if you control both sides of the communication, and have fit for purpose interfaces. Otherwise, you are better with any lower level library.

Besides, what is it with the strictness of Haskell JSON libraries? There's nothing that will even accept Window's BOM.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#166

Post by vhakulinen » Sat, Feb 01, 2020, 3:02 PM UTC

kjtekn wrote: post #149

redmorphium wrote: post #143

Earlier quoted context omitted.

Some Typescript value added: - Living documentation: types are a clear description of how your code and its data are laid out, and this structure is kept always up-to-date with the code, regardless of future changes. If the "documentation" (the typing) is wrong, the compiler will complain. - Better tooling: autocomplete, more robust auto-refactoring - Elimination of an entire class of bugs. This class may include: 1.…

Lets be honest here, these reasons are really weak. Living documentation - TypeScript is less readable. There is more stuff you have to read. Stuff that isn't even relevant. I see a "cars" variable. Oh no, I don't know what type it is, I am going to have a panic attack. Don't worry that cars.map((c) => c.model); is the next line or whatever. What type is it, I must know! auto-refactoring.. yeah we all trust that. Unt…

> TypeScript is less readable.

What makes you say so? I find it more readable than javascript.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#167

Post by kod » Sat, Feb 01, 2020, 3:04 PM UTC

etripe wrote: post #153

namelosw wrote: post #71

Earlier quoted context omitted.

> a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problem. Come on, Typescript is more modern than C#. It's just started to being bloated a little bit since there are advanced type operators against structural typings. Or if you have to use a modern example, languages like Scala or Rust are more like it. Also guaranteed compile + runtime is not what C# is. Probably…

Typescript is certainly newer than C#. So are Scala and Rust. Modernity and novelty are two different things, though.

Scala was released within a couple years of c#. Typescript and Rust were a decade later.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#168

Post by vhakulinen » Sat, Feb 01, 2020, 3:06 PM UTC

cryptica wrote: post #126

twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

I still don't see the value added by TypeScript. My JavaScript tests catch typoed property names every time. I can't remember the last time I merged code with a typo in a property name. IMO, if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.

> My JavaScript tests catch typoed property names every time.

My typescript compiler catches typoed property names every time.

> I can't remember the last time I merged code with a typo in a property name.

I can't remember the last time my newly written code made it into the runtime/browser with a typo in a property name.

> ...if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.

The types are much more than just property names.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#169

Post by marcosdumay » Sat, Feb 01, 2020, 3:15 PM UTC

rtpg wrote: post #97

earthly wrote: post #20

I still don't understand what pulls developers to Typescript. The examples given show major flaws in this (duck)type system. That it works when you don't use the 'any' type and when you know how to avoid all the edge cases and workarounds, I know. But when I see an example like this: const shasta = new Cat("Maine Coon") printDog(shasta) > Dog:Maine Coon I see a huge red flag. Coming from C/C++ it looks like a joke. W…

Structural typing and actual first class union types in typescript are better than basically all the ML-based languages. Dumb example: imagine you had Animal = Dog | Cat Person = Plumber | Driver If you want a list of “stuff” in your system , in typescript you just say you have Person | Animal. In ML languages you would need to introduce an Either type so you’re working with Either Person Animal. So now in your code…

What you are describing is still an ADT. It's just a different syntax.

Indeed, your examples of the TS syntax are more convenient than ML, but that is reversed when going the other way, and decomposing the types into smaller sums instead of composing.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#170

Post by jolux » Sat, Feb 01, 2020, 3:24 PM UTC

garethrowlands wrote: post #152

jolux wrote: post #81

Earlier quoted context omitted.

Java interfaces are not structurally typed, are they?

No but it's the closest available. Two classes C1 and C2 that both implement interfaces I1 and I2 can be said to have a common structure. That is, if they both implement I1 and I2 then they have that structure in common.

Yeah but that’s still fully nominal typing, you can’t implement the interface implicitly, it has to be identified by name.