OP 如果搞得明白会在语言帖子里吵起来的都是些

1. 没有权限或能力控制选型
2. 搞不明白自己的系统需要什么特性
3. 只接触过两三种语言写过一两种范式

的人，就不会发这个帖子了



「为什么用 go 写 web 」跟「为什么用 js 写 arduino 」 是完全一致的问题，想想为什么后者没人吵

@JQSM
> 为什么要传承文化，为什么要记载先祖

为什么信奉历史虚无主义？

从宏观来讲，历史是无数小因果关系的多重积分，历史反映的是世界因果关系的全貌，如果反对历史存在，那么实际上是对因果关系和逻辑体系的否认和反对，这是轻而易举就可以驳斥的。

所以首先我们必须承认历史是客观存在的事实，且它会影响我们现在的一切思维和生存方式。

然后在此之上关于先祖的认知就很容易认同了。

@murmur 粤语有正音字，正音字与大众熟知的北方官话常用字一样有自己的演化路线，这些路线是历史的一部分，但不去研究或保存它就永久缺失了。

只要承认官话文字读音的演化有历史研究价值，那么诸如粤语和粤语正音字的读音文字演化就有同等的研究价值。

我就不讲语言文字演化背后的历史可以研究什么或者有什么价值了，https://www.bilibili.com/video/BV1xa411j7mC 这个 up 做的内容可窥一斑。


你可以先承认「特殊字词的组成方式是有历史价值的，但这些词的具体发音是无价值的」，然后我继续跟你辩论为什么发音也是有价值的。

@JQSM 家乡不是伪概念，国人抛弃先祖和土地永恒观根本就没多少年。有史可考的老祖先生活的地方就是家乡，祖先在家谱宗祠里世代记载着咱老家就是某某地，是客观史实，又不是「改变一下观念」就能抹除的。


「你不知道你家在哪是你爷爷没告诉你，我爷爷的爷爷的爷爷早就告诉我爷爷的爷爷告诉我爷爷告诉我咱家是哪了」

语言承载文化。

我反对去粤语化是因为粤语的发音词汇表达方式与大量独特的历史文化相关，粤语是仅有的，唯一的，某些历史存在的承载方式。


而我不反对语言统一化或丢弃某些局部方言是因为，大量「方言」仅仅是同一文化体系的，私有的、特化的分支，彼此之间没有什么不可取代性，没必要所有的分支都完整保留下去。

打游戏用音箱体验非常不好。如果不是因为体质原因不能接受耳机其实不太建议用音箱

> ，我的初恋和青春，我幻想的爱情与生活都破灭了

噢，理解了一切。

没啥好说的，轮到你了就忍着吧，只要不自杀不干扰另一个人的生活，那么旁人没有任何帮助可以提供。

M: class UserTable{};
V: class Layout{UserTable ut;};
C: for(UserTable t : data){ut->set(t);}

VM: class UserView{User[] rows_; @property User[] rows(){return rows_;}; @rows.setter void rows(User[] &rs){rows_=rs; render();}}

看完这个帖子我最大的感受是

原来「欣赏 geek 的说法」都是叶公好龙……

@foreverstandbyu pixel 的 5g 能用吗

同蹲一个推荐：

硬需求： 不可能含有「国产内置功能」的 rom ，gms ，wifi calling ， 移动

要刷机的请自降一档（因为国产解锁 bootloader 本身就有麻烦）

软需求：NFC （国内公交卡），轻便，相机

自从国内网速普遍提速后就再也没装过迅雷了

aria2 够用

@yeqizhang 中途终止→中止

中途停止，中止。

终止<=>terminate

@justNoBody 双向 merge 的诡异之处在于，这东西会受时序影响。两个 feature 分支的分岔点如果一样，可能不会出问题，但如果一前一后各自分岔，那么 A=>B=>C 与 B=>A=>C 的结果可能就不一样而且不符合预期了。

你也许没明白的是，双向 merge 会发生未产生冲突就丢代码的情况。

原因是更新（ new ）的节点(A)merge 了一个旧节点(B)再 merge 回去(B') 会使 B'认为「不存在(B~B)'期间提交历史」的版本更新（ newer ），从而丢弃(B~B')。这个情况是很难预期也不好发现的。

所以实践上应该禁止 feature2 去 merge dev ，它完全可以 rebase dev 把自己接到后面，此时解决冲突相当于相当于不断发生 dev[N],dev[N+1],feature2[N+1]的三路合并，由于 base 点在 dev[N]，所以不会丢失 dev[N]后的东西（不会认为 dev[N]前的版本更新(newer)），又因为 N 必定大于 feature1 与 dev 的分岔点（ feature1 已经接到 dev 上了），所以也不会丢失 feature1 上的东西。

-----

我看很多人在说解决冲突时误删了代码，然而并不是这么回事。更要命的是搞清并向每一个人说明原理实在是太难了。所以直接制定规则是最可靠科学的办法

1. 你自己没试过对自己有没有用，说明你不是在强行把自己的感受加给别人
2. 有两种实验结论，说明这东西很可能因而而异，但你又不想承认因人而异

那你就是想把一部分人的感受强加在另一部分人身上，然后这两部分人是什么感受，你自己都没亲自实践感受过……


不是，那你图啥？

https://www.jianshu.com/p/603186352605

严禁双向 merge. 3B 做了一个从其它分支 merge 的操作，万恶之源。


虽然
https://i.imgur.com/MooCOTd.png

但是还是强烈建议你们设定「严禁自己分支 merge 其它分支」的规则。
要临时合并其他人的工作只允许 rebase/cherry-pick ，

严禁双向 merge.

有没有一种可能：

@billytom
首先马车帆船出行完全可行，是个可供开拓的市场，只是开拓这个成本要耗费的精力和成本十分高昂，短时间内你熟悉的企业没有碰。

第二非智能手机直到今天也仍有需求，在购物网站上你也能很容易通过搜索条件真的找到这些产品，跟无法选择电 /油车的情况根本不一样

总而言之你举得两个类比都不恰当。

------

打车租车都是租赁机动车出行，租车理所当然地提供了品牌车型选项，而打车无论什么价位和服务品牌，都没有做垂直划分，反而是非常奇怪的。现在这些服务平台只聚合，聚合了资源又不针对性投放，属实搞不懂不做这个的原因。只能猜测是调研过不可能做得起来，成本或政策铁拳