函数式编程？别费力气了，它就是个愚蠢的玩具

Functional Programming? Don’t Even Bother, It’s a Silly Toy

函数式编程？别费力气了，它就是个愚蠢的玩具

---

提示：本博文可能不再更新
请移步我的公众号：跃寒或个人主页

Jul 29

原文

It will make your productivity plummet
它会使得你的生产力直线下降

---

Perhaps you’ve heard of so-called “functional” programming. Maybe you’ve even been wondering whether you should try it next.

也许你已经听说过所谓的函数式编程。可能你已经想接下来你是否应该尝试一下

The short answer is hell no!

简短的回答是不

Functional programming is full of flaws, is not suitable for real-world projects, and will make your productivity plummet. Why? Keep reading to find out!

函数式编程充满了缺陷，它不适合真实环境中的项目，也会使得你的生产力直线下降。why? 继续读下去，你会找到答案的

---

Functional Programming is Unable to Fulfill Complex Enterprise Requirements

函数式编程不能满足复杂的企业需求

Real-world enterprise software demands a complex set of rigorous and compulsory requirements pertaining to the expected amount of embedded abstractions within the software solution.
真实环境的企业软件需要一套复杂的严格和强制的要求，这与软件解决方案中的预期嵌入式抽象数量有关
In other words, object-oriented programming enables the programmer to utilize multiple mechanisms of abstraction that fully satisfy the complex requirements demanded by the enterprise.
换句话说，面向对象编程能够使得程序员利用多种抽象方案来完全满足企业所要求的复杂需求

That was a mouthful, but bear with me! Things will become crystal-clear in a moment.

这有些拗口，请容忍我！事情马上会清明如水。

So-called “functional” programming has no proper mechanism of abstraction since it is based on mathematics (which obviously is inferior and has no applications in the real world apart from academia). Unlike OOP, functional programming makes no attempt to fulfill the numerous rigorous and complex requirements demanded by the enterprise.

所谓的函数式编程没有合适的抽象机制，因为它基于数学（显然是低级的，除了学术之外没有任何现实中的应用）。与面向对象编程不同，函数式编程不会尝试满足企业所要求的大量的严格且复杂的需求。

This code snippet to demonstrates the issues prevalent with functional programming:

这个代码片段说明了函数式编程中普遍存在的问题：

  import { filter, first, get } from 'lodash/fp';
    ​
    const filterByType = type =>
      filter( x => x.type === type );
    ​
    const fruits = [
      { type: 'apple', price: 1.99 },
      { type: 'orange', price: 2.99 },
      { type: 'grape', price: 44.95 }  
    ];
    ​
    const getFruitPrice = type => fruits =>
      fruits
      |> filterByType(type)
      |> first
      |> get('price');
    ​
    const getApplePrice = getFruitPrice('apple');
    ​
    console.log('apple price', getApplePrice(fruits));
    If this makes you angry, you’are not alone!

如果它让你很烦，你并不是唯一有此感觉的人

Functional programming makes no attempt to properly abstract and encapsulate the functionality, as typically is demanded by any serious enterprise.
函数式编程不会企图合适地抽象和封装函数，这通常是任何严肃的企业所要求的。

No self-respecting software engineer would ever write anything like this! If they do, then immediately they should be fired by any seriously large enterprise to prevent further damage. In the next section, we’ll take a look at a properly abstracted OOP program.

任何有自尊心的软件工程师都不会如此写代码！否则，他们会立即被任何大公司解雇以避免更深层次的灾难。下个小节，我们将看到合适的抽象面向对象编程

---

Functional Software Solutions Aren’t Future-Proof

函数式软件解决方案不会不过时

It’s no secret that the foremost duty of any professional and self-respecting software engineer is to write future-proof code that satisfies complex business requirements.
众所周知，任何专业且有自尊的软件工程师的首要义务是写不会过时的满足复杂业务需求的代码

In contrast with the disastrous functional code snippet above, let’s take a quick look at a properly abstracted OOP program. It does the same thing, but in an abstract and a future-proof way:
与上面的灾难性的函数式代码片段相比，让我们快速浏览一个合适地抽象的面向对象编程程序，它做了相同的事，但用来一种抽象且不过时的方式：

class Fruit {
  constructor(type, price) {
    this.type = type;
    this.price = price;
  }
}
​
class AbstractFruitFactory {
  make(type, price) {
    return new Fruit(type, price);
  }
}
​
class AppleFactory extends AbstractFruitFactory {
  make(price) {
    return super.make("apple", price);
  }
}
​
class OrangeFactory extends AbstractFruitFactory {
  make(price) {
    return super.make("orange", price);
  }
}
​
class GrapeFactory extends AbstractFruitFactory {
  make(price) {
    return super.make("grape", price);
  }
}
​
class FruitRepository {
  constructor() {
    this.fruitList = [];
  }
​
  locate(strategy) {
    return strategy.locate(this.fruitList);
  }
​
  put(fruit) {
    this.fruitList.push(fruit);
  }
}
​
class FruitLocationStrategy {
  constructor(fruitType) {
    this.fruitType = fruitType;
  }
​
  locate(list) {
    return list.find(x => x.type === this.fruitType);
  }
}
​
class FruitPriceLocator {
  constructor(fruitRepository, locationStrategy) {
    this.fruitRepository = fruitRepository;
    this.locationStrategy = locationStrategy;
  }
​
  locatePrice() {
    return this.fruitRepository.locate(this.locationStrategy).price;
  }
}
​
const appleFactory = new AppleFactory();
const orangeFactory = new OrangeFactory();
const grapeFactory = new GrapeFactory();
​
const fruitRepository = new FruitRepository();
fruitRepository.put(appleFactory.make(1.99));
fruitRepository.put(orangeFactory.make(2.99));
fruitRepository.put(grapeFactory.make(44.95));
​
const appleLocationStrategy = new FruitLocationStrategy("apple");
​
const applePriceLocator = new FruitPriceLocator(
  fruitRepository,
  appleLocationStrategy
);
​
const applePrice = applePriceLocator.locatePrice();
​
console.log("apple", applePrice);
As you can see, this has all of the core functionality properly abstracted. This code is solid.

如你所见，它把所有的核心函数合适抽象，这种代码是可靠的

Don’t let the simplicity fool you! It completely fulfills all of the complex business requirements that would typically be demanded by any seriously large enterprise.
不要让简单性欺骗你！它完全满足任何大企业通常需要的复杂业务需求。

This robust solution is completely future-proof, and properly makes use of enterprise-grade dependency injection.
这种健壮的解决方案完全不会过时，并且合适的利用了企业级依赖注入

---

Serious Management Needs Serious Features

严肃的管理需要严肃的功能

Hopefully by now the development team has fulfilled the complex business requirements pertaining to code abstraction, as set forth by the enterprise. The developer resources should now shift focus towards implementing the features defined by the project managers.
希望到目前为止，开发团队已经满足了企业提出的与代码抽象相关的复杂业务需求。开发人员资源现在应该将重点转移到实现项目经理定义的功能上

As any real-world enterprise product manager knows, only new features delivered have real business value. They shouldn’t be allowed to waste their resources on time-wasters like unit-testing and refactoring.
正如任何现实世界企业产品经理所知，只有提供新的功能才具有商业价值。他们不应该允许自己的资源浪费在时间浪费上，如单元测试和重构。

It is obvious that so-called “functional” programming is flawed, it makes redundant things like refactoring and unit testing unnecessarily easy. This, in turn, will act as a distraction to the development team — they might accidentally waste time on those useless activities, instead of delivering new features.
非常明显，所谓的函数式编程是有缺陷的，它使得像重构和单元测试这样的冗余事情变得很容易，但这容易是不必要的。这反过来会干扰开发团队，他们可能会意外地浪费时间在这些无用的活动上，而不是提供新的功能

This example clearly demonstrates the inferiority of functional programming — it makes refactoring too easy:
这个例子清楚地表明了函数式编程的劣势——它让重构更简单：

// before refactoring:
​

    // calculator.js:
    const isValidInput = text => true;
    ​
    const btnAddClick = (aText, bText) => {
      if (!isValidInput(aText) || !isValidInput(bText)) {
        return;
      }
    }
    ​
    ​
    // after refactoring:
    ​
    // inputValidator.js:
    export const isValidInput = text => true;
    ​
    // calculator.js:
    import { isValidInput } from './inputValidator';
    ​
    const btnAddClick = (aText, bText, _isValidInput = isValidInput) => {
      if (!_isValidInput(aText) || !_isValidInput(bText)) {
        return;
      }
    }

If such refactoring makes you cringe from its simplicity, then you’re not alone! Six lines of code before the refactor, and only seven lines of code after? You must be kidding me!
如果这样的重构让你害怕于它的简单，你不是唯一的那个人。重构前6行，重构后7行。你在逗我吧
Let’s contrast it with a proper refactor of object-oriented code:
让我们用合适的面向对象编程代码重构对比一下：

// before refactoring:
public class CalculatorForm {
    private string aText, bText;
    
    private bool IsValidInput(string text) => true;
    
    private void btnAddClick(object sender, EventArgs e) {
        if ( !IsValidInput(bText) || !IsValidInput(aText) ) {
            return;
        }
    }
}
​
​
// after refactoring:
public class CalculatorForm {
    private string aText, bText;
    
    private readonly IInputValidator _inputValidator;
    
    public CalculatorForm(IInputValidator inputValidator) {
        _inputValidator = inputValidator;
    }
    
    private void btnAddClick(object sender, EventArgs e) {
        if ( !_inputValidator.IsValidInput(bText)
            || !_inputValidator.IsValidInput(aText) ) {
            return;
        }
    }
}
​
public interface IInputValidator {
    bool IsValidInput(string text);
}
​
public class InputValidator : IInputValidator {
    public bool IsValidInput(string text) => true;
}
​
public class InputValidatorFactory {
    public IInputValidator CreateInputValidator() => new InputValidator();

That’s what proper programming looks like! Nine lines of code before, and 22 after. There’s more effort required to refactor, which will make the enterprise developer resources think twice before engaging in such wasteful activity as refactoring.
这才是一个正确编程的样子！重构前9行，重构后22行。重构需要更多的努力，这将使得企业开发人员资源在开始如重构一般的浪费活动之前三思

---

The Fallacy of Declarative Code

声明性代码的谬论

The so-called “functional” programmers erroneously pride themselves in writing declarative code. That’s nothing to be proud of — such code merely creates an illusion of productivity.
所谓的函数式程序员们以写出声明性代码错误地自豪，没什么可自豪的——这种代码只不过产生了具有生产力的错觉
The core responsibility of any developer should consist of thinking about proper rigorous object-oriented abstractions (as also demanded by any seriously large enterprise).
任何开发者的核心责任应该在于考虑合适严格的面向对象的抽象（正如任何大企业所要求的那样）
Let’s take a look at properly abstracted OOP code:
让我们浏览一下正确抽象的面向对象编程的代码：

class CountryUserSelectionStrategy {
  constructor(country) {
    this.country = country;
  }
  
  isMatch(user) {
    return user.country === this.country;
  }
}
​
class UserSelector {
  constructor(repository, userSelectionStrategy) {
    this.repository = repository;
    this.userSelectionStrategy = userSelectionStrategy;
  }
  
  selectUser() {    
    let user = null;
​
    for (const u in users) {
      if ( this.userSelectionStrategy.isMatch(u) ) {
        user = u;
        break;
      }
    }
    
    return user;
  }
}
​
const userRepository = new UserRepository();
const userInitializer = new UserInitializer();
userInitializer.initialize(userRepository);
​
const americanSelectionStrategy = new CountryUserSelectionStrategy('USA');
const americanUserSelector = new UserSelector(userRepository, americanSelectionStrategy);
​
const american = americanUserSelector.selectUser();
​
console.log('American', american);

Please focus on the imperative loop at line 20. Ignore the minor boilerplate OOP code, unrelated to the task at hand. It had to be included in order to make the code sample adhere to the rigorous abstraction requirements set forth by the serious enterprise.
请注意20行必要的循环。忽略与当前任务无关次要的样板OOP代码。必须包含它才能使得代码示例符合严肃企业提出的严肃抽象要求

Declarative code, on the other hand, is too concise, and erroneously makes the developers focus on the less important things, like business logic. Contrast the robust enterprise solution described above to a snippet of inferior “declarative” code:
另一方面，声明代码非常简洁，错误地使开发人员专注不太重要的事情，像业务逻辑。将上述描述的健壮的企业解决方案劣质的声明性代码片段相比：
SELECT * FROM Users WHERE Country=’USA’;
SQL makes me cringe every single time because of being declarative. Why SQL? Why can’t they have the developers make use of proper enterprise-grade abstractions and write normal object-oriented code? Especially when we already have those tools at our disposal. It’s mind-blowing.

SQL的声明让我每次都恐惧。Why SQL? 为什么他们不能让开发者利用合适的企业级抽象并写出正常的面向对象的代码？特别当我们拥有这些工具任我们使用时（指代用面向对象代码写出的工具，译者注），非常令人兴奋。

---

Real World Modelling

真实世界建模

Object-Oriented Programming is genius. Unlike “functional” programming, it perfectly models the real world with advanced techniques like inheritance, polymorphism, and encapsulation.
面向对象编程简直完美。与函数式编程不同，它用继承，多态和封装等高级技术完美模拟世界
Any self-respecting software developer should be making use of inheritance on a daily basis to achieve code reusability.
任何具有自尊心的软件工程师应该在日常中利用继承来实现代码的可重用性
As I said earlier, inheritance perfectly models the real world. Cats, for example, always inherit their properties and behaviors from a single abstract real-world animal.
正如我之前所说，继承完美模拟了真实世界。以猫为例，它总是继承它们的属性和行为从一个抽象的真实世界
Life originated in the ocean a few billion years ago. Therefore all mammals (including the cats) have inherited the properties of the primordial fish, like garfield.fishHead, and their methods like garfield.swim and garfield.layCaviar.
生命起源于几十亿年前的海洋。因此所有哺乳动物（包括猫）继承了原始鱼类的属性，像garfield.fishHead，它们的方法garfield.swim 和 garfield.layCaviar
No wonder cats enjoy bathing and swimming so much! Humans are actually the same, we can easily start laying caviar if we want to!
难怪猫很喜欢洗澡和游泳！人类实际上一样，如果我们愿意的话，我们可以很容易地铺设鱼子酱
Our programs should always follow similar hierarchical approaches to code organization. Functional programming erroneously rids the developers of such amazing code sharing constructs inspired by the real world. This has far-reaching consequences, especially in seriously complex enterprise software.
我们的程序应该总是遵循相似的代码组织分层方法。函数式编程错误地剥夺了开发人员由现实世界启发的这种惊人的代码共享结构（继承实际上也是共享父类的属性，译者注）。这会产生深远的影响，特别是在重要复杂的企业软件中。

---

Functions Should Always be Bound to Objects

函数应该总是被绑定到对象

This is just common sense and also perfectly models the real world. The notebook you buy at Chapters comes with a built-in “write method”.
这是常识，也完美地塑造了真实世界。你在Chapters 购买的笔记本内置了“写入方法”
This method is to be called whenever you’re planning to write things down.
无论何时计划写点东西，都会调用此方法

You may not realize this, but you also have methods like .eat(veggies), doHomeWork . This is just common sense, how else would your mom be able to make you eat your veggies and have you complete your homework? Of course, she used to call those methods directly!
你可能没意识到这点，但是你也有像吃蔬菜，做家庭作业的方法。这是常识，你的妈妈怎么能让你吃蔬菜并让你完成家庭作业？（意思是你吃蔬菜这种行为只能你来完成，译者注）当然，她以前也直接调用这些方法

No job in the real world can be done without hiring a dedicatedManager that coordinates tasks.
如果不聘请一个专用经理协调任务，就无法在现实世界中完成任务
Young people probably need a manager to satisfy their basic human needs, you know, things like “netflix-n-chill”. Who is going to coordinate the entire process, after all? If they’re smart, then they’d hire multiple managers, just like OOP recommends.
年轻人可能需要一个经理来满足他们的的基本人类需求，比如“netflix-n-chill”（yuepao的含义）。毕竟谁会协调整个过程？如果他们聪明，他们会雇佣多个经理，像OOP推荐的那样。（多个对象？）

In the real world, creating anything new and cool also requires having a dedicated Factory. Leonardo owned a MonaLisaFactory , Trump builds a secretWallFactory. Russia used to have a CommunismFactory , and nowadays mainly maintains itsCorruptionFactory, hidden somewhere deep within the dungeons of Kremlin.
在现实世界中，创造任何新和酷的东西需要专门的工厂。莱昂纳多拥有一个MonaLisaFactory，特朗普建立了一个秘密WallFactory.俄罗斯曾经有过CommunismFactory，现在主要维持着它的CorruptionFactory, 隐藏在克里姆林宫某处的地下深处

One can clearly see that this is just another nail in the “functional” coffin since it makes no attempt to model the real world. The functions are allowed to exist separately from objects, which is plain wrong. Functional programming, obviously, is unsuitable for any serious real-world coding.
人们可以清楚地看到这只是函数式编程棺材中的另一个钉子，因为它没有试图模拟现实世界。
函数允许与对象分开存在，这是完全错误的。显然，函数式编程不适用于任何严肃的真实世界的编程。

---

Functional Programming Provides no Opportunity for Growth

函数式编程没有任何成长的机会

First and foremost, software engineers should focus on constant improvement and growth. A vast amount of knowledge has to be acquired by a software engineer in order to truly master Object-Oriented Programming.
首要的，软件工程师需要专注持续的提升和成长。掌握大量的知识以真正掌握面向对象编程

First, they’d have to learn advanced OOP techniques like inheritance, abstraction, encapsulation, and polymorphism. Then they should familiarize themselves with a multitude of design patterns (like the Singleton), and start making use of them in their code. There about 30 basic design patterns that have to be learned. Ideally, somewhere around this point, the developer should start making use of various enterprise-grade abstraction techniques in their code.
首先，他们应该学习高级的OOP技术，如继承，抽象，封装和多态。然后他们应该熟悉大量的设计模式（如单例），并开始在他们的代码中应用这些模式。大约有30种基础的设计模式需要学习。理想情况下，在这一点上，开发者应该在代码中开始利用各种企业级抽象技术

The next step is to get familiar with techniques like Domain-Driven Design and to learn to break down the monolith. It is also recommended to learn proper refactoring tools, like Resharper, since OOP code is not trivial to refactor.
下一步是熟悉领域驱动设计技术，学习打破整体。还建议学习合适的重构工具，比如Resharper，因为OOP代码重构并不容易

It takes at least 20–30 years to get good with OOP. Even then most people with 30 years of OOP experience haven’t truly mastered it. The learning path is rough, filled with uncertainty. A lifetime of learning awaits the OOP developer, how exciting is that?
至少要花20-30年精通OOP。甚至大多数人30年的OOP经验都没有真正掌握它。学习道路坎坷，充满了不确定性。一生学习等候OOP的开发者，这多么令人兴奋1

What about the poor functional programmers? Unfortunately, there’s not much to learn. I have personally taught a few junior developers functional programming in JavaScript, and they became really good at it in about half a year. They simply had to understand a few basic concepts and then learned to apply them pretty quickly. Where’s the thrill of lifetime learning? I wouldn’t envy them.
可怜的函数式程序员呢？不幸的是，没有太多东西学习。我亲自用JavaScript教过几个初级程序员函数式编程，他们大约半年就非常擅长了。他们只需要了解一些基本概念，然后很快应用它们。终身学习的快感激情在哪里？我不会羡慕他们

---

Success is a Journey, Not a Destination

成功是一次旅程，而不是目的

Let’s admit it, we programmers are being paid for our time. Just as the construction workers who’ve been digging holes not far from my house for the past two years (btw they’re building a ̶w̶a̶l̶l road).
让我们承认它，我们这些程序员以自己的时间作为回报。就像过去两年离我家不远的打洞的建筑工人（顺便提一下，他们在修墙路）（暗讽特朗普修墙吗？）
Let’s define programmer productivity. Everyone who has worked in any seriously large enterprise knows the simple formula for success:
让我们定义下程序员的生产力。在任何大公司工作的每个人都知道这个成功的简单公式：

productivity = lines_of_code x bugs_fixed

---

Bugs Fixed

修BUGs

Human brains are really bad at working with state, we can only hold about five items in our working memory at a given time. State in programming usually refers any data in memory — e.g. fields/variables in OOP. Working with mutable state is very similar to juggling. I don’t know too many people who can juggle three balls, let alone five.
人类大脑在和状态合作时非常糟糕，我们只能在特定的时间在工作记忆中容纳5个状态。编程中的状态通常指储存器中的任何数据。例如——OOP中的字段/变量。使用可变状态与杂耍非常类似。我不知道有多少人可以玩三个球，更别说5个了

OOP makes good use of this weakness. Almost everything is mutable in OOP. Thank god that OOP takes the matter of developer productivity seriously! In OOP all of the mutable state is also shared by reference! This means that you not only have to think about the mutable state of the object that you currently are working with, you also have to think about the mutable state of 10–50 of other objects that it interacts with! This is akin to trying to juggle 50 balls at the same time, and also has the added benefit of acting as a really good exercise for our brain-muscle.
OOP充分利用了这个弱点。几乎所有在OOP中都是可变的。感谢上帝，OOP认真考虑开发者的生产力问题！在OOP中，所有的可变状态通过引用共享！这意味着你不仅要考虑你目前工作的对象，也需要考虑与其交互 的其他10-50个对象的可变状态！这类似于在同一时间玩50个球，并且对我们大脑肌肉来说，有类似于很好运动后的额外好处。

Bugs? Yes, eventually we will drop some of the balls that we’ve been juggling. We will maybe miss some smallish details from the interaction of those 50 objects. But who cares, really? Bugs should be reported by customers in production, that’s how any seriously large enterprise works. Then the bugs go into the JIRA backlog (serious enterprise-grade software as well). A few years from now the bugs will be fixed. Problem solved!
Bugs？是的，最后我们将放弃一些我们正在玩的球。我们会错过50个交互对象中的一些细节。但谁在乎呢，真的吗？生产中的客户应该报告Bugs ，这就是任何一家大型企业的工作方式。然后这些bugs进入JIRA积压（严重的企业级软件）。几年后，错误得到修复，解决了。

God, I love using my mobile banking app. It is very advanced, the bank values my business and they take my privacy seriously. The bugs are just features (I was told)!
上帝，我喜欢使用我的手机银行应用。它非常先进，银行非常重视我的业务，他们认真对待我的隐私。bugs只是功能（我被告知）！

So-called “functional” programming erroneously isolates state and makes the state immutable. This has an unfortunate consequence of reducing complexity, and thus reducing the number of bugs. Having fewer bugs in the codebase means that we will have fewer bugs to fix. Contractors won’t be able to keep charging their clients for those bug fixes. Developers working in any seriously large enterprise will start looking bad in the eyes of their managers, while seriously jeopardizing their chances of success within the organization.
所谓的函数式编程错误地孤立了状态并使状态不可变。这具有减少复杂性和错误数量的不幸后果。代码库极少的bugs意味着我们只有极少的bugs修理。承包商将不能从修复客户端bugs而收费。在任何大公司工作的开发者在经理看来都很糟糕，这将危害他们在组织内成功的机会。

---

Lines of Code

代码行

We should also be able to show continuous progress to our management. And what is the most effective way to show progress? Lines of code, of course! Had we all switched to functional programming, we’d make the management very upset and suspicious. The “declarative” code would have made our code more concise, and the lines of code would decrease drastically. Up to 3–5 times less code to achieve the exact same goal, this is unacceptable!
我们应该能够对我们管理层表现出持续的进步。什么是最有效展现进步的方法？当然是代码行！如果我们转向函数式编程，我们会让管理层非常沮丧和怀疑。声明性代码会使我们的代码更简洁，代码行将急剧下降。实现完全相同的目标减少了3-5倍的代码，这是不可接受的。

In other words, our productivity would plummet in the face of serious enterprise management, and our jobs once again would be put in jeopardy. It is in our best interests to stay away from the “functional” programming.
换句话说，面对严肃的企业管理层，我们的生产力将急剧下降，我们的工作将再次陷入危险之中。为了我们最佳的利益，远离函数式编程吧。
The same advice applies to the contractors who charge their clients for hours worked. Here’s a simple formula for success:
同意的建议适用于向客户收取工时数的承包商。这里有一个成功的简单公式。

lines_of_code = time_to_write = $$$pure_profit$$$

This formula for success, of course, also directly applies to the serious software contractors who get paid for the lines of code:
这个成功的工时，当然也直接适用于按代码行付费的严肃的软件承包商

if (1 == '1') {  doStuff();
} else {
  // pure profit
}

---

Spaghetti is Our Bread and Butter

意大利面是我们的面包和黄油

Unlike Functional Programming, OOP offers us a consistent way to write spaghetti code — a real boon to developer productivity. Spaghetti code equates to more billable hours, which translates to pure profit for the serious OOP engineers. Spaghetti doesn’t only taste delicious, it is the bread and butter of OOP programmers!
不像函数式编程，OOP给我们提供了一种写意大利面条式的一致性方法——对开发人员生产力的真正福利。意大利面条式代码相当于更多的可计费小时，对严肃的OOP工程师来说，这会转换为纯利润。意大利面条不仅可口，也是OOP程序员的面包和黄油。

Object-orientation is a true boon for contractors and employees of serious enterprise alike.
面向对象是承包商和严肃企业雇员的真正福音

---

Bug Prevention Department

bug预防部门

You should not fear using OOP. Once again, those pesky bugs are nothing to worry about! Any serious enterprise has an entire bug prevention department (aka customer support), whose main job is to protect their developer resources from angry customers. It’s the customer’s fault that they can’t use the app properly, after all.
你不应该对使用OOP感到害怕。再说一遍，那些讨厌的bugs无须担心！任何严肃企业有一个完整的bug预防部门（又称客户支持），他们的主要工作是保护他们的开发人员资源免受客户的愤怒。毕竟，这是客户们的错，他们不能合适地使用应用程序

The developers should not be bothered with such irrelevant things as bug reports. This ensures that none of the enterprise resources are wasted, and allows the developers to focus on implementing new features while making use of proper enterprise-grade object-oriented abstractions and complex design patterns.
开发人员不应该被那些诸如bug报告等无关的事情干扰。这将保证没有任何企业资源被浪费，也会允许开发者们在充分利用企业级面向对象抽象和复杂设计模式的同时专注于实现新的功能。

---

Bug Report Process

bug报告流程

An elaborate and rigorous process is typically put in place to protect enterprise resources. Once a customer has encountered a bug, they typically have to look for the customer support phone number online. Then the customer is presented with an advanced and interactive phone menu consisting of various options. It usually takes two to five minutes to listen to the menu and select the correct option. The least persistent customers usually fall off at this step.

通常采用一个详尽且严格的流程来保护企业资源。一旦一个客户遇到错误，他们通常必须在线浏览客户支持电话。然后向客户呈现由各种选项组成的高级和交互的电话菜单。通常需要花费2-5分钟的时间收听和选择正确的选项，耐心最差的客户通常在此步骤中离开。

Then the customer is usually told that the company is experiencing an “unexpectedly large volume of calls”, and that “the average wait time is 56 minutes”. They usually apologize for the inconvenience and mention how much they value the business of the customer. Most of the customers will usually decide not to report the bug at this step. To keep the customer entertained, inspirational music typically is being played. They’re also told to check out the awesome new app. The app that the customer was having trouble with in the first place.
然后客户通常被告知公司正在经历意外的大量呼叫，平均等待时间是56分钟。他们通常为不便道歉，并提到他们对客户业务的重视程度。大多数客户通常决定不在此步骤报告错误。为了让客户娱乐，通常会播放鼓舞人心的音乐。他们也被告知查看这个很棒的新应用。即客户首先遇到问题的应用程序

After the 56-minute wait is over, the call gets routed to a call center located somewhere in The Northern Americas. The local American employees typically go through rigorous training that enables them to speak with a thick Indian or Bulgarian accent. The agent mentions that the app in question is not his responsibility but happily will transfer the client to another department.
56分钟的等待结束后，呼叫被路由的北美的某个呼叫中心。当地的美国雇佣通常会接受严格的训练以便他们可以说出一口浓重的印度或保加利亚口音。代理人提到有问题的应用程序不是他们的责任但是很乐意将客户转接给另一个部门

After another 42 minute wait, an agent happily tells the customer that this bug actually is a feature, and recommends the user to go through the help section of the app. If the customer is still being persistent, the agent might create a support ticket and the customer might even hear back! The bug can’t be reproduced.
再经过42分钟的等待，一个代理人高兴地告诉客户这个bug实际上是一个功能，并提醒用户浏览应用程序的帮助部分。如果这个客户仍然坚持不懈，代理可能会创建支持服务单，客户可能会收到回复！该bug将不会重现

I hope by now you are convinced, that worrying about bugs is not the job of a developer. Serious measures are typically put in place by the enterprise to protect their developer resources.
我希望到此为止你能确信，担心bugs不是开发者的工作。企业通常采取严肃的措施保护他们的开发人员资源。

---

Avoid Rookie Job Interview Mistakes

避免新人求职面试的错误

If you are actively looking for a job, then put some effort into removing all of the “functional” nonsense from your resume or nobody will take you seriously. Nobody in the real enterprise world is trained in childish things like “function composition”, “purity”, “monads” or “immutability”. You don’t want to look like an outsider. Speaking about such things will make your interviewer appear dumb, and will completely annihilate your chances of success.
如果你正在积极寻找工作，那么就付出一些努力从你的建立移除所有的函数式废话，否则没人认真对待你。真是企业世界里没人接受像函数组合，纯度，monads，不变性这样的幼稚事物的训练，你不能看起来像个外行。说关于那些的事情会让你的面试官显得沉默，并会彻底湮灭你成功的机会

The enterprise technical recruiters also go through mandatory rigorous training, which enables them to properly differentiate between serious technologies like Java and JavaScript.
企业技术招聘人员还要经过强制性的严格训练，这使得他们正确区分Java和JavaScript等严肃技术​。

Be sure to sprinkle words throughout your resume that demonstrate your extensive knowledge of the various rigorous enterprise-grade abstraction techniques like classes, inheritance, design patterns, dependency injection, SOLID, abstract factory, and singleton.
请务必在整个简历中泼墨一些文字，证明您对各种严格企业级抽象技术如类，继承，设计模式，依赖注入，SOLID，抽象工厂和单例的广泛了解

When asked to implement the classical FizzBuzz job interview problem on the whiteboard, make sure that you come well-prepared. This is your opportunity to shine and demonstrate your rigorous enterprise-grade system design abilities. Your first step is to adequately design the solution while making use of proper OOP design patterns and rigorous enterprise-grade abstraction techniques. FizzBuzzEnterpriseEdition is a good starting point. Many make the rookie mistake of relying on inferior design techniques like functions. No wonder they never hear back from the potential employer.
当被要求在白板上实现经典的FizzBuzz求职面试问题时，确保你已经准备充分​。这是你出众和证明你严格企业级系统设计能力的机会。你的第一步是充分设计解决方案，同事充分利用OOP设计模式和严格的​企业级抽象技术。FizzBuzzEnterpriseEdition是一个好的起点。许多人都犯了一个新手错误，依赖函数劣等设计技术​。难怪​他们从未听过潜在雇主的回复。

---

Functional Programming Can’t Possibly be Used to Build Serious Software Solutions

函数式编程不可能用于构建严格的软件解决方案

Having considered all of the serious and rigorous arguments above, one can now clearly see that nothing good ever came out of this so-called “functional” programming. It’s clear it should be avoided at all costs.
考虑了上述所有严肃且严格的论点后，人们现在可以明确地看到函数式编程没有任何好处​。很明显应该不惜一切代价回避它

The so-called “functional” programming was a fad of the last couple of years. It’s good that it is already going away! The big fish like Facebook and Microsoft have long ago realized the limitations of functional programming and the clear superiority of object-oriented approaches to code organization. They’re shifting their resources towards a new generation of object-oriented languages, namely ReasonOL and BosqueOOP. Such languages bring state mutability to a whole new level and fortunately have no support for useless functional things like immutable data structures.
所谓函数式编程已经是过去几年的时尚了，它已经消失了，非常好​。向Facebook和Microsoft这样的大鱼早就意识到函数式编程的局限性以及面向对象方法组织代码的明显的优势​。他们将资源转向新一代的面向对象语言，即ReasonOL and BosqueOOP.这些语言将可变状态提升到一个全新的水平，幸运的是它不支持像不可变数据结构体这些无用的​函数式事物。

---

The Boon of Gods

神的恩赐

So you might ask what are the alternatives to the so-called “functional” programming? Object-Oriented Programming, silly! It was bestowed upon us by the one true god of programming himself. OOP is a force to be reckoned with. It is the ultimate tool for developer productivity and will always keep you and your teammates busy (and employed).
所以你可能会问函数式编程的替代品是什么​？面向对象编程，傻​！它是一个真正的自编程之神赠与我们的​。OOP是一种不可忽视的力量。他是开发人员生产力的终极工具，会让你和你的队友忙碌（和受雇）​
​
May the (object-oriented) force be with you. And your codes. I’m one with the force. Peace.
愿（面向对象）的力量与你同在​，和你的代码。我是一个有力量的人。和平

PS> As most of you have guessed, the post is a satire. To all of the new developers out there — don’t take this seriously, FP is great! Invest some time into learning functional programming, and you will be ahead of most of your peers.
正如大多数人猜测的，帖子是讽刺作品​。对于那里的所有开发者——不要认真对的。函数式编程很棒​！花一些时间学习函数式编程，你将领先于戴安多数同行。

I hope you’ve enjoyed reading this post as much as I’ve enjoyed writing it!
我希望你喜欢阅读这篇文章，就像我写这篇文章一样​！