对巴解组织的看法很有意思

 
少读激进的计生协会活动家的文章。FP的概念不是一年或两年前就有的,但你没有听说过一场革命
 

这不是OOP的问题,而是它的应用问题,更是应用它的人的问题。他们是那些觉得...

在OOP的帮助下,你可以写出令人难以置信的东西,这让我感到兴奋,甚至是狂喜。

令人难以置信的复杂的代码(甚至在其中竞争:)。他们觉得自己是一个特殊的精英阶层。

他们甚至发明了他们自己的 "伟大的书",他们读了又读,却不能

但他们无法阅读。它被称为"设计模式"--在人类语言中

译为 "编写模糊、模糊和混乱的代码的终极艺术"。然而,如果

这是 一个非常,非常酷的事情,令人难以置信的简化和

简化和简化了生活。

 

你应该明白,这类文章很可能是由不熟悉FP的人写的,其混乱的钩子,可以包括20个标签....。

硬性FP是另一回事。然后你开始考虑OOP的简洁性和便利性,你可以提前声明一些功能,等等.....。在本质上,一个人与另一个人的相似性。这只是这样的文章往往写的人谁已经掌握了只有程序代码 - 而这甚至不是接近FP,所以,如果你不知道什么钩和生动的使用它,没有FP是出了问题

此外,文章中列出的许多 "垂死的语言"都支持FP和OOP的全部功能,它们为什么要死亡呢!而且其中有几位是独联体国家 中收入最高的。
 
我说的是OOP中的 "疏散化",没有想到FP中的 "淹没"。在我看来,程序化范式是现实的,比OOP更节约资源。
 
Mikhail Mishanin:
它更多的是关于OOP中的 "修饰",完全没有考虑 "淹没 "在FP中。在我看来,程序化范式是现实的,比OOP更节约资源。

是的,有一个构造函数,在某些情况下,它的代码通常比较长....。从技术上讲,FP的部署对于机器代码的生成应该是更有效的....。但代码并没有变得更简单,就打字而言,不可能做出正常的包装器......

这些天,你经常可以找到一个和另一个的混合体--方式不互相干扰

 
Alexandr Andreev:

是的,有一个构造函数,在某些情况下,它的代码通常比较长....。从技术上讲,FP的部署对于机器代码的生成应该是更有效的....。但代码并没有变得更简单,就打字而言,不可能做出正常的包装器......

如今,经常可以看到一种和另一种的混合。

如果没有OOP和FP,一切工作都会更容易和更快(是的,没有 "美女"、面板等),但有时甚至很难理解自己的代码)

 
Mikhail Mishanin:

没有OOP和FP,一切工作都更容易、更快(是的,没有 "美女"、面板等),但有时连自己的代码都难以理解)。

首先掌握一个或另一个,或者最好两个都掌握,然后再决定你喜欢哪个。而像现在这样的做法,随着时间的推移,你会变成费多谢夫,同意一切你不理解的东西(即几乎所有的东西)。

 
世界范围内的新技术趋势是研究新事物三个月,使用一个月(收集一堆虫子),然后报废,然后再次研究新事物三个月,一个月后再报废(收集另一堆虫子)。如果有人喜欢这样的生活方式--欢迎你。
 

这是对话题的破坏性反应,也是一种破坏性的讨论。告诉我一个程序化编程的追随者,如何避免OOP中的 "面条化",如何解析以及使用别人的 "面条 "是否有意义?

毕竟,事实证明,OOP主要是为了可读性和团队编程,也就是为了大型项目。一个专家顾问,在其图表上交易一个符号,控制账户中的余额/资金的最大风险,好了,不能被称为一个大项目 - 它是足够的,更有利的内存/速度 - 程序化编程。

问题。

- 个人经验中的OOP(作为必须的)的缺点/劣势

- 从个人经验来看,FP的缺点/劣势(作为声明性的)。

而对前景的看法当然是有趣的,特别是在并行计算 的方向。我不认为触及量子话题有任何意义。

 
Mikhail Mishanin:

告诉我,作为一个程序员,如何避免OOP中的 "拼凑 "现象?

引用的文章中给出了秘诀:努力编写确定性的函数。

如何拆解,用别人的 "面条 "有意义吗?

好的代码,是的,但不是意大利面条。

毕竟你能得到什么,OOP主要是为了可读性和团队编程,也就是为了大项目。

对。

一个EA在图表上交易一个符号,并对余额/账户资金进行最大限度的风险控制,嗯,不能称之为一个大项目--所以程序化编程是足够的,而且在内存/速度方面更有利。

去澳大利亚旅行,用飞机比较方便(OOP),去邻近的城市旅行,用汽车甚至自行车就可以了(PP)。你只需要选择更方便的手段来实现目标。

原因: