71–80 of 185 posts
I didn't look too much at this but are they offering an alternative to the (IMO ugly) error checking pattern Go enforces? It's interesting to me shoehorning this into Go in particular. Go is notoriously stringent on how you write code.
They have Either, so kind of. It looks serviceable, if a little messy without language support for safely destructuring its cases.
Earlier quoted context omitted.
Just like FPP is incompatible with C, I agree. And if you want a real taste of FPP go with either Haskell, OCaml or even the good ol' LISP
Or Rust.
Adding generics to go was a mistake
Step 2: Add “Monoids for the Endomorphism where the `concat` operation is the usual function composition.”
Step 3: …
Step 4: Profit?
Earlier quoted context omitted.
I can think of two good reasons: 1. To look clever. 2. To make junior programmers look stupid.
For me, the best reason would be: for the heck of it. But it's IBM's repo. Someone wanted this in some official IBM capacity.
client := H.MakeClient(HTTP.DefaultClient)
readSinglePost := H.ReadJson[PostItem](client)
readSingleCatFact := H.ReadJson[CatFact](client)
data := F.Pipe3(
T.MakeTuple2("https://jsonplaceholder.typicode.com/posts/1", "https://catfact.ninja/fact"),
T.Map2(H.MakeGetRequest, H.MakeGetRequest),
R.TraverseTuple2(
readSinglePost,
readSingleCatFact,
),
R.ChainFirstIOK(IO.Logf[T.Tuple2[PostItem, CatFact]]("Log Result: %v")),
)
result := data(context.Background())
fmt.Println(result())
I’m sorry, but this is just awful. func TraverseTuple10[F1 ~func(A1) IOEither[E, T1], F2 ~func(A2) IOEither[E, T2], F3 ~func(A3) IOEither[E, T3], F4 ~func(A4) IOEither[E, T4], F5 ~func(A5) IOEither[E, T5], F6 ~func(A6) IOEither[E, T6], F7 ~func(A7) IOEither[E, T7], F8 ~func(A8) IOEither[E, T8], F9 ~func(A9) IOEither[E, T9], F10 ~func(A10) IOEither[E, T10], E, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, T1, T2, T3, T4, T…
Also yes it is awful.
1) Go doesn't have a concise lambda expression. This makes the functional approach in Go will be more verbose and less readable than the traditional imperative approach.
2) Go's type inference is not sophisticated enough. Most of the time you will still need to explicitly annotate the types, which, again, makes it more verbose and less readable.
Earlier quoted context omitted.
Or Rust.
As a Rust guy, I disagree. For one, Rust does not have lazy evaluation, just like C which is why I raised the point C is incompatible with FPP. Lazy evaluation in C (and Rust) can be emulated by function pointers (and closures), but it is not easy to use
Does one need lazy evaluation to be FP?
Scheme isn't lazy to my knowledge.