在学习函数式编程， Ramda 的一些疑问

突然想起来可以用 copilot ，去充了一个，对学习很有帮助。
贴两个 copilot 写的
```
ifElse(
shouldFill,
compose(prepend, brickSample),
compose(prepend, always(null))
)(row.length)(row),
```
```
prepend(
ifElse(shouldFill, brickSample, always(null))(row.length),
row
),
```

楼主的用法真的是辣眼睛。

关于 JS 函数式编程，前两天我写了个知乎回答，贴过来 https://www.zhihu.com/question/570165038/answer/2784350974

point free 就是要把代码写成文章
如果无法从语义上（也就是函数名）表达代码在做什么那就是没写好，或者说这段代码不适合 point free

关于 Ramda 的写法，它提供了一些函数组合的工具函数，例如 compose 、pipe 等，可以用来把多个函数组合在一起，并且从右往左依次执行。

对于上面的代码，可以把两个部分分别写成两个函数，然后用 compose 组合在一起，代码如下：

const getBrick = compose(
ifElse(identity<boolean>, brickSample, always(nll)),
shouldFill
)

const prependBrick = (map) => (row) => prepend(getBrick(row.length)(row), map)

prependBrick(map)(row)

这样就可以很清晰地看出来，前面的部分是根据 row.length 获取砖块值，后面的部分是 prepend 到地图里。

当然，这个写法并不是必须的，你可以按照自己的喜好写，只要保证代码可读性即可。

@lmshl 看不懂你写的文 同样的功能你能不能改一个 让我看看不辣的函数式 js 是什么样的

不辣的
```Javascript
if (!shouldFill(row.length)) return row

const arr = brickSample()
return prepend(row, arr)
```

// Define named functions for each part of the code.
function shouldFill(length: number) {
// Determine whether the current cell should be filled with a brick.
return length > 0;
}

function brickSample(filled: boolean) {
// If the cell should be filled, return the value of a brick.
// Otherwise, return null.
return filled ? BRICK_VALUE : null;
}

function prependBrick(brick: any, row: any[]) {
// Prepend the given brick to the given row.
return [brick, ...row];
}

// Use the named functions to create a new, composed function.
const fillRow = compose(
prependBrick,
brickSample,
shouldFill
);

// Use the composed function to fill the cells in a row.
const filledRow = fillRow(row.length, row);

开眼了，感觉 Ramda 真的是函数式。但程序变得好神奇。
看了之后，还是坚定的自己的习惯，保持数据不可变，用好 map flatmap filter reduce 就可以好好的函数式编程了。

做了 10 年 JS 全栈开发，表示两段看起来都很难读懂。

一般 JS 开发者的思维都是 foo() 或 foo=() 这种形式，即函数名后紧跟参数表的形式，所以看到 ()()() 这种形式就需要转换思维，先在脑内模拟运行前面的部分才能知道返回了什么函数来使用后面的参数表，在代码特别长的时候，单拎出来中间一部分可能无法确定是在执行什么函数，可能降低了代码阅读理解的效率。工业上来讲，个人认为 a().b().c() 这样链式调用的形式可能更明确。

通常，函数调用和逻辑判断流程有明显的语法格式差异，可以帮助阅读者快速切换这两种语境，但当流程控制也被封装成函数的时候，就需要人去了解函数内部的流程特征，个人认为不如直接在相关代码附近喂给阅读者要方便，在各个函数声明的区域跳来跳去也比较打断思路。

或许题主只想做一个使用 JS 实现的完全函数式编程案例，尽管这不是工业上最普遍的风格；这样的话题主就不要纠结好看不好看了，符合教材范式和核心目标就好吧。