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

171–180 of 256 posts

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

#171

Post by rolfvandekrol »

solardev wrote: post #166
rolfvandekrol wrote: post #161

Earlier quoted context omitted.

compose is a higher order function. In the first step it accepts a function that converts 3 values (V1 to V3) into a single values (T1) and a series of conversion functions that converts this single value into another value (T1 into T2, T2 into T3 and so on until T6). Using these functions it produces a new function that converts the combination of V1, V2 and V3 into a T6. I don't know ramda, but I assume this is onl…

Yes, that's correct... compose() pipes a bunch of passed functions from right to left. Here's the actual type definition if you want to see: https://github.com/googol/DefinitelyTyped/blob/6836f798cb186... But even at its simplest variant, with just one or two functions passed, what the V0 or T1 do is pretty confusing. I thiiiiiiiiink it's trying to ensure the return type of one function is correctly passed as the inp…

It indeed ensures one a type level that this series of functions can work as a series so every subsequent function can accept the return type of the previous one.

The latest version seems to have abandoned the typing of the initial input, which makes the types a little simpler.

My point however is that the types you point our here are actually not particularly complex. They are just long, with lot's of inputs for the generics (and the syntax may be confusing). The types in the original article are much more complicated, with conditional type inference etc.

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

#172

Post by brabel »

laumars wrote: post #164
jongjong wrote: post #140

Earlier quoted context omitted.

My coding philosophy is centered around simple interfaces. I think of power sockets and plugs. The simpler the socket/plug design, the easier it is to plug in. It's easier to connect a European plug which has 2 round pins than it is to connect a UK plug which has 3 rectangular pins at different angles. You can imagine how difficult it would be to connect a plug with 10 pins; it would be difficult to get the alignment…

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…

I don't think the discussion really was about plugs.

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

#174

Post by seer »

cercatrova wrote: post #30
seer wrote: post #24

Earlier quoted context omitted.

haven’t used it myself but other teams at the company I work for have tried with mixed results. It’s very opinionated about the way you structure your code and basically makes anything thats not fully fp-ts hard to integrate, and also is quite hard for general JS people to wrap their head around. It’s been designed by FP people for FP people and if there are some on your team who are not fully on board or are just st…

That sounds about what I've expected. Frankly in a TS codebase with many other devs that are not versed in FP, I wouldn't want to bring in a pure FP library because it, like you said, needs everyone to understand the "meta-language" of FP so to speak, such as how monads work, not having raw side effects, mutation etc. Ramda et al seem like a good compromise. Looking through its docs though, doesn't JS have a lot of t…

Well currying is a big one, and also functions like flow/pipe (in lodash/fp) mimic piping in FP languages which allows for very nice expressions of business logic for modifying data.

You can sometimes loose the type though, so I prefer to do it with off the shelf filter/map/reduce even if its a bit unsightly.

I personally reach for lodash/fp for more specific expressions like orderBy or groupBy. There are some very nice well documented and powerful primitives there.

At one team a guy got so enamored with the functional style that he went ahead and rewrote mountains of logic in lodash/fp. And it turned out quite hard to maintain by the rest of the team, so you also have the danger of “overdoing it for the rest of the team” danger as well.

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

#175

Post by valenterry »

tobyhinloopen wrote: post #64
cogman10 wrote: post #26

A great idea. Now, everyone that learns this stuff, show some restraint! The drawback of a powerful type system is you can very easily get yourself into a type complexity mudhole. Nothing worse than trying to call a method where a simple `Foo` object would do but instead you've defined 60 character definition of `Foo` capabilities in the type system in the method signature. Less is more.

True that. Once types get so complex, I’ve no idea what’s going wrong. Today I had code running fine but throwing errors all over the place because some deeply nested type mismatch between two libraries. I just any’d it… i aint got no time for that shit

You maybe just lack experience with more complex types. Which is totally expected, since you probably learned programming the runtime all the time, but not the typesystem - unless you come from one of those rare languages that have a similar powerful typesystem.

But just like you probably struggled with and overcame many things before, it will be the same now. It's just that you can opt out of the typesystem in typescript whereas you are forced to learn how to deal with the runtime.

But if you make it, your development experience will change drastically. The time might be very well spent.

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

#176

Post by KronisLV »

nsxwolf wrote: post #154
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.

I've been professionally employed as a software developer since 1998 and I am currently curled up in a ball in the corner rocking slowly back and forth after seeing that.

Personally, I think the equivalent code would look bad in most languages, even with more verbose argument/type names and comments (which people seem to overlook often) - it's just that we try to make our applications do a bit too much.

Just look at some of other examples in the sibling comments!

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

#177

Post by valenterry »

solardev wrote: post #147
nsxwolf wrote: post #143

I currently have to occasionally contribute to a TypeScript codebase at work. I appreciate how much better it is than Javascript. When I write code as an outsider (Java and Go developer), I feel like I use the type system in sensible and readable ways. When I look at the code written by the native TypeScript experts in my company it is a bewildering, abstract, unreadable morass. I have no idea what's going on half th…

Yeah, what a terrible syntax :( Just today I was looking at the type definition for a third-party lib (ramda)... what the heck does this even mean... compose (fn5: (x: T5) => T6, fn4: (x: T4) => T5, fn3: (x: T3) => T4, fn2: (x: T2) => T3, fn1: (x: T1) => T2, fn0: (x0: V0, x1: V1, x2: V2) => T1): (x0: V0, x1: V1, x2: V2) => T6; Got it?

Funny thing: what you are complaining about here is in fact a lack of power in typescripts typesystem.

And even that verbose signature is better than none imo.

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

#178

Post by mirekrusin »

laumars wrote: post #164
jongjong wrote: post #140

Earlier quoted context omitted.

My coding philosophy is centered around simple interfaces. I think of power sockets and plugs. The simpler the socket/plug design, the easier it is to plug in. It's easier to connect a European plug which has 2 round pins than it is to connect a UK plug which has 3 rectangular pins at different angles. You can imagine how difficult it would be to connect a plug with 10 pins; it would be difficult to get the alignment…

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…

When I was a kid before we had legos we had some soviet alternative called constructor or something. Everything was made from metal, crews etc. obviously as a kid one of the first “hello world” things you will build is “plug” that you can insert into those holes in the wall. My older brother was lucky when he did it as the fuse in the house went off. My younger brother did the same about a decade later but holding in his hand two metal pins. He was also lucky that my dad was just passing through corridor and pushed him out. He got away with just burned skin on the fingers and a bit of shock.

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

#179

Post by valenterry »

solardev wrote: post #169
patrec wrote: post #165

Earlier quoted context omitted.

> 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. It returns a function. The one that's equivalent to applying the arguments in reverse order. I think that this signature is pretty clear for anyone experienced with a statically typed language with generics and higher order functions. On the other hand, I have no idea why a compos…

> I think that this signature is pretty clear for anyone experienced with a statically typed language with generics and higher order functions. Sounds like I have stuff to study! Maybe ramda was an extreme example (with or without typescript, it was so hard to read that our dev team decided to just remove it altogether and replace it with more verbose but easier to read vanillaJS code or equivalent lodash functions).…

From what you are writing, you really lack the basics here. Learning on the job is fine, but sometimes it's worth to spent dedicated time to learn foundations or at least get someone on board who can teach them.

I suggest to try to get your boss to sponsor this, since you need it for the job. It will also make your dev experience so much more fun!

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

#180

Post by meheleventyone »

cogman10 wrote: post #26

A great idea. Now, everyone that learns this stuff, show some restraint! The drawback of a powerful type system is you can very easily get yourself into a type complexity mudhole. Nothing worse than trying to call a method where a simple `Foo` object would do but instead you've defined 60 character definition of `Foo` capabilities in the type system in the method signature. Less is more.

Less is more is also important for writing performant code. JS engines care about types, in the form of ‘shapes’ which is the V8 term for a specific structural layout and maps pretty neatly to TS structural types for obvious reasons. Simple types make performance issues like megamorphic inline cache issues much harder to create. If you see type spaghetti it’s a good hint that performance issues may be lurking depending on actual runtime usage. And if your runtime usage is actually simple then you don’t particularly need the flexibility the type spaghetti provides.
Post reply on HN