2022-08-18
[14:51:49.0706] <TabAtkins>
Hoo boy, I have to say, Kyle's "dynamic-composition-flow" examples look extraordinarily bad to me, as a reader. I assume he's deep enough in pointfree FP stuff that this makes sense to him, but every single function here would be vastly more readable if written as some plain functions that execute statements.

[14:57:46.0542] <TabAtkins>
And dynamic-composition-pipeline is quite bad too - why does he want to pass around an *array* named "getCustomerName"? That's clearly indicating a function, and is *used* as one; keeping it as an array just makes the code less readable.

[16:22:26.0706] <rbuckton>
`getCustomerName` doesn't seem to be an array. isn't it a function that returns an array?

[16:30:36.0612] <rbuckton>
`partial` is basically `Function.bind`, so:

```
getCustomerName := partial(flow, [pick("customerName"), formatName2])
                := flow.bind(null, pick("customerName"), formatName2)
                := arg => formatName2(pick("customerName")(arg))
                := arg => formatName2(arg.customerName)
```

[16:30:40.0844] <rbuckton>
 * `partial` is basically `Function.bind`, so:

```
getCustomerName := partial(flow, [pick("customerName"), formatName2])
                := flow.bind(null, pick("customerName"), formatName2)
                := arg => formatName2(pick("customerName")(arg))
                := arg => formatName2(arg.customerName)
```

[16:45:24.0034] <TabAtkins>
In file #2 it's a function, in the rest of the files it's an array of functions. (This is explicitly called out in comments in each file)


2022-08-19
[17:02:52.0815] <rbuckton>
I think that's the point of the `|> ...` operator? `x |> ...[a, b, c]` is essentially `x |> a(^) |> b(^) |> c(^)`.

[17:03:10.0707] <rbuckton>
It would possibly be better written as `getCustomerNameSteps = [...]`

[17:04:54.0057] <rbuckton>
Also, this would be impossible for a type system like TypeScript to statically type in any meaningful way. You'd have to wait for the `|> ...` to instantiate generics, meaning you have no type inference when composing functions in the array.

[08:27:03.0583] <TabAtkins>
Right, but my point is, carrying around an array of functions instead of just composing them into a single function is odd. If they did that, then it would just be `|> getCustomerName(^^) |>` and be a completely uninteresting example.

[08:28:20.0158] <TabAtkins>
It just so happens that, if you're using `pipe()`, carrying around an array can be somewhat ergonomic since you can then spread the functions into the arglist. But that's an accidental quality of the features and syntaxes involved; it's not *intended* as something that should work.

[08:28:49.0225] <TabAtkins>
But even with pipe(), using a composed function instead of an array is likely better since then you can use it *elsewhere*, rather than just in pipe().

[08:30:26.0630] <TabAtkins>
It just seems odd that this particular behavior is being defended on FP grounds, when it is actually a pretty weird and not particularly FP-ish thing to do. Good FP programming would use actual function composition.