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

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

#211

Post by lexicality » Sun, Feb 02, 2020, 6:00 PM UTC

ravenstine wrote: post #187

lexicality wrote: post #158

Earlier quoted context omitted.

The only electron app I've ever used that wasn't slow/terrible is VSCode which happens to be written in typescript by Microsoft and it still occasionally decides to use 100% of my macbook's CPU making it entirely unusable until I restart, so I'm not sure that's a very good argument.

Do you think that's actually thanks to TypeScript? From what I know, TypeScript doesn't have an inherent performance quality that makes it better than JavaScript.

No, typescript has no impact on runtime performance that I know of.

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

#212

Post by drderidder » Mon, Feb 03, 2020, 2:50 PM UTC

After using TypeScript for the past couple of years, I've come to see it as simply another "embrace and extend" maneuver by Microsoft carve off a chunk of JavaScript mindshare, preying upon the naïveté of less-experienced developers who've fallen for the "static typing is safer" myth. TypeScript's decision to disallow JSDoc within .ts files [1] for example doesn't contribute anything positive to my impression of this syntactic pocket-protector. While the type hinting it provides is useful, the tradeoffs of added complexity, tool dependencies, and cross-compiling phase have made it more trouble than its worth in my opinion, particularly since tooling to provide code introspection and type hinting has already existed for a long time [2]. For new projects, I've begun using straight JSDoc, which is working beautifully with minimal setup [3] and provides all of the benefits I ever found useful about TypeScript, while remaining completely unobtrusive otherwise[4].

1. https://github.com/microsoft/TypeScript/issues/20774

2. https://ternjs.net/

3. https://medium.com/@trukrs/type-safe-javascript-with-jsdoc-7...

4. https://fettblog.eu/typescript-jsdoc-superpowers/

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

#213

Post by the_gipsy » Mon, Feb 03, 2020, 10:43 PM UTC

cryptica wrote: post #205

the_gipsy wrote: post #182

Earlier quoted context omitted.

I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums. In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful. On the other hand, I have an Elm project with no unit te…

Well designed tests lock down features not code. That's why I mostly write integration tests. I write unit tests once the project is stable and usually only for parts of the logic that are either very complicated or operationally critical. I try to avoid implementing 'very complicated' modules as much as possible.

Do you mean e2e tests? Because those are the only ones that test features. Integration tests are the biggest offenders of "code lockdown". They don't really test features, yet they have to observe too many implementation details.

Unit tests can't really lock down code, or then we shouldn't call those "unit" anymore.

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

#214

Post by kazinator » Mon, Feb 03, 2020, 11:22 PM UTC

dtech wrote: post #115

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.

> If you can pass a Cat to a Dog function, where is the better checking? If you have compatible method, fields and types, in a duck-typed ecosystem like Javascript it is a major boon that it is possible to interchange them, because it happens all the time in the ecosystem. The standard way to do enforce exactly the right interface in typescript if you need to is to add a `type: "cat" | "dog"` field to your Animal int…

What is a boon is that I can write code that accesses obj.breed and have it work with any object that has a breed property.

That has some downsides; it can be abused to create a ball of mud.

However, a middle-of-the-road type check which insists that an object must have all of the properties of Dog, even ones you're not using, isn't very useful. It kills the above dynamism, and yet allows abuses to sneak through.

You will not find that cats are being passed to Dog functions until you try to maintain Dog. And then you will discover that, oops, everything you add to Dog has to be replicated in Cat.

Basically, a typecheck which says that an object coming in has to have all the properties of Dog might as well just be a subclass check. The smart way to ensure that a non-Dog class has all the properties of Dog is inheritance.

A properly done static version of this structural type check would validate that the object being passed to the function doesn't have all the properties of a Dog, but that it has all the properties which just that function requires (including transitively: through any functions it calls).

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

#215

Post by kazinator » Tue, Feb 04, 2020, 5:21 AM UTC

redmorphium wrote: post #144

DonHopkins wrote: post #137

Earlier quoted context omitted.

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

From your second link: https://en.wikipedia.org/wiki/Duck_typing#Structural_type_sy... > Duck typing is similar to, but distinct from structural typing. Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time.

That looks like ooks like "original research". It's obvious that what is described as dynamic-only duck typing could be statically checked. So that is to say, a given expression foo.bar in the program could be statically checked to make sure that all possible values that foo takes on have property bar. If three classes A, B, C in the program have property foo, then this means verifying that foo is A | B | C. Thus, "static duck typing".

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

#216

Post by virtue3 » Thu, Feb 06, 2020, 9:35 PM UTC

sjy wrote: post #56

virtue3 wrote: post #22

Earlier quoted context omitted.

Because you can get some decent typing with some compiler help AND leverage the entire node/js eco system super easily. Which is kind of the whole point. As someone that's done c/c++/c#/lua/js/ts I've found typescript to be really awesome because it differentiates the types from the objects. Which has given me a much better appreciation of typing rather than the traditional OOP everything.

What do you mean by “differentiates the types from the objects”? Could you maybe offer an example comparing TS and C#?

in typescript I have something like

type theThing = { thing1: string, thing2: string };

and the actual object: const thing:Thing = { thing: 'hello', thing2:'more hello' };

"Thing" is not an object, I can't do Thing.new() etc. If I use a class in typescript it behaves just like you would expect C# / Java to.

This allows some really fun stuff with unions where I could do something like

const operateOnThings = (thing: Thing | Thing1 | Thing2) => { //do something based on what kind of thing it is }

Or I can build other types off of it like : type newThing = Pick & { newerThing: number};

Which is something I would have to do a lot of work with interfaces with in order to implement in C#. (I haven't done C# in a few years but I do love the hell out of it).