Мнение редакции может не совпадать с мнением автора оригинала. По мнению многих, ООП является жемчужиной информатики. Идеальное решение для организации кода. Конец всем проблемам. Единственный верный способ написания программ. Дарован нам самим истинным Богом программирования. Но это не так. Люди начинают уступать под тяжестью абстракций и...
这里有详细的统计数据https://githut.info/， 但这是14年的数据。
github上的最新统计数据https://madnight.github.io/githut/#/pull_requests/2019/2
我认为每个人都会从阅读这篇文章 的专业意见中受益。
祝好运
我认为每个人都会从阅读这篇文章 的专业意见中受益。
该文章的所有（完全有偏见的）结论都被一个简单的问题所抵消。
FP已经存在了很长一段时间，如果它是如此令人敬畏，为什么它仍然有这样一个小的利基？
我的意思不是说OOP是最好的概念或OP很糟糕。
这篇文章的所有（完全有偏见的）结论都是由一个简单的问题来决定的。
FP已经存在了很长时间，如果它是如此令人敬畏，为什么它仍然有这样一个小的利基？
这篇文章有这个问题的答案。你没有仔细阅读。
这篇文章对这个问题有一个回答。
完全有偏见，什么都不说。
有的开发人员实际上是在写代码。有些管理人员可能根本不知道如何编程。
因此，技术栈不一定是由开发人员选择的。而且，如果某个堆栈能让一个团队更有效地解决问题，你不需要知道和拥有这项技术就能理解它。
你仍然认为这篇文章回答了这个问题吗？
我认为每个人都会从阅读这篇文章 的专业意见中受益。
祝好运
这里有一个惯例。极端的观点。这就像争论什么更好--锤子或大锤。
你不会在C#中写出好的工具，但在纯C中，你会为描述和调试严重应用中的夯实的逻辑链而感到厌倦。
所以这篇文章没有任何用处。
事情总是这样的。极端的观点。这就像争论什么更好--锤子或大锤。
你不会在C#中写出好的工具，但在纯C中，你会为描述和调试严重应用中的夯实的逻辑链而感到厌倦。
因此，这篇文章是关于什么的。
当然，这篇文章中也有一些事实...至少，继承会 "拉出 "那些并不真正需要的方法和字段，但可惜的是，你必须为一切付出代价--它节省了时间，但它可能会增加内存的使用或解决方案的整体性能，但五不是所有的悲伤，现在的编译器和代码优化水平是非常陡峭的，所以输出的结果往往是一个良好的解决方案，开发时间短
关于C#，好吧，如果它有其他的目的，它纯粹是一种 "Windows语言"，在特定的PC或有限的一组PC上快速获得结果，即使没有安装更新。.Net可以在没有访问权限的PC上导致关键的错误，并且抓住这一点是相当昂贵的 - 用C#写了一个交易面板，已经在虚拟机 上检查了它，如果没有安装更新中的所有 "补丁"，该项目不能预测地反弹;)当然，你可以尝试为最初级的.Net版本写作，但有一个问题--GitHub上的所有新闻都是在新的.Net构建下发布的--也就是说，你将只局限于他们的发展。
总的来说，就像其他地方一样--创新是 "痛苦的、漫长的、悲伤的"，你必须跟随IT巨头设定的趋势，然后一切都写得很快，没有问题，好在微软用OOP风格写了所有他们能写的东西，你必须全部使用，否则将从头开始写他们所有的WinForm，等等，自Win-95以来写了数千吨和数兆字节的代码))
文章中当然有一些事实...
有一点吗？)实际上，这只是它的方式。然而，作者并没有揭示真相，这是很明显的事情（至少对我来说）。 我想任何有经验的程序员都会对改变状态的问题有同样的认识。顺便说一下，我最近看到一篇非常类似的文章，但比较短。但是，也许，这是功能主义者和开源程序员之间永恒的辩论 )
但事实上，没有人阻止你正确地使用OOP。 甚至作者自己也提到，你可以使用不可变的对象。 而且99%的描述的问题都会马上消失。 所以，这一切只取决于手要直，头要靠肩的问题，而不是正在使用的范式。
当然，流行的OOP语言并没有提供控制对象可变性的方法，这使得这个过程变得复杂。 所以，如果能有一个关键字immutable 而不是const/readonly，那将非常酷。
至于函数式语言 不受欢迎的原因，我不同意作者的观点。 首先，在我看来，对这种代码的认识更加复杂。 这不仅仅是OOP和FP的对立，而是命令式和函数式方法的对立。 在我看来，第一种方法对大多数人来说更加接近和直观。我只是通过对应的方式了解函数式语言，所以我不能客观地评判它们，但是，例如，当我看到用lambda加载的代码时，就会产生认知上的不协调）它太复杂了，错综复杂。 可能大多数人也是这样认为的 )
此外，函数式语言并不打算用于一些与外部环境互动的任务。 以GUI为例。当以这样或那样的方式，你需要在事件之间存储全局变化的状态。
有一点吗？)事实上，情况正是如此。然而，作者并没有透露美洲的情况，这些东西是很明显的（至少对我来说）。 我想任何有经验的程序员都会对可改变状态的问题有同样的认识。顺便说一下，我最近看到一篇非常类似的文章，但比较短。但是，也许，这是功能主义者和开源程序员之间永恒的辩论 )
但事实上，没有人阻止你正确地使用OOP。 甚至作者也提到你可以使用不可变的对象。 而99%的描述的问题都会立即消失。 所以这一切只取决于手直和头在肩上的问题，而不取决于使用的范式。
当然，流行的OOP语言并没有提供控制对象可变性的方法，这使得这个过程变得复杂。 如果能有一个关键字immutable 而不是const/readonly，那就很酷。
在任何情况下，在不久的将来都不会有什么变化，IT巨头们支持这种模式，这可能有利于迫使软件开发者做出复杂的实现，这将需要更强大的硬件来工作，以及以OOP的形式为操作系统或编译器提供现成的库的文件，这迫使开发者....。以此类推，无穷无尽；)
我们可以把这个OOP故事看作是医护人员必须掌握的拉丁语知识--它不是必须的，但作为专业层面的交流手段，它是必须使用的；)