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

Learn how to unleash the full potential of the type system of TypeScript

type-level-typescript.com

Post reply on HN
Print view View original

221–230 of 256 posts

Re: Learn how to unleash the full potential of the type system of TypeScript

#221

Post by schwartzworld »

galaxyLogic wrote: post #220
schwartzworld wrote: post #201

Earlier quoted context omitted.

> That gives a pretty good insight for anybody reading the code as to what "type" of arguments the function expects. If you test Only true if you're using very simple types, i.e. number and string. But "string" is pretty close to "any" and doesn't give you much info. If my function only expects two or three possible strings, it should be typed to only take those ones. Comments are not a solution for much of anything,…

> Comments are not a solution for much of anything, What are Unix man-pages but comments about the APIs they describe? Are you saying you would prefer to replace them with the TypeScript type-language? As I see it TypeScript is a a solution to the problem of how to describe a function, what it does, what it expects from its arguments and what it returns. That information can often be clearly and simply expressed with…

> What are Unix man-pages but comments about the APIs they describe?

Documentation. Obviously not the same thing as inline comments in the code. You can generate documentation using comments (i.e. jsdoc), but comments are the weakest form of guidance for other developers. Types don't replace documentation, but are part of the same goal: making code easier to consume.

> When type-declarations become more complicated than the code they are describing

Do you find this happening to you often? JavaScript is a very permissive language, and most JS devs learn to write code in a way that is difficult to type. That's a part of the learning curve of the language. Part of using TS well, is realizing that complicated types are a smell for complicated behavior, and modeling your data in a conceptually simple way.

It's not just about labeling everything string or number, but making it impossible to use the code the wrong way.

> But if a declaration is very complicated how can we be sure there's no errors in it?

Simple. You test them. Same as any other code. How do you test your comments?

Re: Learn how to unleash the full potential of the type system of TypeScript

#222

Post by hither_shores »

solardev wrote: post #155
davnn wrote: post #152

Earlier quoted context omitted.

Imho it’s kind of pointless to judge how simple a type definition looks like. The definition is there to make sure the interface is correctly typed. Edit: and sometimes a simple/beautiful interface requires complex types..

When I'm using someone else's code, though, I need to be able to understand what it's expecting and returning... isn't that the point of a typing system? It's not just an internal unit test, but a signal to other developers of how the function is supposed to work (especially if it's exported and intended for reuse). Quite often I get a function that's working correctly but typed incorrectly (including in someone else…

> I think it's like that because they had to hack it on top of Javascript

This is the source of most of typescript's flaws, but the mediocre type syntax was a deliberate choice: it's all erased at compile time, so javascript imposes no constraints. My guess is that it's just because many of the original typescript devs were on the C# language team.

Re: Learn how to unleash the full potential of the type system of TypeScript

#223

Post by valenterry »

patrec wrote: post #218
solardev wrote: post #213

Earlier quoted context omitted.

That's a good point. Like even if TypeScript goes away, some other language will still use generics and higher order functions. I can see the value in that!

My 2 cents: I think the fact that you're having trouble with the compose signature is something you should rectify and that would transfer well to other languages. I'm however not sure the same holds true for more advanced features of typescript. I'm only a casual user, so take this with more than a grain of salt, but for me typescript occupies quite a weird point in statically typed language space: on the other hand…

This reply is pretty good. As a Scala developer, many people have told me that a lot of features of the Scala compiler are niche and will go away. I never thought so - and now a good part of then has appeared in Typescript and some in Rust. Python is also pushing forward with optional typing.

Therefore I think the chance is high that even if there are currently not too many languages with advanced features (generics are not advanced btw), we will see more and more of them in the future.

Re: Learn how to unleash the full potential of the type system of TypeScript

#224

Post by laumars »

kuschku wrote: post #210
laumars wrote: post #164

Earlier quoted context omitted.

The thing with electrical plus is that they should be designed around safety first, rather than convenience. And the U.K. plug is a lot more safety focused than many other plug standards. The advantage of the U.K. plug is that live pins are physically blocked and only released when the Earth pin is present. This is why the Earth pin is slightly longer on U.K. plugs and why insulated devices have a plastic Earth pin r…

And now try the Schuko, which improves on all metrics you named (except the polarity isn't fixed, that's its one theoretical disadvantage), but also significantly improves usability (you can plug it in either way, the plug goes in much easier, and it stays in with much more force)

It’s a good design but I disagree that it improves on all the safety features. For starts the child proof safety shutters are still only optional in some regions.

> except the polarity isn't fixed, that's its one theoretical disadvantage

Polarity isn’t fixed on any mains sockets. That’s why the A in AC stands for “alternating”

Re: Learn how to unleash the full potential of the type system of TypeScript

#225

Post by remram »

aussiesnack wrote: post #85

Looks good. Given the course is unfinished, it's a shame the only way to get updates is via a third party corporate web site ("Twitter"). RSS would be the obvious way to go.

Twitter seems like a good way to miss it. I don't check Twitter every day...

Re: Learn how to unleash the full potential of the type system of TypeScript

#226

Post by wrycoder »

laumars wrote: post #224
kuschku wrote: post #210

Earlier quoted context omitted.

And now try the Schuko, which improves on all metrics you named (except the polarity isn't fixed, that's its one theoretical disadvantage), but also significantly improves usability (you can plug it in either way, the plug goes in much easier, and it stays in with much more force)

It’s a good design but I disagree that it improves on all the safety features. For starts the child proof safety shutters are still only optional in some regions. > except the polarity isn't fixed, that's its one theoretical disadvantage Polarity isn’t fixed on any mains sockets. That’s why the A in AC stands for “alternating”

And yet there is a big difference between the hot and neutral conductors in a 120V outlet in the US. The neutral remains close to ground potential, and is actually bonded to earth at the breaker panel.

Re: Learn how to unleash the full potential of the type system of TypeScript

#227

Post by nawgz »

likeclockwork wrote: post #144
nawgz wrote: post #90

Earlier quoted context omitted.

> That boundary is why I have a hard time taking TypeScript seriously. A type system that doesn't participate in code generation is what How is being able to check code correctness at compile-time even close to "just linting and documentation basically"? This has to be a bad faith argument > Worse there is one value that is both a user-definable TypeScript type and a JS value. What does this even mean? I don't think…

It's just fancy documentation. It doesn't contribute to behavior at all. Typescript can describe polymorphism, lamely, but it can't drive it.

> It doesn't contribute to behavior at all

I agree that TypeScript, in and of itself, doesn't change the way the code executes. This is self-evident.

But the idea that that makes it simply "fancy documentation" is hilarious. I have never seen documentation that can tell you at compile-time how your code will behave, it's fundamentally stupid to argue that static type checking is in any way comparable with documentation

Re: Learn how to unleash the full potential of the type system of TypeScript

#228

Post by aussiesnack »

remram wrote: post #225
aussiesnack wrote: post #85

Looks good. Given the course is unfinished, it's a shame the only way to get updates is via a third party corporate web site ("Twitter"). RSS would be the obvious way to go.

Twitter seems like a good way to miss it. I don't check Twitter every day...

I don't have (or want) a Twitter account, which kind of rules me out.

Re: Learn how to unleash the full potential of the type system of TypeScript

#229

Post by 29athrowaway »

solardev wrote: post #153
29athrowaway wrote: post #150

Earlier quoted context omitted.

It's very simple to understand. You don't have to actually read the definition just know what "compose" does at a high level.

What compose() does is not the point here, it's that the type definition is totally unreadable. I was trying to figure out what compose was supposed to return (the function or the value), in that case, and I still don't really know. Another random example from Axios: (onFulfilled?: (value: V) => T | Promise , onRejected?: (error: any) => any): number; Or eslint: type Prepend = ((_: Addend, ..._1: Tuple) => any) exten…

Well, you are likely taking examples from library internals.

Libraries exist, in part, to encapsulate high complexity.

There's likely accompanying documentation for the examples you provided.

In some other languages you have similar stuff, with the added complexity of concurrency and memory management related types. If you are struggling with TypeScript, let me tell you about a whole new world of pain called C++.

That's why I think every programmer should learn C++.

Re: Learn how to unleash the full potential of the type system of TypeScript

#230

Post by galaxyLogic »

schwartzworld wrote: post #221
galaxyLogic wrote: post #220

Earlier quoted context omitted.

> Comments are not a solution for much of anything, What are Unix man-pages but comments about the APIs they describe? Are you saying you would prefer to replace them with the TypeScript type-language? As I see it TypeScript is a a solution to the problem of how to describe a function, what it does, what it expects from its arguments and what it returns. That information can often be clearly and simply expressed with…

> What are Unix man-pages but comments about the APIs they describe? Documentation. Obviously not the same thing as inline comments in the code. You can generate documentation using comments (i.e. jsdoc), but comments are the weakest form of guidance for other developers. Types don't replace documentation, but are part of the same goal: making code easier to consume. > When type-declarations become more complicated t…

> You can generate documentation using comments (i.e. jsdoc),

So comments are a solution to something. Don't TypeScript programmers use them as well?

Post reply on HN