I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
Hi Wayne, thanks for your post. I have more pragmatic view on such things like fp-ts. I have even forced it in one of projects what currently I consider as mistake. The thing is that you deliberetly don't compare your code with idiomatic examples with ifs and switches. And in my opinion such comparission would look bad for your fp-ts version which is just overcomplicated.
I see that the code is neat and uses some nice constructs, but still nobody will say it's more readable that few simple conditions. And conditions are nothing wrong, FP also is about making branching, and this is why all FP Lang's have pattern matching.
Also FP is not about typeclasses or high opaque types. You can make FP and use null. It has no such properties like Maybe, but with new operators like ?? and ?. It's not so bad. First of all in TS you see what can or can't be null and this is big value on its own.
I haven't used any other idomatic keywords like else or switch because I'm saving those for the next article when we explore Either.
As mentioned, it seems like over and is not simpler compared to using just the keywords.
The aim of the article is to show how we'd approach converting simple idiomatic JavaScript into using fp-ts.
We can use null in FP by how you may define it. I've defined it as using higher minded types like in Haskell and F#. HKT's allow composition, which is the most important element of a pleasurable functional programming experience.
If we follow the pattern of using HKT's, we get fantastic solutions for side effects and promises with Task and IO types due to their laziness.
We'll never have to await for promises again!
It is type with two values
You're right, Option is a type, not a typeclass. I'll change that now.
I don't fall anymore in high abstraction so often, I learned after my mistakes.
We still need to write code, which is inherently low level. The abstraction is for something like DDD. Lifting a little bit at low level using HKT's is great because we can define more complex models for our domain with these abstractions.
I read your article and took that into consideration when responding.
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
We can use null in FP by how you may define it. I've defined it as using higher minded types like in Haskell and F#. HKT's allow composition, which is the most important element of a pleasurable functional programming experience.
HKT is not about composition but about code reuse and pattern reuse. It allows for very high polimorhism. F# has no HKT.
If we follow the pattern of using HKT's, we get fantastic solutions for side effects and promises with Task and IO types due to their laziness.
Again you can make these abstractions without HKT. For me FP is great but I really don't need HKT in a language which doesn't support it. HKT fits great where it is idiomatic so in Haskell or PureScript. TypeScript not support HKT, and what fp-ts is doing is a hack.
HKT is not about composition but about code reuse and pattern reuse
I feel like pattern reuse is composition, which means that HKT is compositional by nature.
How would you define composition?
F# has no HKT.
That's correct, sorry about that. I don't know F# very well, but it looks like it has HKT because it's got the Async<T> type and it has methods, just like a typeclass, to manipulate code in async world. Thanks for mentioning this.
Again you can make these abstractions without HKT
We can, such as with fluture: lazy promises.
I really don't need HKT in a language which doesn't support it. HKT fits great where it is idiomatic so in Haskell or PureScript. TypeScript not support HKT, and what fp-ts is doing is a hack.
The "hack" is what makes it special. If it wasn't we'd just use purescript.
I feel like more people move to fp-ts than to purescript because being close to the javascript specification is important.
Maybe because it's familiar, maybe because it drives the internet, maybe because it integrates well into existing codebases.
People and companies are seeing use cases which require these compositional aids. Grammarly is just one of them, which they did a talk on describing their use case.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Wayne, thanks for your post. I have more pragmatic view on such things like fp-ts. I have even forced it in one of projects what currently I consider as mistake. The thing is that you deliberetly don't compare your code with idiomatic examples with ifs and switches. And in my opinion such comparission would look bad for your fp-ts version which is just overcomplicated.
I see that the code is neat and uses some nice constructs, but still nobody will say it's more readable that few simple conditions. And conditions are nothing wrong, FP also is about making branching, and this is why all FP Lang's have pattern matching.
Also FP is not about typeclasses or high opaque types. You can make FP and use null. It has no such properties like Maybe, but with new operators like ?? and ?. It's not so bad. First of all in TS you see what can or can't be null and this is big value on its own.
I don't think it is right. Maybe implements many typeclasses but not is one. It is type with two values.
I don't fall anymore in high abstraction so often, I learned after my mistakes.
My full point about using Nullable vs Maybe you can find here - maybe just Nullable
I haven't used any other idomatic keywords like else or switch because I'm saving those for the next article when we explore Either.
As mentioned, it seems like over and is not simpler compared to using just the keywords.
The aim of the article is to show how we'd approach converting simple idiomatic JavaScript into using fp-ts.
We can use null in FP by how you may define it. I've defined it as using higher minded types like in Haskell and F#. HKT's allow composition, which is the most important element of a pleasurable functional programming experience.
If we follow the pattern of using HKT's, we get fantastic solutions for side effects and promises with Task and IO types due to their laziness.
We'll never have to await for promises again!
You're right, Option is a type, not a typeclass. I'll change that now.
We still need to write code, which is inherently low level. The abstraction is for something like DDD. Lifting a little bit at low level using HKT's is great because we can define more complex models for our domain with these abstractions.
I read your article and took that into consideration when responding.
I see your fascination for HKT.
HKT is not about composition but about code reuse and pattern reuse. It allows for very high polimorhism. F# has no HKT.
Again you can make these abstractions without HKT. For me FP is great but I really don't need HKT in a language which doesn't support it. HKT fits great where it is idiomatic so in Haskell or PureScript. TypeScript not support HKT, and what fp-ts is doing is a hack.
I feel like pattern reuse is composition, which means that HKT is compositional by nature.
How would you define composition?
That's correct, sorry about that. I don't know F# very well, but it looks like it has HKT because it's got the
Async<T>type and it has methods, just like a typeclass, to manipulate code in async world. Thanks for mentioning this.We can, such as with fluture: lazy promises.
The "hack" is what makes it special. If it wasn't we'd just use purescript.
I feel like more people move to fp-ts than to purescript because being close to the javascript specification is important.
Maybe because it's familiar, maybe because it drives the internet, maybe because it integrates well into existing codebases.
People and companies are seeing use cases which require these compositional aids. Grammarly is just one of them, which they did a talk on describing their use case.