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

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

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

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

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

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

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

legacy 代码是无法保证代码质量和组织架构的吧。如果是用了那些已经被认定是糟糕做法的代码，或者是利用一些 bug 一样的写法的，应该是不存在「自动转换」的可能性。

没有很明确的区别。

外包公司里面的研发和科研机构里面的开发，哪个更有「价值」？

@yuwancumian27149 这个感觉不光是不欢而散还有小概率会吵起来

分清哪些是值得自己善待的人，哪些不值得如此对待，大概就好了。

@h0099 以及建议去 /chamber 里面开一个专门的讨论。

@h0099 那请您留一个可以长期使用的稳定联系方式，可以通过我留在 GitHub 的那个邮箱或者 zulip 或者别的社交软件留给我。

@h0099 我给你私发邮件了，如果你邮箱没改的话。

七年……有点可怕（

感觉不管是什么场合，把对方当成朋友随便聊聊就好了。如果彼此有感觉的话是可以慢慢发展成熟悉的关系的。

也没必要去伪装什么，和人相处的时候表现出真实的自己是最重要的。

npm 在这方面问题确实很大。

不过如果一个包的作者想放手不干了，哪怕这是非常流行的包，一般正确的做法是什么呢？大体上也不是所有的项目都有一个很成熟的治理方案，引入特别的治理方案对于基于爱好的开源社区不一定是好事吧（比如说自动关闭 issue 的 bot ）

感觉没什么新意。

不提编程语言一般都有泛型、lambda 之类的很好用的抽象工具，在代码里面进行修改，比如说给几百个函数加一个多余的参数，一行 regex 就能搞定的事情，那些 lowcode 不是要开启关闭几百个窗口拖拉几百个控件就是要多写一大堆 boilerplate 。

而且 lowcode 的产物基本上都千篇一律，光是想要定制外观需要额外花费的精力就远远超过使用通用编程语言和流行框架了。更不用提流程、校验等方面的深度定制。

完全是一个错误的方向。

感觉不如扩充硬盘…64G 内存真的用的上的场景很少吧，可能等换新机的时候会发现压根没用上。

我觉得很难理解。

一边非处不娶想要破女生的处一边又觉得不是处就脏了在我看来是究极的双标。

当然这年头大家都不觉得双标是什么问题。

所以也没什么好说的了。