Actor 的模型为什么会被吹起来，你可以找英文维基的 History of the Actor Model 这个词条，下面有一梭子论文可以吃。

然后你可能逐渐会发现，他们讲的和你看到的东西差不多是两码事。这是因为一开始作为 model，纯粹要的就是 model of computation，而不是体系结构研究里的 model of computer，所以性能之类的预设情形下是不管的，要关心的就是“表达能力”。

就 model 本身来看，并发实际上是很被强调的，卖点之一就是 concurrent computation modeling。只是 actor model 并不只是要做基于其它 model 上扩充的理论，而是要完整地替代先前的理论，所以当然不只是并发，只不过把顺序的计算当作并发的特例而已。就发展过程的特色来看，还有就是强调指称语义(denotational semantics) ，不过这个你用不上。

注意这里的并发和一般开发者理解的概念有不小距离。理论上，并发是指表达计算作用(computational effect) 的程序的非确定性组合(nondeterministic composition) ，要解决的是如何应对本质上不可预测发生的现象（例如，接受用户的输入作为一种计算上的副作用）的抽象问题。而实际开发者理解的并发经常和多任务混淆，认为并发关心的是某个计算任务在“何时”“是否同时”“如何发挥计算资源”这样的具体实现下的具体性质，还经常和并行（确定性的计算渐进行为）混淆。这种偏差导致真正意义上的 model 本身的性质并不容易直接被利用。

顺便，上面有人提到的线程是抢占式多任务的主要实现方式，强调某些计算资源的独占性。协程是协作式多任务的一种实现。这些和并发其实没啥直接关系……硬说的话，任务调度策略本身还能扯上点关系。要回到模型，在 actor model 里扯 threading，显然就很不 pure 了。其实也有其它扩充既有设计实现多任务的替代方法（而且理论上显而易见更优越只是不足以使工业界广泛接受），只不过听起来没那么主流知道的人稍微少点而已。比如抢占式多任务用 engine （ timed-lambda ），协作式多任务可以直接用 continuation。

至于你现在看到的具体框架的实现吹的 model，已经是跟 OOP 互相扯皮了……要知道 OOP 根本就几个的像样的 model （比较著名的也就是 Luca Cardelli 的 sigma calculus，相当地脱离实际而且睁眼说瞎话吹简单），理论上对比根本没什么意义……苦口婆心连 thread of execution 都上了地 red herring 黑了半天 OOP，站得住脚的合理理由就是它黑的 class-based OOP 在这方面确实过于弱鸡这点罢了，但实际上 OOP 在这个问题上几乎弱鸡到是个其它不建议共享可变状态的阵营的都能干翻（比如纯 FP ），并没有体现出非 actor model 才能上位这点。（而且更讽刺的是，Alan Kay 等强调的“正版” OOP 实际上用的也就是 message passing。）

所以选择 actor model 很大程度还是 political 的问题了。

@Actrace SQL 名义上确实是“查询”（“ Q ”）语言，但规格上至少包含 DML/DDL/DCL。以查询为中心的 SQL 名义上是声明式语言，但实际上已经是大杂烩了。
实际实现野心更大，什么乱七八糟的功能都想掺和（很多所谓内置函数的干活附会到“查询”上也是可以的，但本质早就和 DB 无关了），给 DBA 偷懒以外就是给手贱不懂正确选型的开发喂屎而已。
“可扩展”的存储过程算是这种不切实际的鸡肋野心的进一步实现。半吊子 UI 能顶几个靠谱的 API 呢，谁用谁知道，是不是混了斯德哥尔摩综合症就难说了……

资源来源跟 Listen1 比起来如何。

当模型就是陈年渣渣了。论文？先补 Lambda: The Ultimate XXXXX 系列刷新三观。

> 存储过程没法进行版本控制-----凡是语言都能进行版本控制。
肤浅。控制到什么程度？“凡是语言”？给你一坨 Piet 代码你能 diff 得让人看？

> 你这种论调，只是把逻辑用另一种语言来实现而已。
废话。只是工程上能用的“另一种”语言想要比带所谓存储过程的语言实现此类需求能力更稀烂还是不太容易的。

> 必须带有子库。即子库+母库。而字母库 1，又和字母库 2 互联。形成分布式库。
前面的瞎眼论调先无视。整个生命周期都没要分布式的业务，照你这坨还应该没事瞎搞个分布式架构？这是什么精神？

> 2 感觉，存储过程，sql 难，反人类。不好调试，没执行记录。------这些是 [应用开发人员] 偏见， [库开发人员] 不这么看。
抛开实现是不难。但是[语言开发人员]就是要 diss 一坨不知本分还要跨领域碰瓷的 DSL 了，不服？

@v2overflow 醒醒，DBMS 不是 RDBMS，没空没历史遗产倒腾啥 SQL。

@mywaiting

我同意缩进在逻辑上更清楚，但这本质应该是 AST 层次上的结构化的表示；这和文本的、书面的、可打印的代码并不一定是一一对应的。否则，对齐也是毫无意义的了。

缩进检查的理论问题倒的确不是那么了然，不过副作用有个简单的表现：IndentationError 到底算是 syntactic error 还是 semantic error ？照一般的习惯，里外不是人。

Lambda 和 TCO 的问题是指出作为爹的 GvR 关于这些（工程上）简单的问题自己没干好活也没引导社区。

至于缺少 PTR/PTC 之类的保证作为缺陷，C/C++在更一般的情况下显然还更糟糕，stack overrun 直接 UB，而且一般实现多大会炸原则上不可预测，导致严格意义上就没多少程序能保证语言层面上可移植的。这不照用么……
Python 的基本做法是保证不会炸得莫名其妙，这起码是工程上更正确一些的。
Shadow stack 这里是解决可调试性问题（保留 stack trace ），对安全没有影响。Stack inspection 原则上也是兼容 PTC 的[1]。

缺少 PTC 导致一些程序（如 [2] Part III，某些 CPS 程序，某些依赖互递归的自动机）的直接实现无法被准确简单的表达，其变通就是人肉翻译成更底层（更类似机器语言口味）的代码。对高级语言用户来讲，这就是显然的不友好的限制。

[1] www2.ccs.neu.edu/racket/pubs/cf-toplas04.pdf
[2] www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf

@mywaiting 你觉得是你觉得，不表示别人觉得的就没问题了。

所谓的动态类型我不喷（反过来我还要喷所谓的“静态”本身，或者强调“静态”的 Robert Harper 流的扯蛋）所以略过。

限制缩进首先是对用户选择的冒犯。用户会缩进不表示语言设计者替用户选择就是道德上正当的，撑死这也就是一部分人的选择。加上 free form 和决定如何缩进一贯是历史传统上的用户权利，突然就收归 GvR 之流所有了？敢限制自然就得准备好被喷。

更进一步地，如 PEP-8 这样钦定缩进用空格的，我可以认为是分不清缩进和对齐程度的反智。（不过这是另一回事了——缩进用不用空格的显然不是 Python 独家问题。）

其次，限制缩进是对语言理论（形式系统意义上的“理论”，反映到工程上主要是语言 spec 的表现形式）的简单性的破坏。限制缩进的规则导致 parse 时就很难卸掉一个单独的 phase，而必须导致抽象泄漏；这也导致扩展 spec 派生其它语言的一些困难而损失语言 spec 的可用性。（说远点，钦定 phase 是我喷“静态”的根本理由，只不过这个和 Python 也没直接关系就是了。）

然后我给你追加一个 GvR 本身的反智（先不提这人搞 PL 设计的意义上不务正业很久了，什么 lambda 该限制几行的破事也瞎倒腾……）：连 proper tail recursion 和 tail call optimization 也分不清，不懂 shadow stack 还会借口阻碍 debug 瞎限制 stack depth，被人教育后还是“和尚念经老子不听”，这种水平的爹的语言敢通用？

关于这个 feature 设计大方向的“工程影响”问题，一个 lua 就够打脸咣咣响了。（虽然有违反 EWD 831 的另一个反智问题，也是屑。）

这些问题你都当“不限制你表达”的话，也是醉了。

@noli 大部分情况下打得过 Fortran 就够用了，不用考虑硬件问题。

关于 Python 容易入门的说法好像从来就没看到有正式的 PL 研究提过，所以可能只是大众迷因，和“ PHP 是最好的语言”类似。

实际具体点的原因大概是，和 C++之类的比起来，Python 看起来似乎是没那么坑，不需要之前有其它语言的丰富经验，于是“被简单”了。如果这些用户已经足够了解了其它语言，可能就不会有这样的想法。对不以 Python 也不以比 Python 明显复杂的语言作为入门的用户来讲，看样子也普遍不觉得 Python 简单。

Quora 上有人问“ Is Python an easy language to learn ”，下面有回答总结了不少，但其实多数是其它高级的动态语言也具备的。唯独“ designed to be English like ”，我看来是寅吃卯粮，因为实际上并不 English-like （真刻意 English-like 的设计都挺烂的，因为说实话 English 拿来应付表达算法之类的目的就不咋地……），这是把理解的复杂度扔给之后倒腾了。

还有就是 @secondwtq 暗示的从众。不过其实细讲起来 Python 并没有个好爹（ GvR 设计水平不咋地而且作为 dictator 都搞砸了不少事情），而且流行起来也相当偶然了。

@huskar 你是不是回错人了。你反驳的实际上是把职称、职务和职业混淆起来的 @icy37785。

另外，抠字眼的话，“工程师”是省级人事部门审核授予的工业技术类技术职称体系中的中级职称。而计算机技术与软件专业技术资格（水平）考试就有“程序员”这个初级资格名称。按国人部发[2003]39 号，

> 通过考试获得证书的人员，表明其已具备从事相应专业岗位工作的水平和能力，用人单位可根据工作需要从获得证书的人员中择优聘任相应专业技术职务（技术员、助理工程师、工程师、高级工程师）。

这显然是有法律效力的。虽然 @russian 的说法仍然很有问题，但本来作职业讲的“工程师”也不是这个意思，而你想把“工程师”作“头衔”讲反倒就有些问题了。所以是谁在一厢情愿？

@icy37785

有的人，如 @russian，自始至终把“工程师”当作职业而不是职务，虽然不能断言一点问题都没有，但起码逻辑能自洽。

而你，在 35L 首先提的“工种”，指的是职业分工；在 35L 之后提的“软件工程师”“机械工程师”仍然是职业，但“电气工程师”同时也是建筑工程系列的职称资格认证的头衔。

你在 53L 所谓“当然有假的”，指的只能是职称资格或者是职业资格这种有你所谓的“标准”可查证的内容，而非职业这个内涵。

你在 73L 引用的内容先不管已经跑题（回应关于所谓 engineering，和 engineer 的“标准”并没什么直接的联系），还原封不动照搬 [citation needed] 甚至 [improper synthesis?] 的质疑，也是很硬核的了。这坨内容，撑死能说明关于 software engineering 的不同观点的存在性，不知道你想拿来怎么论证谁关于 engineer 的观点不可靠？（要我说，这里 D.Knuth 的说法和条目主题毫无关系，是多余的； E.W. Dijkstra 的说法也欠缺专业性。条目质量堪忧，难以信服。）

所以到底是谁在偷换概念，还要人教语文？

@huskar 你是不是回错人了。你反驳的实际上是把职称、职务和职业混淆起来的 @icy37785。

另外，抠字眼的话，“工程师”是省级人事部门审核授予的工业技术类技术职称体系中的中级职称。而计算机技术与软件专业技术资格（水平）考试就有“程序员”这个初级资格名称。按国人部发[2003]39 号，

> 通过考试获得证书的人员，表明其已具备从事相应专业岗位工作的水平和能力，用人单位可根据工作需要从获得证书的人员中择优聘任相应专业技术职务（技术员、助理工程师、工程师、高级工程师）。

这显然是有法律效力的。虽然 @russian 的说法仍然很有问题，但本来作职业讲的“工程师”也不是这个意思，而你想把“工程师”作“头衔”讲反倒就有些问题了。所以是谁在一厢情愿？

@Takamine 一样得被 PEP-8 教做人。

@murmur
LZ 的意思显然是有指责领导不了解程序员的具体工作内容这个含义在。
上面有人也指出了，程序员不止一种。为什么技术工人要分类，程序员就分不得？
从这楼的许多回复来看，这个问题是一贯的。大部分人都对程序员的分工和工作内容了解得怕是欠缺得很。
这并不是只是领导的问题，是从上到下到处都有的问题。
提社会地位是因为和这些了解有直接的依赖。大众不了解工作，领导又没能力背书，自然不用指望什么社会地位，也就无所谓有多少实际意义的“上限”。
只不过，和这里不少人想得相反，程序员这方面其实是比技工要惨的就是了。
比如你说的“程序员太依靠硬件”，真的吗……？
顺便，我认识一些 Linux 运维（正式工），问到自己日常用什么 Linux 发行版，甚至有完全没听说过 Arch Linux 的……
须知工业基础不是死的，积累也得靠人。
相关职业人士都内卷到这个程度，你要是还认为这些虚名能当作立国之本，而且领导都没疑问的话，那只能说我输了。

@asensio 电费确实是个不大不小问题，不过本来就在（ build farm ）预算内的也就算了……

@murmur 你这又把当局承认和社会地位混起来了……
抛开 LZ 挞伐的“领导重视”的思路，加了“大国工匠”头衔又能说明啥呢。
上限？你还不如考虑为什么当前没有一个人出殡会享受 Mendeleev 或者 Dijkstra 万人空巷的待遇。
（于敏都没到这个上限了……）

@Vincex
其实现状来看总体还是挺蠢的。改个配置文件也能体现可编程性了。题图“其它必要操作”以及没什么开发能力的 IT 运维都能成为职业这点也能看出点问题。
如果是真的很有趣很酷的工作，结果应该是大部分其它工作都被自动完成了，没有多少凭兴趣插手的余地，也不会有 LZ 的问题了。

@Wincer
既然知道 GIL 是具体实现为主的锅了，也请注意 numpy 的可用性长期依赖具体的实现而不是 Python 语言。
虽然 LZ 少根筋，也别把弱类型这种民科概念堂皇地提出来。

@icy37785 你这明显是杠。一开始就拿受到主管部门限制的职业技术资格偷换职业的概念，接着补充的是什么鬼？能把观点稳定下再补充论据吗？
软件工程师资格证说起来中日韩互认，实际上市场认可度多少，有什么排面，自己清楚。（高级证不拿来挂靠能怎么变现？）

……大部分程序员还真没刘电工厉害。。。
考核的啥，devops ？