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

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

blog.asana.com

Post reply on HN
Print view View original

171–180 of 216 posts

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

#171

Post by jolux »

alexcole wrote: post #55
potatoz2 wrote: post #41

Earlier quoted context omitted.

It just means that structural types are the default and you need to opt in to nominal types, when necessary: https://www.typescriptlang.org/play/?ssl=13&ssc=1&pln=13&pc=... (there are other ways as well) In something like Java, it's the opposite: you get nominal types by default and you need to opt in to structural types (via interfaces). Because TS is built on a duck typed language, tons of existing libraries would…

I think that Flow’s approach of using nominal types for classes and structural for everything else makes more sense. Are there really cases you expect classes to be structural types?

Objects in OCaml are all structurally typed.

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

#172

Post by heavenlyblue »

bt4u wrote: post #108
ketzo wrote: post #94

Earlier quoted context omitted.

Yup. Rather than bringing 100,000 devs from one typed language to another, Typescript brings 1,000,000 devs from untyped to typed.

There's no such thing as an untyped programming language that's used in the real world. JavaScript and typescript definitely aren't. Maybe you mean dynamically typed

There’s always that “intellectual” who would say something smart while being absolutely wrong.

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

#173

Post by lazarljubenovic »

cryptica wrote: post #163
lazarljubenovic wrote: post #155

Earlier quoted context omitted.

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 asynchron…

> the list of such difficult issues is practically infinite

Precisely. No matter how good a language is, you can always say "but it doesn't do xyz". If you want to replace the human brain by a language, then you're looking for AI, not a language.

I understand what you mean, and I agree that these things are lacking from TypeScript. And I would love them. TypeScript is slowly adding more and more things, mitigating issues one by one, which were previously dissed off by developers with "it doesn't even do xyz".

I have my job because my brain is smarter than TypeScript's compiler. And it does help me, because I know which things I don't have to think about anymore, based on how I write the code. So it does help me, because I think less about the set of problems which it DOES solve.

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

#174

Post by hopia »

marcosdumay wrote: post #165
hopia wrote: post #157

Earlier quoted context omitted.

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.

Fair enough, you're probably right, I have only used it in contexts where I build both sides of the application.

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

#175

Post by firethief »

Findeton wrote: post #106
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…

As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks. However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using…

Have you considered OCaml with BuckleScript or js_of_ocaml? The language that inspired Rust's nods to FP can be compiled to mostly-idiomatic Javascript.

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

#176

Post by IggleSniggle »

chmod775 wrote: post #161
IggleSniggle wrote: post #88

Earlier quoted context omitted.

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…

But wouldn't what you're talking about just be a union type? We might be saying the same thing. The "discriminated" part of discriminated union means that you will be performing the runtime validation to check which of Cat or Dog it is, and only once it receives those validations do you have a derived type. By asserting that the object received is Dog only if it has kind:dog bark:string, you've narrowed your type at compile time to only types that have bark.

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

#177

Post by greenshackle2 »

DonHopkins wrote: post #137
kazinator wrote: post #98

Earlier quoted context omitted.

If you can pass a Cat to a Dog function, where is the better checking? That would be one of the hello-world test cases for a type checker bolted on to a dynamic language. That type checker itself has introduced the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.

CatDog typing sure looks, walks, and quacks a lot like Duck typing. https://en.wikipedia.org/wiki/CatDog https://en.wikipedia.org/wiki/Duck_typing

Kind of but not really. If you ask a "duck" to quack, duck typing is satisfied with any object that implements the quack method.

With structural typing, the type system will check that the "duck" not only quacks but also looks like and walks like a duck, before it is allowed to be asked to quack.

EDIT: of course with small enough interfaces you can get structural typing pretty close to duck typing, if you have interfaces "QuacksLikeDuck", "WalksLikeDuck", "LooksLikeDuck", etc. instead of one big "Duck" interface.

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

#178

Post by yawaramin »

loxs wrote: post #89
yawaramin wrote: post #70

Earlier quoted context omitted.

> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types. > This way you can have type safety without losing JS features. IMHO, you can't get type safety out of an unsound type system. (Which TypeScript…

The thing is... it doesn't seem to matter. After 30-40k lines of TS code (coming from OCaml) I am still to find a bug where OCaml would have done a better job, except for missing features like nominally typed primitives and no pattern matching. And these are hopefully coming to TS/JS

I recommend looking at your frontend console logs for instances of type errors a la https://rollbar.com/blog/top-10-javascript-errors/

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

#179

Post by yawaramin »

seanmcdirmid wrote: post #93
yawaramin wrote: post #70

Earlier quoted context omitted.

> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types. > This way you can have type safety without losing JS features. IMHO, you can't get type safety out of an unsound type system. (Which TypeScript…

TypeScript’s goal isn’t absolute type safety, the goal is feedback (eg code completion) and earlier detection of many errors.

Yes, I realize that's not the goal which is why I said 'by choice'. I just think it's not the right approach ultimately. Other safer languages also reach the goals of code completion and error detection.

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

#180

Post by [deleted] »

sjy wrote: post #50
arusahni wrote: post #46

Earlier quoted context omitted.

In strongly typed languages, there are serialization/deserialization libraries that don't require you to type the entire JSON object - just the fields you care about.

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…

[deleted]
Post reply on HN