商业公司，尤其是外包产业的，应该一点也不奇怪。

许多世界级别的外包公司，GitHub 上面的开源项目比学生的作业还敷衍，很能代表这个产业对开源社区的态度。

大概是，「业务」

@tool2d 函数式编程不是写函数，是探讨怎么以函数为最小可复用单位去进行各种组合和抽象。状态与否也不是函数式所关心的，状态本身在常见的函数式编程语言里可以用数据结构来表达。

如果您说的写函数是指，`void fun() { foo(); bar(); baz() }` 这种写法，这和函数式完全没有任何关系，这叫过程式，写的其实也只是子过程而已。

函数式编程至少要求可组合的函数，比如说，`f x`，`g (f x)`，这里的函数和数学上的函数是可以一一对应的。那么对编程语言的要求也是最少要支持以函数为参数或者作为返回值来计算（也就是高阶函数）。至于其他更复杂的构造都是后话了。

不知道现在 compose multi 对 data binding 和 mvvm 的支持如何，如果可以用的话感觉还是值得一试的。

一个具体的物体，一个可以划入若干个物体的分类，还有能够表达「某些分类的共性」的抽象概念，应该能找到一些比较好的例子去讲解。

没有 interface 还有 trait ，还有 typeclass ，当然这两个和 interface 经常混在一起。只讨论使用的话，作用也很相似，提取出公共接口提供代码复用而已。

表达子类型关系，除了继承完全也可以用别的方式来做，比如说组合或者混入，比如说把方法的实现写进 interface 让具体类型提供最小的需要实现的条件，比起直球继承，这种写法最大的好处大概就是松耦合和类型安全了。

把函数编程理解为一堆函数然后封装起来，感觉是既不懂 FP 大概也不懂 OOP 的发言。

面向对象只是一个范式而已。你用 Haskell 也能写出 OOP 的代码。而且近年来 OOP 不是也在转向组合优于继承和 declarative code 之类的比较良好的做法嘛。

真要说糟糕的，大概还是那种「鸟是动物，所以会飞」之类的教学法和思维定势，但是 op 也提到了这本身并不是 OOP 的问题吧。OOP 也有不强调继承而强调消息传递的思路。

然后就是 Java 或者上古 C#那套屎山堆叠，但是这玩意哪怕没 OOP 也有 Cobol 和 Fortran 珠玉在前。反过来说，如果没有 OOP 做铺垫，有多少人能有机会碰到 FP 的概念呢？

我对 OOP 也有偏见，但是实话说很多东西并不是 OOP 的锅。

有没有办法屏蔽关于 chatgpt 的话题。

Lovelive limited...这是做校园偶像的吗

@houshuu readme 开源的东西怎么讨论算法模型（

如何看待：按照对方自己认定的性别来看待。
如果有孩子：抱歉，最后一代。但纯粹按理论上讲的话，我会支持 TA 的想法并且给予尽可能的帮助。
其他人是 trans：和别人相处的时候性别不重要，不管是什么性别都有友善的和狗屎的人。

「正常」的男女性这个说法很让人膈应。

这个贴子里面的仇恨言论和居高临下俯瞰人的贵族态度感觉很能体现当代互联网的氛围。

大革命时期的法国也是数字排序的。

没必要在乎 star 吧，把文档写好，如果许多人感兴趣的话，说明这个项目对别人可能有帮助，那就可以考虑一起讨论然后拉个社区出来，没有人的话就自己自娱自乐也挺好。

陡峭的不是应用技术而是应用技术背后的原理。

React 和 Flutter 都是典型的上手很顺滑但要往深了学需要花费大量精力熟悉许多不同领域的技术栈。

op 之前的 post 里面好像提到过 compose 和 kotlin 吧，为什么这个 post 里面没有了呢。

感觉 op 的 cv 没什么亮点，这个可以稍微提一下的吧。

没觉得 python 如何逆天，也没觉得 kotlin 如何函数式了。

但是这些都只不过是语法而已，计算机科学的范畴很广，语法也许是这里面最不重要的一点了。android 也好，spring 也好，react 也好，这些应用层的东西，在没有理论背景的前提下，天花板不会很高。

对于稍微了解过一点计算机理论的人来说，op 所自豪的那些东西，其实甚至不值得过于提及。或者说，有良好的理论基础和编码训练的人，哪怕是用 java 这种东西都能写出让人为之赞美的艺术品。