6 ms·

I get the idea of libraries like fp-ts and effect-ts, but like most libraries in this area, they are just boltons. I dont like to write unidiomatic code for giv

I get the idea of libraries like fp-ts and effect-ts, but like most libraries in this area, they are just boltons. I dont like to write unidiomatic code for given language if it is not designed for it. This means if i wrote a applicative that must satisfy homomorphism in javascript: APP.ap(APP.of(ab), APP.of(a)) = APP.of(ab(a)) Im pretty sure not a single dev would understand what the hell is going on, and i would have to buy quite a few beers to get that passed in a CR. I write idiomatic code for the language: Eg. In Go i loop and use mutability when its the correct thing to do, but in OCaml i almost exclusively use recursion and favour a monadic api, and javascript being a middle-ground i tend to just just the builtins map/filter/reduce and pals for most things. I dont need a monad for the sake of it. That said i tend to step out of this rule when it comes to errors, and avoid throwing as much as possible. Errors as values is invaluable.

epolanski 11mo ago
> Im pretty sure not a single dev would understand what the hell is going on, and i would have to buy quite a few beers to get that passed in a CR. That's a questionable example imho, for few reasons. The first is that understanding an applicative functor requires you to first understand map, apply and lift. Starting from an applicative, in any language, including Haskell, is like starting from a monad, (as you know very well they are almost the same thing as a monad is an applicative with one more rule) and then it's quite clear why we get endless blog posts that leave you no brighter. The second is that we're talking about TypeScript, not JavaScript. Let's make an example. Given a definition for map in TypeScript: map: <A, B>(f: (a: A) => B) => ((fa: F<A>) => F) which requires a minimal typescript understanding (a function from A to B and a value of type F<A> you get F) to read. If you can read map you can read ap in TypeScript: const ap: <A>(fa: F<A>) => (fab: F<(a: A) => B>) => F It's almost the same, with one major difference: you don't have a function from a to b, but one that is lifted in a datatype F, thus F<a => b>.

epolanski 11mo ago

> Im pretty sure not a single dev would understand what the hell is going on, and i would have to buy quite a few beers to get that passed in a CR. That's a questionable example imho, for few reasons. The first is that understanding an applicative functor requires you to first understand map, apply and lift. Starting from an applicative, in any language, including Haskell, is like starting from a monad, (as you know very well they are almost the same thing as a monad is an applicative with one more rule) and then it's quite clear why we get endless blog posts that leave you no brighter. The second is that we're talking about TypeScript, not JavaScript. Let's make an example. Given a definition for map in TypeScript: map: <A, B>(f: (a: A) => B) => ((fa: F<A>) => F) which requires a minimal typescript understanding (a function from A to B and a value of type F<A> you get F) to read. If you can read map you can read ap in TypeScript: const ap: <A>(fa: F<A>) => (fab: F<(a: A) => B>) => F It's almost the same, with one major difference: you don't have a function from a to b, but one that is lifted in a datatype F, thus F<a => b>.