编程语言的随想

我突然在思考， 为什么oop这么流行， 什么样的抽象才是适合的抽象。
f(a, b, c, d, e)和(a, b, c, d, e).f()哪个更好？

let obj = new Ins(a, b, c, d, e);
是f(obj);更好还是obj.f()更好？

亦或者是f(a).f(b).f(c ).f(d).f(e)更好?

语言之所以称为语言， 我认为他更多的是为了接近人类的思维， 用每个程序员自己独一无二的思维去叙说一个故事。 虽是这样说， 但是人脑其实hold不住太过天马行空的想法， 以至于需要oop这种语法糖来协助编程。

我学过的绝大多数语言都会允许共有方法和某些集合的私有方法同时存在。 这至少可以反过来说明存在即合理， 我见过非常反对oop的程序员， 也见过喜欢oop的程序员。

一般来说， 每个人都会更适应自己的编程思维， 除非阅读到了非常优雅的编程范式。

人们大谈设计模式时候， 自然会对所有的应用场景有自己的理解， 其实这本就是一些经过总结的优雅的编程范式， 极富经验主义和实用主义。 而经过反馈调节， 他们也变得足够适合拓展， 适合模块化， 并投入了生产环境中。

当代码超过5000行的时候， 该如何hold住， 当代码超过5W行的时候， 该如何hold住， 当代码超过50w行呢？
此类问题还有当api接口超过500个， 该如何对接， 什么样程度的api才能满足上层的需要？如何衡量？
比如我觉得trilium那套js+label识别的api用起来很糟糕， 不够直观。

这些问题都偏感性， 以至于让人的思维变得浪漫起来， 远非无情的并行并发或者是异步同步啰里啰唆一大堆， 内存磁盘cpu加加加扩容扩容扩容这种。

我对程序员的建议是， 当你对实现不感到深恶痛绝之时, 不必纠结于move还是copy导致这个空间有没有浪费， 也不必纠结于哪里到底应该用哪个设计模式。 就像redux文档里写的那样， 当你不知道为什么要引入redux时候， 你并不需要引入他。 当然， 在你的角度， 当你不知道为什么要听我给的建议时候， 你也完全可以不理会我的建议。 但我会接着给出我的建议。

一直沿用自己落后的思维方式是古板的， 可一直纠结亦或是学习新的机制也会陷入迭代地狱。 这需要一个独属于每个人自己的平衡时间来归纳新知识与旧方法的特点， 不是两三天就会忘记的那种。

如果这种认知刻不进DNA里， 那想必也没有机会去体会函数套函数， 封装套封装， 一直套个百八十层然后再重构的毫无意义了。 写代码就像写诗， “生如夏花之绚烂，死如秋叶之静美”。 我认为这正是软件工程师所需要学会的对待语言的态度。