blocks|key|1346885|text|在没有状态的情况下，很容易实现代码的自动并行化(因为CPU的内核越来越多，这一点非常重要)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1346886|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Without state, it is very easy to automatically parallelize your code (as CPUs are made with more and more cores this is very important).

blocks|key|1562523|text|无状态函数的一个优点是它们允许预先计算或缓存函数的返回值。甚至一些C编译器也允许您显式地将函数标记为无状态，以提高它们的可优化性。正如其他许多人所指出的，无状态函数更容易并行化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562524|但效率并不是唯一的关注点。纯函数更容易测试和调试，因为任何影响它的东西都是显式声明的。当用函数式语言编程时，人们养成了让尽可能少的函数“脏”的习惯(通过I/O等)。尽可能的。以这种方式分离出有状态的东西是设计程序的好方法，即使是在非函数式语言中也是如此。|1562525|函数式语言可能需要一段时间才能“理解”，并且很难向没有经历过该过程的人解释。但大多数坚持了足够长时间的人最终意识到，即使他们最终并没有太多地使用函数式语言，这种小题大做也是值得的。|1562526|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

One advantage of stateless functions is that they permit precalculation or caching of the function's return values. Even some C compilers allow you to explicitly mark functions as stateless to improve their optimisability. As many others have noted, stateless functions are much easier to parallelise.

But efficiency is not the only concern. A pure function is easier to test and debug since anything that affects it is explicitly stated. And when programming in a functional language, one gets in the habit of making as few functions "dirty" (with I/O, etc.) as possible. Separating out the stateful stuff this way is a good way to design programs, even in not-so-functional languages.

Functional languages can take a while to "get", and it's difficult to explain to someone who hasn't gone through that process. But most people who persist long enough finally realise that the fuss is worth it, even if they don't end up using functional languages much.

blocks|key|1562589|text|不久前，我写了一篇关于这个话题的文章：On+The+Importance+of+Purity。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1562590|entityMap|0|LINK|mutability|MUTABLE|url|http://higherlogics.blogspot.com/2007/10/on-importance-of-purity.html^0|J|R|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I wrote a post on just this subject awhile back: <a href="http://higherlogics.blogspot.com/2007/10/on-importance-of-purity.html" rel="noreferrer">On The Importance of Purity</a>.

blocks|key|1562660|text|当你开始有更高的流量时，无状态web应用程序是必不可少的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562661|例如，出于安全原因，您可能不希望将大量用户数据存储在客户端。在这种情况下，您需要将其存储在服务器端。您可以使用web应用程序的默认会话，但如果您有多个应用程序实例，则需要确保每个用户始终指向相同的实例。|1562662|负载均衡器通常具有“粘性会话”的能力，其中负载均衡器如何知道将用户请求发送到哪个服务器。但这并不理想，例如，这意味着每次您重新启动web应用程序时，所有连接的用户都将丢失其会话。|1562663|一种更好的方法是将会话存储在web服务器后面的某种数据存储中，现在有很多很棒的nosql产品可用于此(redis、mongo、elasticsearch、memcached)。这样，web服务器是无状态的，但您仍然拥有状态服务器端，并且可以通过选择正确的数据存储设置来管理此状态的可用性。这些数据存储通常具有很大的冗余性，因此几乎总是可以在不影响用户的情况下对web应用程序甚至数据存储进行更改。|1562664|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Stateless web applications are essential when you start having higher traffic.

There could be plenty of user data that you don't want to store on the client side for security reasons for example. In this case you need to store it server-side. You could use the web applications default session but if you have more than one instance of the application you will need to make sure that each user is always directed to the same instance.

Load balancers often have the ability to have 'sticky sessions' where the load balancer some how knows which server to send the users request to. This is not ideal though, for example it means every time you restart your web application, all connected users will lose their session.

A better approach is to store the session behind the web servers in some sort of data store, these days there are loads of great nosql products available for this (redis, mongo, elasticsearch, memcached). This way the web servers are stateless but you still have state server-side and the availability of this state can be managed by choosing the right datastore setup. These data stores usually have great redundancy so it should almost always be possible to make changes to your web application and even the data store without impacting the users.

blocks|key|1562711|text|我的理解是FP对测试也有巨大的影响。没有可变状态通常会迫使您为函数提供比为类提供更多的数据。有一些权衡，但是想一想测试一个"incrementNumberByN“而不是"Counter”类的函数是多么容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562712|对象|1562713|describe("counter",+()+=>+{
++++it("should+increment+the+count+by+one+when+'increment'+invoked+without+
++++argument",+()+=>+{
+++++++const+counter+=+new+Counter(0)
+++++++counter.increment()
+++++++expect(counter.count).toBe(1)
++++})
+++it("should+increment+the+count+by+n+when+'increment'+invoked+with+
++++argument",+()+=>+{
+++++++const+counter+=+new+Counter(0)
+++++++counter.increment(2)
+++++++expect(counter.count).toBe(2)
++++})
})|code-block|syntax|javascript|1562714|功能|1562715|+describe("incrementNumberBy(startingNumber,+increment)",+()+=>+{

+++it("should+increment+by+1+if+n+not+supplied"){
++++++expect(incrementNumberBy(0)).toBe(1)
+++}

+++it("should+increment+by+1+if+n+=+1+supplied"){
++++++expect(countBy(0,+1)).toBe(1)
+++}

+})|1562716|由于函数没有状态，并且进入的数据更加明确，因此当您试图找出测试可能失败的原因时，需要关注的事情会更少。在我们不得不做的柜台测试上|1562717|+++++++const+counter+=+new+Counter(0)
+++++++counter.increment()
+++++++expect(counter.count).toBe(1)|1562718|前两行都对counter.count的值有贡献。在这样一个简单的例子中，1对2行潜在的有问题的代码并不是什么大问题，但当你处理一个更复杂的对象时，你可能也会给你的测试增加大量的复杂性。|offset|length|style|CODE|1562719|相反，当您用函数式语言编写项目时，它会推动您让花哨的算法依赖于进出特定函数的数据，而不是依赖于系统的状态。|1562720|另一种看待它的方式是说明在每个范例中测试系统的心态。|1562721|对于函数式编程:确保函数A适用于给定的输入，您确保函数B适用于给定的输入，确保C适用于给定的输入。|1562722|对于OOP:确保对象A的方法在对对象的状态执行Y和Z操作后，在输入参数X的情况下工作。确保对象B的方法在对对象的状态执行W和Y之后，在给定输入参数X的情况下工作。|1562723|entityMap^0|0|0|0|0|0|0|0|5|D|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|19|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1C|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|1D|8|@$S|1E|T|1F|U|V]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1I|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1J|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|15|$]]

My understanding is that FP also has a huge impact on testing. Not having a mutable state will often force you to supply more data to a function than you would have to for a class. There's tradeoffs, but think about how easy it would be to test a function that is &quot;incrementNumberByN&quot; rather than a &quot;Counter&quot; class.
Object
<pre><code>describe(&quot;counter&quot;, () =&gt; {
 it(&quot;should increment the count by one when 'increment' invoked without 
 argument&quot;, () =&gt; {
 const counter = new Counter(0)
 counter.increment()
 expect(counter.count).toBe(1)
 })
 it(&quot;should increment the count by n when 'increment' invoked with 
 argument&quot;, () =&gt; {
 const counter = new Counter(0)
 counter.increment(2)
 expect(counter.count).toBe(2)
 })
})
</code></pre>
functional
<pre><code> describe(&quot;incrementNumberBy(startingNumber, increment)&quot;, () =&gt; {

 it(&quot;should increment by 1 if n not supplied&quot;){
 expect(incrementNumberBy(0)).toBe(1)
 }

 it(&quot;should increment by 1 if n = 1 supplied&quot;){
 expect(countBy(0, 1)).toBe(1)
 }

 })

</code></pre>
Since the function has no state and the data going in is more explicit, there are fewer things to focus on when you are trying to figure out why a test might be failing. On the tests for the counter we had to do
<pre><code> const counter = new Counter(0)
 counter.increment()
 expect(counter.count).toBe(1)
</code></pre>
Both of the first two lines contribute to the value of <code>counter.count</code>. In a simple example like this 1 vs 2 lines of potentially problematic code isn't a big deal, but when you deal with a more complex object you might be adding a ton of complexity to your testing as well.
In contrast, when you write a project in a functional language, it nudges you towards keeping fancy algorithms dependent on the data flowing in and out of a particular function, rather than being dependent on the state of your system.
Another way of looking at it would be illustrating the mindset for testing a system in each paradigm.
For Functional Programming: Make sure function A works for given inputs, you make sure function B works with given inputs, make sure C works with given inputs.
For OOP: Make sure Object A's method works given an input argument of X after doing Y and Z to the state of the object. Make sure Object B's method works given an input argument of X after doing W and Y to the state of the object.

I've recently been learning about functional programming (specifically Haskell, but I've gone through tutorials on Lisp and Erlang as well). While I found the concepts very enlightening, I still don't see the practical side of the "no side effects" concept. What are the practical advantages of it? I'm trying to think in the functional mindset, but there are some situations that just seem overly complex without the ability to save state in an easy way (I don't consider Haskell's monads 'easy').

Is it worth continuing to learn Haskell (or another purely functional language) in-depth? Is functional or stateless programming actually more productive than procedural? Is it likely that I will continue to use Haskell or another functional language later, or should I learn it only for the understanding?

I care less about performance than productivity. So I'm mainly asking if I will be more productive in a functional language than a procedural/object-oriented/whatever.

Advantages of stateless programming?

Elasticsearch 

负载均衡

数据存储

服务器

编译器

Erlang

我最近一直在学习函数式编程(特别是Haskell，但我也学过关于Lisp和Erlang的教程)。虽然我发现这些概念非常有启发性，但我仍然看不到“无副作用”概念的实际一面。它的实际优势是什么？我试着用函数式思维来思考，但有些情况看起来过于复杂，没有能力以一种简单的方式保存状态(我不认为Haskell的monads“容易”...

问无状态编程的优点？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问无状态编程的优点？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问无状态编程的优点？
EN