<table class="text">
<tr class="li1"><td class="ln"><pre class="de1">1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39 IoUsly better than the other. Programs are usually shorter and in some cases easier to read Except in the cases where they are longer and harder to read. Learning how to read programs written in a functional style is a difficult skill; people seem to be much better at conceiving of programs as a series of steps to be followed,like a recipe,rather than as a series of calculations to be carried out. Productivity goes up (example: Erlang) Productivity has to go up a lot in order to justify the massive expense of hiring programmers who know how to program in a functional style. And remember,you don't want to throw away a working system; most programmers are not building new systems from scratch,but rather maintaining existing systems,most of which were built in non-functional languages. Imagine trying to justify that to shareholders. Why did you scrap your existing working payroll system to build a new one at the cost of millions of dollars? "Because functional programming is awesome" is unlikely to delight the shareholders. Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21th century Functional programming is very old too. I don't see how the age of the concept is relevant. Don't get me wrong. I love functional programming,I joined this team because I wanted to help bring concepts from functional programming into C#,and I think that programming in an immutable style is the way of the future. But there are enormous costs to programming in a functional style that can't simply be wished away. The shift towards a more functional style is going to happen slowly and gradually over a period of decades. And that's what it will be: a shift towards a more functional style,not a wholesale embracing of the purity and beauty of Haskell and the abandoning of C++. I build compilers for a living and we are definitely embracing a functional style for the next generation of compiler tools. That's because functional programming is fundamentally a good match for the sorts of problems we face. Our problems are all about taking in raw information -- strings and Metadata -- and transforming them into different strings and Metadata. In situations where mutations occur,like someone is typing in the IDE,the problem space inherently lends itself to functional techniques such as incrementally rebuilding only the portions of the tree that changed. Many domains do not have these nice properties that make them obvIoUsly amenable to a functional style.
