Javascript 的函数式编程是一种反模式 #1842

sunui · 2017-07-03T10:30:23Z

#1815 翻译完成。 @sqrthree

leviding · 2017-07-05T15:37:22Z

校对认领 @sqrthree

linhe0x0 · 2017-07-05T15:37:27Z

@leviding 好的呢 🍺

leviding

先睡了，明早校对剩下的。

leviding · 2017-07-05T16:00:35Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

 > * 校对者：

-# Functional programming in Javascript is an antipattern
+# Javascript 的函数式编程是一种反模式


文中所有的 Javascript 是否有必要统一改写为 JavaScript ？

恩恩有必要

leviding · 2017-07-05T16:01:46Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

@@ -3,95 +3,96 @@
 > * 原文作者：[Alex Dixon](https://hackernoon.com/@alexdixon)
 > * 译文出自：[掘金翻译计划](https://github.com/xitu/gold-miner)
 > * 本文永久链接：[https://github.com/xitu/gold-miner/blob/master/TODO/functional-programming-in-javascript-is-an-antipattern.md](https://github.com/xitu/gold-miner/blob/master/TODO/functional-programming-in-javascript-is-an-antipattern.md)
-> * 译者：
+> * 译者：[sunui](https://github.com/sunui)
 > * 校对者：


校对者：LeviDing

leviding · 2017-07-05T16:12:47Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-> “If it’s Immutable, use <this function> with <this syntax>, otherwise use <a different version of the same function> with <different syntax and totally different behavior>.”
+> “如果它是不可变的，使用 <这种语法> 的 <这个函数>，否则使用 <不同的语法和完全不同行为> 的 <同一个函数的另一个版本>”


【使用 <这种语法> 的 <这个函数>】=> 【要么使用 <这种语法> 的 <这个函数>】

leviding · 2017-07-05T16:16:30Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-Libraries like Redux and React require immutability by convention. So even if I’m not using ImmutableJS, I have to remember “don’t mutate here”. Immutable transformations in Javascript are more difficult than they need to be. I feel like the language is fighting me every step of the way. Compounding that, Javascript doesn’t have basic functions like Object.map. So like more than [43 million of us last month](https://www.npmjs.com/package/lodash), I use lodash, which provides a lot of functions Javascript doesn’t have. Still, the API isn’t immutable-friendly. Some functions return new values, while others mutate the existing ones. Again, keeping things like this straight is unnecessary overhead. So is the fact that presumably, on top of Javascript, I need to know lodash, its function names, its signatures, its return values. And to top it off, its [“collection first, arguments last” approach is not ideal](https://www.youtube.com/watch?v=m3svKOdZijA) for functional programming.
+按照惯例像 Redux 和 React 这种库需要不可变性。所以即使我不使用 ImmutableJS，我也得记得“don’t mutate here”。在 Javascript 中不可变的转换比它本身的使用更难。我感觉这门语言给我前进的道路下了一路坑。此外，JavaScript 没有像 Object.map 这样基本函数。所以像[上个月 4300 多万人](https://www.npmjs.com/package/lodash)一样，我使用 lodash，它提供大量 Javascript 自身没有的函数。不过它的 API 也不是友好支持不可变的。一些函数返回新的数值，而另一些会更改已经存在的数据。再次强调，花时间来区分它们是很不必要的开销。事实大概如此，想要处理 Javascript，我需要了解 lodash、它的函数名称、它的签名、它的返回值。更糟糕的是，它的[“collection 在先， arguments 在后”](https://www.youtube.com/watch?v=m3svKOdZijA)的方式对函数式编程来说也并不理想。


【这样基本函数】=>【这样的基本函数】

leviding · 2017-07-05T16:19:24Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-Libraries like Redux and React require immutability by convention. So even if I’m not using ImmutableJS, I have to remember “don’t mutate here”. Immutable transformations in Javascript are more difficult than they need to be. I feel like the language is fighting me every step of the way. Compounding that, Javascript doesn’t have basic functions like Object.map. So like more than [43 million of us last month](https://www.npmjs.com/package/lodash), I use lodash, which provides a lot of functions Javascript doesn’t have. Still, the API isn’t immutable-friendly. Some functions return new values, while others mutate the existing ones. Again, keeping things like this straight is unnecessary overhead. So is the fact that presumably, on top of Javascript, I need to know lodash, its function names, its signatures, its return values. And to top it off, its [“collection first, arguments last” approach is not ideal](https://www.youtube.com/watch?v=m3svKOdZijA) for functional programming.
+按照惯例像 Redux 和 React 这种库需要不可变性。所以即使我不使用 ImmutableJS，我也得记得“don’t mutate here”。在 Javascript 中不可变的转换比它本身的使用更难。我感觉这门语言给我前进的道路下了一路坑。此外，JavaScript 没有像 Object.map 这样基本函数。所以像[上个月 4300 多万人](https://www.npmjs.com/package/lodash)一样，我使用 lodash，它提供大量 Javascript 自身没有的函数。不过它的 API 也不是友好支持不可变的。一些函数返回新的数值，而另一些会更改已经存在的数据。再次强调，花时间来区分它们是很不必要的开销。事实大概如此，想要处理 Javascript，我需要了解 lodash、它的函数名称、它的签名、它的返回值。更糟糕的是，它的[“collection 在先， arguments 在后”](https://www.youtube.com/watch?v=m3svKOdZijA)的方式对函数式编程来说也并不理想。


【是很不必要的开销】=>【是很不划算的】

leviding · 2017-07-05T16:22:09Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-When I use ImmutableJS in isolation, some things are easier. Map.set returns a brand new value. Everything returns a brand new value! This is what I want. Unfortunately, ImmutableJS complects things too. I inevitably have two different sets of data structures to work with. So I have to know whether `x` is Immutable or Javascript. As a result of learning its API and its overall way of thinking, I can know how to solve a problem in 2 seconds using Immutable. When I’m working in native JS, I have to skip over that solution and solve the problem another way. Like ramda and lodash, I have a larger set of functions I need to know about — what they return, their signatures, their names . I also need to divide all the functions I know about into two categories: ones that work with Immutable, and ones that don’t. This tends to affect the way I solve problems too. I sometimes arrive at a solution automatically that uses curry and compose. But neither work with ImmutableJS. So I skip that solution and think of another.
+当我单独使用 ImmutableJS，一些事变得容易些了。Map.set 返回全新的值。一切都返回全新的值！这就是我想要的。不幸的是，ImmutableJS 也纠结了一些事情。我不可避免地要处理两套不同的数据结构。所以我不得不清楚 `x` 是 Immutable 的还是 Javascript 的。通过学习其 API 和整体思维方式，我可以使用 Immutable 在 2 秒内知道如何解决问题。当我使用原生 JS 时，我必须跳过该解决方案，用另一种方式来解决问题。就像 ramda 和 lodash 一样，有大量的函数需要我了解 —— 它们返回什么、它们的签名、它们的名称。我也需要把我所知的所有函数分成两类：一类用于 Immutable 的，另一类不是。这往往也会影响我解决问题的方式。我有时会不自主地想到柯里化和组合函数的解决方案。但不能和 ImmutableJS 一起使用。所以我跳过这个解决方案，想想其他的。


倒数第二行的【另一类不是】=>【另一类用于其它】

leviding · 2017-07-05T16:32:11Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-If you identify or agree at all with what I’ve said (and if you don’t, that’s fine), then I think it’s worth 5 minutes, a day, or even a week to consider: What might be the long-term costs of staying on the Javascript path versus taking a different one?
+我没有确切的数字，但我敢说如果不必去想“在这里我可以用什么函数？”和“我可否改变这个变量”这样的问题，我可以更有成效。这些问题对我想要解决的问题或者我想要增加的功能没有任何意义。它们是语言本身造成的。我能想到避免这个问题的唯一办法就是在路的起点就不要走下去 —— 不要使用 ImmutableJS 、ImmutableJS 数据结构、Redux/React 概念中的不可变数据，以及 ramda 表达式和 lodash。总之就是写 Javascript 不要使用函数式编程技术，它看似不是什么好的解决方案。


第一行【我可以更有成效】=>【我可以更高效的开发】

leviding

校对完成，请批评指正！

leviding · 2017-07-06T02:53:45Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-The different one, for me, is called Clojurescript. It’s a “compile-to-JS” language like ES6. By and large, it’s Javascript in a different syntax. It was designed from the ground up as a functional programming language that operates on immutable data structures. To me, it’s way easier and more promising than Javascript.
+如果你确定并同意我所说的（如果不同意，也很好），那么我认为值得花 5 分钟或一天甚至一周时间来考虑：保持在 Javascript 路子上相比用一个不同的东西取代，耗费的长期成本是什么？


【如果你确定并同意我所说的（如果不同意，也很好），那么我认为值得花 5 分钟或一天甚至一周时间来考虑：保持在 Javascript 路子上相比用一个不同的东西取代，耗费的长期成本是什么？】
=>
【我认为花 5 分钟或一天甚至一周的时间考虑“继续使用 Javascript 进行开发相比用其他的东西来取代，长期来说耗费多少成本？”等问题是很值得的。不知你能否认可并同意我所说的（如果不同意，也没什么）。】

这里为什么要调换语序？

就是更符合国人习惯一些。不改的话，也可以吧。

leviding · 2017-07-06T03:01:56Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-Like Javascript, Clojure and Clojurescript are dynamically typed. You can write full stack apps in 100 percent Clojurescript using Node for your server. Unlike with a language that compiles to Javascript alone, you have the option of writing a Java-based server that supports multithreading.
+和 Javascript 一样，Clojure 和 Clojurescript 也是动态类型的。你可以 100% 地使用 Clojurescript 语言用写服务端的 Node 来写全栈应用。与单独编译成 Javascript 的语言不同，你也可以选择写一个基于 Java 的 servrer 来支持多线程。


【你可以 100% 地使用 Clojurescript 语言用写服务端的 Node 来写全栈应用。】=>【你可以 100% 使用 Clojurescript 语言和用来写服务端的 Node 语言来写全栈应用。】

这里 Node 是运行环境不是语言

那【用写服务端的 Node 来写全栈应用】这句话怎么梳理好呢，感觉就是不通顺，读不懂。

现在译者改的「你可以 100% 地使用 Clojurescript 语言用 Node 写服务端的全栈应用」感觉已经不错了，能理解就好

leviding · 2017-07-06T03:03:24Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-### What makes Clojurescript easier?
+### 是什么让 Clojurescript 更简单？


【是什么让 Clojurescript 更简单？】=>【是什么使得 Clojurescript 更简单？】

leviding · 2017-07-06T03:06:39Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

+在编辑器中执行任意你想要执行的代码。
+1. **你可以在编辑器中一键执行任何代码。** 的确如此，你可以在编辑器中输入任何你想写的代码，选中它（或者把光标放在上面）然后运行并查看结果。你可以定义函数，然后用你想用的参数调用它。你可以在应用运行的时候做这些事。所以，如果你不知道一些东西如何运作，你可以在你的编辑器的 REPL 里求值，看看会发生什么。
+2. **函数可以作用于数组和对象。** Map、reduce、filter 等对数组和对象的作用都相同。设计就是如此。我们毋须再纠结于 `map` 对数组和对象作用的不同之处。
+3. **不可变的数据结构。** 所有 Clojurescript 数据结构都是不可变的。因此你再也不比纠结一些东西是否可变了。你也不需要切换编程范式，从可变到不可变。不完全在不可变的领地上。


这是笔误吧
【因此你再也不比纠结一些东西是否可变了。】=>【因此你再也不用纠结一些东西是否可变了。】

leviding · 2017-07-06T03:11:03Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

+在编辑器中执行任意你想要执行的代码。
+1. **你可以在编辑器中一键执行任何代码。** 的确如此，你可以在编辑器中输入任何你想写的代码，选中它（或者把光标放在上面）然后运行并查看结果。你可以定义函数，然后用你想用的参数调用它。你可以在应用运行的时候做这些事。所以，如果你不知道一些东西如何运作，你可以在你的编辑器的 REPL 里求值，看看会发生什么。
+2. **函数可以作用于数组和对象。** Map、reduce、filter 等对数组和对象的作用都相同。设计就是如此。我们毋须再纠结于 `map` 对数组和对象作用的不同之处。
+3. **不可变的数据结构。** 所有 Clojurescript 数据结构都是不可变的。因此你再也不比纠结一些东西是否可变了。你也不需要切换编程范式，从可变到不可变。不完全在不可变的领地上。


【不完全在不可变的领地上。】=>【你完全在不可变的数据结构的领地上。】

leviding · 2017-07-06T03:15:38Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

@@ -101,32 +102,33 @@ Run whatever code you want inside your editor.
 => 2
 (macroexpand '(infix (1 + 1)))
 => (+ 1 1)
-; The macro passes this to Clojure. Clojure evaluates it no problem because it's native Clojure syntax
+; 这个宏把它传入 Clojure，Clojure 可以正确执行，因为是 Clojure 的原生语法


本句句尾少个句号。

leviding · 2017-07-06T03:19:06Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-**Lack of job opportunities?** Clojure compiles to Javascript and Java. It can actually compile to C#, too. So any Javascript job could be a Clojurescript job. Or a Java or C# job. It’s a functional language for getting stuff done for any or all of those compile targets. And for whatever it’s worth, the 2017 StackOverflow survey found [Clojure developers are the highest paid of all languages on average worldwide](http://www.techrepublic.com/article/what-are-the-highest-paid-jobs-in-programming-the-top-earning-languages-in-2017/).
+**因为缺少工作机会吗？** Clojure 可以编译成 Javascript 和 Java。它实际上也可以编译成 C#。因此大量的 Javascript 工作都可以当作 Clojurescript 工作。它是一种函数式语言，用于为所有编译目标完成所有的工作。先不论它的价值如何体现，2017 StackOverflow 的调查表明 [Clojure 开发者的薪资水平是所有语言中全球平均最高的](http://www.techrepublic.com/article/what-are-the-highest-paid-jobs-in-programming-the-top-earning-languages-in-2017/)。


【它是一种函数式语言，用于为所有编译目标完成所有的工作。】=>【它是一种用于为任何这些编译目标完成任务的函数式编程语言。】

leviding · 2017-07-06T03:24:29Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-**Lack of familiar frameworks and tooling?** That perception may exist, but there are Clojurescript equivalents to everything in Javascript: [re-frame](https://github.com/Day8/re-frame) is Redux, [reagent](https://github.com/reagent-project/reagent) is React, [figwheel](https://github.com/bhauman/lein-figwheel) is Webpack/hot reloading, [leiningen](https://github.com/technomancy/leiningen) is yarn/npm, Clojurescript is Underscore/Lodash.
+**因为缺乏熟悉的框架和工具吗？** 这感知上可能是个原因，但 Clojurescript 有 Javascript 中等价的一切： [re-frame](https://github.com/Day8/re-frame) 对应 Redux、[reagent](https://github.com/reagent-project/reagent) 对应 React、[figwheel](https://github.com/bhauman/lein-figwheel) 对应 Webpack/热加载、[leiningen](https://github.com/technomancy/leiningen) 对应 yarn/npm、Clojurescript 对应 Underscore/Lodash。


【因为缺乏熟悉的框架和工具吗？ 这感知上可能是个原因，但 Clojurescript 有 Javascript 中等价的一切：】
=>
【因为缺乏熟悉的框架和工具吗？ 感觉上这可能是原因之一，但 Javascript 中有的东西， Clojurescript 都有与之对应的：】

leviding · 2017-07-06T03:25:06Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-**Too difficult to write because parentheses? **This might not talked about enough either, but [we don’t have to match parenthesis and brackets](https://shaunlebron.github.io/parinfer/) ourselves. Parinfer makes Clojure a whitespace language, basically.
+**因为括号的问题太难写吗？** 这方面也许谈的还不够多，但[我们不必自己来区分圆括号方括号](https://shaunlebron.github.io/parinfer/) 。基本上，Parinfer 使得 Clojure 成为了空格语言。


【因为括号的问题太难写吗？】=>【因为括号太难写了吗？】

难写的不是括号呀是因为有括号的问题使得这门语言比较难写

嗯嗯，改成 => 是因为有括号的问题使得这门语言太难写了吗？

是否比现在好点呢，说得明白，就是啰嗦点。

leviding · 2017-07-06T03:26:40Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-**Not popular enough?** Unfortunately, I think this is what it comes down to. I got into Javascript in part because it has a huge community. Clojurescript is smaller. I started using React in part because it was backed by Facebook. Clojure is backed by [a guy with big hair who spends a lot of time thinking](https://avatars2.githubusercontent.com/u/34045?v=3&amp;s=400).
+**没有足够受欢迎？** 很不幸，我想这就是它的原因。我使用 Javascript 一部分原因就是因为它拥有庞大的社区。Clojurescript 太小众了。我使用 React 的部分原因是它是由 Facebook 维护的。而 Clojure 的维护者是[花大量时间思考的留着长发的家伙](https://avatars2.githubusercontent.com/u/34045?v=3&amp;s=400)。


语法不当：原因是因为
【我使用 Javascript 一部分原因就是因为它拥有庞大的社区。】=>【我使用 Javascript 的一部分原因就是它拥有庞大的社区。】

leviding · 2017-07-06T03:28:35Z

校对完成 @sqrthree @sunui

iFwu · 2017-07-06T13:19:09Z

@sqrthree 申请认领校对

linhe0x0 · 2017-07-06T13:19:21Z

@xekri 妥妥哒 🍻

sunui · 2017-07-09T16:24:32Z

@xekri 别忘了来校对啦

iFwu

@sunui @sqrthree 校对完成

iFwu · 2017-07-10T01:53:21Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

- mutable programming techniques when working with Javascript data structures
- immutable programming techniques for Immutable data structures
- immutable programming with mutable Javascript data structures when working with Redux or React
+- lodash 的 API、Immutable 的 API、lodash/fp 的 API、ramda 的 API、还有原生 JS 的 API 或一些组合的 API


这边可以做一下「合并同类项」，比如「lodash、Immutable、lodash/fp、ramda 等库的 API……」

这样说是有意的主要是想强调要知道的东西比较多 😆

iFwu · 2017-07-10T01:57:49Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-Libraries like Redux and React require immutability by convention. So even if I’m not using ImmutableJS, I have to remember “don’t mutate here”. Immutable transformations in Javascript are more difficult than they need to be. I feel like the language is fighting me every step of the way. Compounding that, Javascript doesn’t have basic functions like Object.map. So like more than [43 million of us last month](https://www.npmjs.com/package/lodash), I use lodash, which provides a lot of functions Javascript doesn’t have. Still, the API isn’t immutable-friendly. Some functions return new values, while others mutate the existing ones. Again, keeping things like this straight is unnecessary overhead. So is the fact that presumably, on top of Javascript, I need to know lodash, its function names, its signatures, its return values. And to top it off, its [“collection first, arguments last” approach is not ideal](https://www.youtube.com/watch?v=m3svKOdZijA) for functional programming.
+按照惯例像 Redux 和 React 这种库需要不可变性。所以即使我不使用 ImmutableJS，我也得记得“don’t mutate here”。在 JavaScript 中不可变的转换比它本身的使用更难。我感觉这门语言给我前进的道路下了一路坑。此外，JavaScript 没有像 Object.map 这样的基本函数。所以像[上个月 4300 多万人](https://www.npmjs.com/package/lodash)一样，我使用 lodash，它提供大量 JavaScript 自身没有的函数。不过它的 API 也不是友好支持不可变的。一些函数返回新的数值，而另一些会更改已经存在的数据。再次强调，花时间来区分它们是很不划算的。事实大概如此，想要处理 JavaScript，我需要了解 lodash、它的函数名称、它的签名、它的返回值。更糟糕的是，它的[“collection 在先， arguments 在后”](https://www.youtube.com/watch?v=m3svKOdZijA)的方式对函数式编程来说也并不理想。


“don’t mutate here” 是否可以考虑翻译一下，因为不是什么难译的技术名词，比如「这个地方不能改变」

iFwu · 2017-07-10T02:38:00Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-If I use ramda or lodash/fp, that helps. It’s easy to compose functions and write clear and concise code. But I can’t use it with Immutable data structures. I will also probably have some code where the collection argument is last, and other times it’s the opposite. I have to know more function names, signatures, return values, and import more basic functions.
+如果我使用 ramda 或者 lodash/fp 会好一些，可以很容易地组合函数并且写出清晰整洁的代码。但是它不能和 Immutable 数据结构一起使用。我可能还是要写一些参数集合在后而其他在前的代码。我必须知道更多的函数名、签名、返回值，并引入更多的基本函数。


「我可能还是要写一些参数集合在后而其他在前的代码」，少表达了「and other times」的意思

iFwu · 2017-07-10T03:23:30Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-When I use ImmutableJS in isolation, some things are easier. Map.set returns a brand new value. Everything returns a brand new value! This is what I want. Unfortunately, ImmutableJS complects things too. I inevitably have two different sets of data structures to work with. So I have to know whether `x` is Immutable or Javascript. As a result of learning its API and its overall way of thinking, I can know how to solve a problem in 2 seconds using Immutable. When I’m working in native JS, I have to skip over that solution and solve the problem another way. Like ramda and lodash, I have a larger set of functions I need to know about — what they return, their signatures, their names . I also need to divide all the functions I know about into two categories: ones that work with Immutable, and ones that don’t. This tends to affect the way I solve problems too. I sometimes arrive at a solution automatically that uses curry and compose. But neither work with ImmutableJS. So I skip that solution and think of another.
+当我单独使用 ImmutableJS，一些事变得容易些了。Map.set 返回全新的值。一切都返回全新的值！这就是我想要的。不幸的是，ImmutableJS 也纠结了一些事情。我不可避免地要处理两套不同的数据结构。所以我不得不清楚 `x` 是 Immutable 的还是 JavaScript 的。通过学习其 API 和整体思维方式，我可以使用 Immutable 在 2 秒内知道如何解决问题。当我使用原生 JS 时，我必须跳过该解决方案，用另一种方式来解决问题。就像 ramda 和 lodash 一样，有大量的函数需要我了解 —— 它们返回什么、它们的签名、它们的名称。我也需要把我所知的所有函数分成两类：一类用于 Immutable 的，另一类用于其它。这往往也会影响我解决问题的方式。我有时会不自主地想到柯里化和组合函数的解决方案。但不能和 ImmutableJS 一起使用。所以我跳过这个解决方案，想想其他的。


「ImmutableJS 也纠结了一些事情」=>「也有一些纠结的事情」，可能更通顺

iFwu · 2017-07-10T03:26:10Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


 ![](https://cdn-images-1.medium.com/max/1600/1*MVU4TWwrkRMpQlmgkU9TuQ.png)

-`Visualization of an antipattern.
-I’m going out on a limb and calling functional programming in Javascript an antipattern. It’s an attractive path that gives way to a maze. It seems to solve some problems but ends up creating more. More importantly, those problems appear to have no higher-level solution that can prevent me from having to deal with them over and over again.
+`反模式的可视化。


原文可能是有笔误，这边不应该加上重音符号`

iFwu · 2017-07-10T03:31:32Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

-The different one, for me, is called Clojurescript. It’s a “compile-to-JS” language like ES6. By and large, it’s Javascript in a different syntax. It was designed from the ground up as a functional programming language that operates on immutable data structures. To me, it’s way easier and more promising than Javascript.
+如果你确定并同意我所说的（如果不同意，也很好），那么我认为值得花 5 分钟或一天甚至一周时间来考虑：保持在 JavaScript 路子上相比用一个不同的东西取代，耗费的长期成本是什么？
+
+这个所谓不同的东西对于我来说就是 Clojurescript。它是一门像 ES6 一样的 “compile-to-JS” 语言。一般而论，它是一种使用不同语法的 JavaScript。它的底层是被设计成用于函数式编程的语言，操作不可变的数据结构。对我来说，它比 JavaScript 更容易，更有前途。


「By and large」可能翻译成「大体上」更好

iFwu · 2017-07-10T03:35:00Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

+2. **函数可以作用于数组和对象。** Map、reduce、filter 等对数组和对象的作用都相同。设计就是如此。我们毋须再纠结于 `map` 对数组和对象作用的不同之处。
+3. **不可变的数据结构。** 所有 Clojurescript 数据结构都是不可变的。因此你再也不必纠结一些东西是否可变了。你也不需要切换编程范式，从可变到不可变。你完全在不可变数据结构的领地上。
+4. **一些基本函数是语言本身包含的。** 像 map、filter、reduce、compose 和[很多其他](https://clojure.github.io/clojure/)函数都是核心语言的一部分，不需要外界引入。因此你的脑子里不必记着 4 种不同版本的“map”了（Array.map、lodash.map、ramda.map、Immutable.map）。你只需要知道一个。
+5. **它很简洁。** 相对于其他任何编程语言，它只需要短短几行的代码就能表达你的想法。（通常较少）


「通常较少」=>「通常少得多」

iFwu · 2017-07-10T03:36:28Z

TODO/functional-programming-in-javascript-is-an-antipattern.md

+5. **它很简洁。** 相对于其他任何编程语言，它只需要短短几行的代码就能表达你的想法。（通常较少）
+6. **函数式编程。** Clojurescript 是一门彻底的函数式编程语言 —— 支持隐式返回声明、函数是一等公民、lambda 表达式等等。
+7. **使用 JavaScript 中所需的任何内容。** 你可以使用 JavaScript 的一切以及它的生态系统，从 `console.log` 到 npm 库都可以。
+8. **性能。** Clojurescript 使用 Google Closure 编译器来优化输出的 JavaScript。Bundle 体积小到极致。用于生产的打包过程不需要从设置优化到 `:advanced` 的复杂配置。


「apart from」是「除了」的意思，也就是用于生产时除了设置成:advanced不需要别的配置

iFwu · 2017-07-10T03:43:39Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-There’s safety in numbers. I buy that. But “popularity as veto” discards every other possible factor.
+有数量上的劣势，我认了。但“全民投票”否决了所有其他可能的因素。


「There’s safety in numbers」是人多势众的意思。

iFwu · 2017-07-10T03:46:07Z

TODO/functional-programming-in-javascript-is-an-antipattern.md


-Well, maybe so! There’s a track record of success. It must be safer than the other way, because more people have chosen it. Nothing awful must have happened to them. The other way does sound better, but I’m sure it’s just a trap. If it was what it seemed, it would be the most popular.
+恩，也许会的吧！那里有成功的先例。它一定比另一条路安全，因为更多的人选择了它。他们一定不会遇到什么可怕的事。而另一条路听起来美好，但我确定那一定是个陷阱。
+如果它像看起来那么美好，那么它就是最受欢迎的那条了。


不理解「那条」的意思，我觉得应该就是指语言本身而不是理由。
另外换行好像多了。

是指文章中提到的两条路

iFwu · 2017-07-10T10:21:19Z

好吧，那没什么大碍。其他地方翻译的都不错 On 2017年7月10日 at 下午6:17:32, sun (notifications@github.com<mailto:notifications@github.com>) wrote: @sunui commented on this pull request.

________________________________ In TODO/functional-programming-in-javascript-is-an-antipattern.md<#1842 (comment)>:

-- APIs for lodash, Immutable, lodash/fp, ramda, and native JS or some combination -- mutable programming techniques when working with Javascript data structures -- immutable programming techniques for Immutable data structures -- immutable programming with mutable Javascript data structures when working with Redux or React +- lodash 的 API、Immutable 的 API、lodash/fp 的 API、ramda 的 API、还有原生 JS 的 API 或一些组合的 API 这样说是有意的主要是想强调要知道的东西比较多 😆 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1842 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APwiWDPGT2S6REYXRfU9kBbMUB53XGSrks5sMfo8gaJpZM4OMHFi>.

sunui · 2017-07-11T02:00:15Z

@sqrthree 修改完成了

linhe0x0 · 2017-07-11T03:20:52Z

已经 merge 啦~ 快快麻溜发布到掘金专栏然后给我发下链接，方便及时添加积分哟。

sunui added 3 commits June 28, 2017 18:27

functional-programming-in-javascript-is-an-antipattern.md

15be9f3

翻译

4a16b18

翻译初稿完成

8e3e776

linhe0x0 added the 校对认领 label Jul 3, 2017

linhe0x0 mentioned this pull request Jul 3, 2017

Javascript 的函数式编程是一种反模式 #1815

Closed

修正一点瑕疵

ce813d3

linhe0x0 added the 前端 label Jul 3, 2017

linhe0x0 added the 正在校对 label Jul 5, 2017

leviding reviewed Jul 5, 2017

View reviewed changes

leviding reviewed Jul 6, 2017

View reviewed changes

linhe0x0 removed the 校对认领 label Jul 6, 2017

根据一校意见修改

3e71ac8

iFwu suggested changes Jul 10, 2017

View reviewed changes

根据二校意见修改

b6d5399

linhe0x0 approved these changes Jul 11, 2017

View reviewed changes

linhe0x0 merged commit df2eb46 into xitu:master Jul 11, 2017

linhe0x0 added 翻译完成 and removed 正在校对 labels Jul 11, 2017

sunui deleted the translate branch July 11, 2017 04:57


		> “If it’s Immutable, use <this function> with <this syntax>, otherwise use <a different version of the same function> with <different syntax and totally different behavior>.”
		> “如果它是不可变的，使用 <这种语法> 的 <这个函数>，否则使用 <不同的语法和完全不同行为> 的 <同一个函数的另一个版本>”


		Libraries like Redux and React require immutability by convention. So even if I’m not using ImmutableJS, I have to remember “don’t mutate here”. Immutable transformations in Javascript are more difficult than they need to be. I feel like the language is fighting me every step of the way. Compounding that, Javascript doesn’t have basic functions like Object.map. So like more than [43 million of us last month](https://www.npmjs.com/package/lodash), I use lodash, which provides a lot of functions Javascript doesn’t have. Still, the API isn’t immutable-friendly. Some functions return new values, while others mutate the existing ones. Again, keeping things like this straight is unnecessary overhead. So is the fact that presumably, on top of Javascript, I need to know lodash, its function names, its signatures, its return values. And to top it off, its [“collection first, arguments last” approach is not ideal](https://www.youtube.com/watch?v=m3svKOdZijA) for functional programming.
		按照惯例像 Redux 和 React 这种库需要不可变性。所以即使我不使用 ImmutableJS，我也得记得“don’t mutate here”。在 Javascript 中不可变的转换比它本身的使用更难。我感觉这门语言给我前进的道路下了一路坑。此外，JavaScript 没有像 Object.map 这样基本函数。所以像[上个月 4300 多万人](https://www.npmjs.com/package/lodash)一样，我使用 lodash，它提供大量 Javascript 自身没有的函数。不过它的 API 也不是友好支持不可变的。一些函数返回新的数值，而另一些会更改已经存在的数据。再次强调，花时间来区分它们是很不必要的开销。事实大概如此，想要处理 Javascript，我需要了解 lodash、它的函数名称、它的签名、它的返回值。更糟糕的是，它的[“collection 在先， arguments 在后”](https://www.youtube.com/watch?v=m3svKOdZijA)的方式对函数式编程来说也并不理想。


		When I use ImmutableJS in isolation, some things are easier. Map.set returns a brand new value. Everything returns a brand new value! This is what I want. Unfortunately, ImmutableJS complects things too. I inevitably have two different sets of data structures to work with. So I have to know whether `x` is Immutable or Javascript. As a result of learning its API and its overall way of thinking, I can know how to solve a problem in 2 seconds using Immutable. When I’m working in native JS, I have to skip over that solution and solve the problem another way. Like ramda and lodash, I have a larger set of functions I need to know about — what they return, their signatures, their names . I also need to divide all the functions I know about into two categories: ones that work with Immutable, and ones that don’t. This tends to affect the way I solve problems too. I sometimes arrive at a solution automatically that uses curry and compose. But neither work with ImmutableJS. So I skip that solution and think of another.
		当我单独使用 ImmutableJS，一些事变得容易些了。Map.set 返回全新的值。一切都返回全新的值！这就是我想要的。不幸的是，ImmutableJS 也纠结了一些事情。我不可避免地要处理两套不同的数据结构。所以我不得不清楚 `x` 是 Immutable 的还是 Javascript 的。通过学习其 API 和整体思维方式，我可以使用 Immutable 在 2 秒内知道如何解决问题。当我使用原生 JS 时，我必须跳过该解决方案，用另一种方式来解决问题。就像 ramda 和 lodash 一样，有大量的函数需要我了解 —— 它们返回什么、它们的签名、它们的名称。我也需要把我所知的所有函数分成两类：一类用于 Immutable 的，另一类不是。这往往也会影响我解决问题的方式。我有时会不自主地想到柯里化和组合函数的解决方案。但不能和 ImmutableJS 一起使用。所以我跳过这个解决方案，想想其他的。


		If you identify or agree at all with what I’ve said (and if you don’t, that’s fine), then I think it’s worth 5 minutes, a day, or even a week to consider: What might be the long-term costs of staying on the Javascript path versus taking a different one?
		我没有确切的数字，但我敢说如果不必去想“在这里我可以用什么函数？”和“我可否改变这个变量”这样的问题，我可以更有成效。这些问题对我想要解决的问题或者我想要增加的功能没有任何意义。它们是语言本身造成的。我能想到避免这个问题的唯一办法就是在路的起点就不要走下去 —— 不要使用 ImmutableJS 、ImmutableJS 数据结构、Redux/React 概念中的不可变数据，以及 ramda 表达式和 lodash。总之就是写 Javascript 不要使用函数式编程技术，它看似不是什么好的解决方案。


		The different one, for me, is called Clojurescript. It’s a “compile-to-JS” language like ES6. By and large, it’s Javascript in a different syntax. It was designed from the ground up as a functional programming language that operates on immutable data structures. To me, it’s way easier and more promising than Javascript.
		如果你确定并同意我所说的（如果不同意，也很好），那么我认为值得花 5 分钟或一天甚至一周时间来考虑：保持在 Javascript 路子上相比用一个不同的东西取代，耗费的长期成本是什么？


		Like Javascript, Clojure and Clojurescript are dynamically typed. You can write full stack apps in 100 percent Clojurescript using Node for your server. Unlike with a language that compiles to Javascript alone, you have the option of writing a Java-based server that supports multithreading.
		和 Javascript 一样，Clojure 和 Clojurescript 也是动态类型的。你可以 100% 地使用 Clojurescript 语言用写服务端的 Node 来写全栈应用。与单独编译成 Javascript 的语言不同，你也可以选择写一个基于 Java 的 servrer 来支持多线程。


		### What makes Clojurescript easier?
		### 是什么让 Clojurescript 更简单？


		Lack of job opportunities? Clojure compiles to Javascript and Java. It can actually compile to C#, too. So any Javascript job could be a Clojurescript job. Or a Java or C# job. It’s a functional language for getting stuff done for any or all of those compile targets. And for whatever it’s worth, the 2017 StackOverflow survey found [Clojure developers are the highest paid of all languages on average worldwide](http://www.techrepublic.com/article/what-are-the-highest-paid-jobs-in-programming-the-top-earning-languages-in-2017/).
		因为缺少工作机会吗？ Clojure 可以编译成 Javascript 和 Java。它实际上也可以编译成 C#。因此大量的 Javascript 工作都可以当作 Clojurescript 工作。它是一种函数式语言，用于为所有编译目标完成所有的工作。先不论它的价值如何体现，2017 StackOverflow 的调查表明 [Clojure 开发者的薪资水平是所有语言中全球平均最高的](http://www.techrepublic.com/article/what-are-the-highest-paid-jobs-in-programming-the-top-earning-languages-in-2017/)。


		Lack of familiar frameworks and tooling? That perception may exist, but there are Clojurescript equivalents to everything in Javascript: [re-frame](https://github.com/Day8/re-frame) is Redux, [reagent](https://github.com/reagent-project/reagent) is React, [figwheel](https://github.com/bhauman/lein-figwheel) is Webpack/hot reloading, [leiningen](https://github.com/technomancy/leiningen) is yarn/npm, Clojurescript is Underscore/Lodash.
		因为缺乏熟悉的框架和工具吗？这感知上可能是个原因，但 Clojurescript 有 Javascript 中等价的一切： [re-frame](https://github.com/Day8/re-frame) 对应 Redux、[reagent](https://github.com/reagent-project/reagent) 对应 React、[figwheel](https://github.com/bhauman/lein-figwheel) 对应 Webpack/热加载、[leiningen](https://github.com/technomancy/leiningen) 对应 yarn/npm、Clojurescript 对应 Underscore/Lodash。


		Too difficult to write because parentheses? This might not talked about enough either, but [we don’t have to match parenthesis and brackets](https://shaunlebron.github.io/parinfer/) ourselves. Parinfer makes Clojure a whitespace language, basically.
		因为括号的问题太难写吗？这方面也许谈的还不够多，但[我们不必自己来区分圆括号方括号](https://shaunlebron.github.io/parinfer/) 。基本上，Parinfer 使得 Clojure 成为了空格语言。


		Not popular enough? Unfortunately, I think this is what it comes down to. I got into Javascript in part because it has a huge community. Clojurescript is smaller. I started using React in part because it was backed by Facebook. Clojure is backed by [a guy with big hair who spends a lot of time thinking](https://avatars2.githubusercontent.com/u/34045?v=3&s=400).
		没有足够受欢迎？很不幸，我想这就是它的原因。我使用 Javascript 一部分原因就是因为它拥有庞大的社区。Clojurescript 太小众了。我使用 React 的部分原因是它是由 Facebook 维护的。而 Clojure 的维护者是[花大量时间思考的留着长发的家伙](https://avatars2.githubusercontent.com/u/34045?v=3&s=400)。


		If I use ramda or lodash/fp, that helps. It’s easy to compose functions and write clear and concise code. But I can’t use it with Immutable data structures. I will also probably have some code where the collection argument is last, and other times it’s the opposite. I have to know more function names, signatures, return values, and import more basic functions.
		如果我使用 ramda 或者 lodash/fp 会好一些，可以很容易地组合函数并且写出清晰整洁的代码。但是它不能和 Immutable 数据结构一起使用。我可能还是要写一些参数集合在后而其他在前的代码。我必须知道更多的函数名、签名、返回值，并引入更多的基本函数。


		There’s safety in numbers. I buy that. But “popularity as veto” discards every other possible factor.
		有数量上的劣势，我认了。但“全民投票”否决了所有其他可能的因素。

Javascript 的函数式编程是一种反模式 #1842

Javascript 的函数式编程是一种反模式 #1842

Conversation

sunui commented Jul 3, 2017

leviding commented Jul 5, 2017 • edited Loading

linhe0x0 commented Jul 5, 2017

leviding left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leviding left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leviding commented Jul 6, 2017 • edited Loading

iFwu commented Jul 6, 2017

linhe0x0 commented Jul 6, 2017

sunui commented Jul 9, 2017

iFwu left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iFwu commented Jul 10, 2017 via email

sunui commented Jul 11, 2017

linhe0x0 commented Jul 11, 2017

leviding commented Jul 5, 2017 •

edited

Loading

leviding commented Jul 6, 2017 •

edited

Loading

iFwu left a comment •

edited

Loading