Reservations about TypeScript • Hacker News Board

Re: Reservations about TypeScript

#21

Post by forgotpw1123 » Sun, Aug 20, 2017, 2:10 AM UTC

The authors main complaints seem to focus around "but Typescript isn't ES6". I don't have a problem with this because Typescript compiles down to very clean vanilla JS. Unlike C++ to C, Clojure, and Babel the compilation down to JS is extremely good in comparison.

Good enough that I usually debug the Javascript output. Typescript has the cleanest transpilation I've ever seen so I don't have any problems with using it. And if Typescript ever falls out of vogue I'm confident just compiling down to JS one last time and being done with it. Really the language is so easy to get rid of its harmless.

Re: Reservations about TypeScript

#22

Post by barakm » Sun, Aug 20, 2017, 2:12 AM UTC

catnaroek wrote: post #19

barakm wrote: post #8

> TypeScript compiles down to JavaScript, which doesn’t have types or type checking, it’s impossible to have actual type checking. The TypeScript compiler is great at checking at compile time, but at the end of the day, it’s impossible to actually check the types. I'll point out that C/C++/Haskell compiles down to Assembly, which doesn't have types or type checking. GCC/LLVM/GHC is great at checking at compile time,…

> Obviously you can find ways to break out of the type systems (void* cast?) but that's on you Sometimes a type system can be proven to have no holes. (Of course, not counting the FFI, if any is provided.)

Sometimes, but very rarely, if only because of FFI as you pointed out.

And usually there's something in the unsafe category that lets you break some rules, if only to give a pressure release as in the interop reply above.

I don't deny the existence of such a thing, just that there aren't many practical examples

Re: Reservations about TypeScript

#23

Post by azangru » Sun, Aug 20, 2017, 2:22 AM UTC

> TypeScript fundamentally changes the way JavaScript works. JavaScript does not have classes. Even ES6 classes are just syntactic sugar on top of the ES5 prototypical inheritance. I’ll repeat it again. JavaScript does not have classes. The class keyword may exist in ES6+, but under the hood, it’s still just prototypical inheritance. As long as this is understood, it’s perfectly fine, but the problem comes when ES6+ or TypeScript is marketed as having “classes” in the traditional OOP sense of the word.

It looks like the author started out as saying one thing (how Typescript is fundamentally different from JS) and ended up with another (how they are fundamentally the same) :-)

Which reminds me. Could you please explain to me what are the proper classes? I guess I have spent too much time with JavaScript to start thinking about classes just as about collocations of methods and properties spewed out by constructors. What is so improper about JavaScript's prototype-based classes that is different in real classes?

Re: Reservations about TypeScript

#24

Post by nkohari » Sun, Aug 20, 2017, 2:23 AM UTC

anderskaseorg wrote: post #17

daviesgeek wrote: post #12

Earlier quoted context omitted.

All fair points and totally valid. My concern is the facade/promise of type security.

Your quarrel is not with JavaScript (as everyone else has pointed out, there’s no reason one can’t build a secure compile-time type system on top of JavaScript), but with some of the specific design decisions made by TypeScript that open soundness holes, such as “programmers are too stupid to understand the difference between covariance and contravariance, so we’ll pretend everything is bivariant”. See https://www.ty…

This gives an explanation of why they made the choice: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-fun...

Also, FWIW, in my experience, I don't think I've ever actually run into a problem with this in real code.

Re: Reservations about TypeScript

#25

Post by barakm » Sun, Aug 20, 2017, 2:32 AM UTC

azangru wrote: post #23

> TypeScript fundamentally changes the way JavaScript works. JavaScript does not have classes. Even ES6 classes are just syntactic sugar on top of the ES5 prototypical inheritance. I’ll repeat it again. JavaScript does not have classes. The class keyword may exist in ES6+, but under the hood, it’s still just prototypical inheritance. As long as this is understood, it’s perfectly fine, but the problem comes when ES6+…

The answer is, not much. They're shockingly similar. Both are achieving very similar ends through slightly different means (the subtlety of `virtual` in C++ leading to vtables) -- dynamic dispatch of a function based on an instantiation (a collocation of a method, as you called it)

How you implement inheritance under the hood and how you interpret the `class` keyword is another false distinction the author makes.

Re: Reservations about TypeScript

#26

Post by ctvo » Sun, Aug 20, 2017, 2:33 AM UTC

Harkins wrote: post #6

First point: "I found a bug but can't give an example." Second point: "It adds a feature that's different from a similar language." These are not persuasive arguments. I'm not trying to be unkind, but the first point is totally unsupported and the second doesn't elaborate on what's bad about classes besides that another language also has classes.

Conclusion:

> TypeScript brings some great features, but, in my opinion, it comes with some significant pitfalls that need to be addressed and realized before jumping in with both feet.

While listing none of the pitfalls unless the significant pitfall is classes mentioned a few paragraphs above.

This reads like it had much grander aspirations and ended up being published 30% through.

Re: Reservations about TypeScript

#27

Post by ctvo » Sun, Aug 20, 2017, 2:37 AM UTC

forgotpw1123 wrote: post #21

The authors main complaints seem to focus around "but Typescript isn't ES6". I don't have a problem with this because Typescript compiles down to very clean vanilla JS. Unlike C++ to C, Clojure, and Babel the compilation down to JS is extremely good in comparison. Good enough that I usually debug the Javascript output. Typescript has the cleanest transpilation I've ever seen so I don't have any problems with using it…

An aside: check out BuckleScript's OCaml -> JS work. It's even better than Typescript's output.

Some examples:

https://github.com/BuckleScript/bucklescript-addons/tree/mas...

Re: Reservations about TypeScript

#28

Post by wwwigham » Sun, Aug 20, 2017, 2:40 AM UTC

Not to pry, but do you have a Java background? I see you're using the global 'Boolean' and 'String' interfaces in your examples (which correspond to the equivalent JavaScript constructor objects), rather than the 'boolean' and 'string' primitive types. While it kinda works to use the interfaces instead of the primitives, the primitives, IMO have much more expected behavior in the type system, since, unlike the interfaces, they do not get compared structurally - TypeScript uses a structural type system for all objects, after all.

Re: Reservations about TypeScript

#29

Post by stupidcar » Sun, Aug 20, 2017, 2:41 AM UTC

That is an appalling article, even by Hacker News standards.

I mean, his second "reservation" is that TypeScript "fundamentally" changes JavaScript. How does he demonstrate this? By complaining that classes, which are a JavaScript feature, work differently than in other OO languages. What the hell does that even have to do with TypeScript?

Re: Reservations about TypeScript

#30

Post by phaed » Sun, Aug 20, 2017, 3:03 AM UTC

nkohari wrote: post #9

Sorry, I don't understand what this post is about, other than that you have some reservations about TypeScript. It's not really clear what those reservations are.

He started with the conclusion, then went and tried to look for reasons to support it. Problem is he came up short.