- 主题:一个项目想从4.7迁移到dotnet5，又放弃了
面向对象这个模式由于java的历史性的成功，有点被捧得过分了，后来函数编程
的模式追了上来，两种模式都很重要，在面向数据、分布式的环境里面，可能函
数编程的地位还更高一点
【 在 KEILLY (米饭) 的大作中提到: 】
: 我一上来就学C# 7.2
: 用了3年，基本全是糖、无视“面向对象”设计模式。
--
FROM 221.218.138.*
面向对象的成功是因为以前都在搞 C++ GUI 编程。这个领域天然适合面向对象编程。
【 在 GoldenBull (祝病魔早日战胜方老师) 的大作中提到: 】
: 面向对象这个模式由于java的历史性的成功，有点被捧得过分了，后来函数编程
: 的模式追了上来，两种模式都很重要，在面向数据、分布式的环境里面，可能函
: 数编程的地位还更高一点
: ...................
--
FROM 125.78.67.*
我一直觉得OO那些概念就是一堆人做UI做出来的经验总结
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 面向对象的成功是因为以前都在搞 C++ GUI 编程。这个领域天然适合面向对象编程。
--
FROM 116.233.90.*
是的。java 刚出来的主要用处也是 GUI，后来才慢慢地搞成了 web 系统专用，变成写业务脚本的最佳语言。
其实写业务脚本，java 的面向对象反而不适合，还是结构化编程好。最能证明我这个论点的是，java 领域特别喜欢搞单例。很多单例内部并不存储数据，存的只是另外一个单例的引用。这种用法，和数据存在结构体里面，函数处理结构体并没有区别。
现在各种 FP 语言兴起，背后就暗示着 GUI 编程极大衰弱。
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 我一直觉得OO那些概念就是一堆人做UI做出来的经验总结
--
修改:hgoldfish FROM 125.78.67.*
FROM 125.78.67.*
说到这个，，现在 js web 社区试图使用 fp 搞 GUI 编程的路子，注定是条死路。
GUI 编程没有那么多数据流动。因为有网络下载延迟这个限制，程序也没法搞得很大。单个系统的业务逻辑一般很简单。根本不适合 FP 这个流派。
相反，我觉得 nodejs 搭配一门 fp 语言，拿来搞后端的网络编程，一定可以大放异彩。
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 我一直觉得OO那些概念就是一堆人做UI做出来的经验总结
--
FROM 125.78.67.*
过程即函数
类型属于数据
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 是的。java 刚出来的主要用处也是 GUI，后来才慢慢地搞成了 web 系统专用，变成写业务脚本的最佳语言。
: 其实写业务脚本，java 的面向对象反而不适合，还是结构化编程好。最能证明我这个论点的是，java 领域特别喜欢搞单例。很多单例内部并不存储数据，存的只是另外一个单例的引用。这种用法，和数据存在模块里，函数处理数据并没有区别。
: 现在各种 FP 语言兴起，背后就暗示着 GUI 编程极大衰弱。
: ...................
--
FROM 116.233.90.*
这是混淆视听。。
java 多余的 oo 负担，就会导致 java 的代码量多出很多。导致生产率的降低。
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 过程即函数
: 类型属于数据
--
FROM 125.78.67.*
我说的是编程范式的方向
好吧，其实就是golang那个路数
不过仅限于type和func的处理部分
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这是混淆视听。。
: java 多余的 oo 负担，就会导致 java 的代码量多出很多。导致生产率的降低。
--
FROM 116.233.90.*
我觉得 jvm 上面的几门语言路子都不对。如果能仿 golang 改一改，应该能大火。
1. 我拿 kotlin 写过项目，其实就是加个大量糖的咖啡。腻得喝不下。
2. groovy/jython 都是脚本语言，速度太慢，可以做业务脚本，但是性能不行。
3. scala 我没在项目中用过。方向是对的。奈何门槛比较高。
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 我说的是编程范式的方向
: 好吧，其实就是golang那个路数
: 不过仅限于type和func的处理部分
: ...................
--
FROM 125.78.67.*