@Livid 是不是应该放到推广节点 ...

@dangyuluo 可以改成 auto operator+(const Complex<U>& rhs) -> Complex<decltype(std::declval<T>()+std::declval<U>())> {

@lolizeppelin 那按照同样的逻辑，你也不应该用”能不能并发“这种”无法准确传递“的词啊 ...

还有另一个问题是 parallelism/concurrency 的区别应不应该是程序员的常识，也就是说 parallelism/concurrency 到底能不能”准确传递“
我个人是觉得一个合格的程序员是应该能够区分 concurrency 和 parallelism 的，虽然事实上很多人并不能做到——对于我来说，这只能说明他们暂时还不是合格的程序员，如果他们搞不明白，多学习一下就行了，随便 google 一下相关资料很多。我并不会因为这种原因就不用甚至混用这两个词（混用是比不用更大的恶）
或者说大家都想要所有的东西都很直白随便看看都能看懂，不用理解定义，不用纠结细节，甚至不用思考，任凭劣币驱逐良币，坚决贯彻落实 Worse is Better，我觉得像什么 C 啊 Golang 的忠实拥趸应该会很高兴

或者说，Python 程序员一般不能区分，Golang 程序员一般可以区分
毕竟 Rob Pike 做过一个 Talk 就叫 Concurrency is not Parallelism
查一下还能找到相关的讨论： https://news.ycombinator.com/item?id=9450016

楼主这问题确实没啥意义，不过 #11 的表述稍微有点问题，我尝试做个比喻：
你要给一个 2D 游戏做场景美术，游戏不仅仅是 2D 的，而且画风不太真实，类似于日本冻鳗。那么我是弄个 3D 模型再渲染成 2D 画风呢，还是直接画一张 2D 图呢，前者大概能比后者提升多少工作效率？

反正最后都是像素。
”理论上来说，你两个用哪个都能开发出性能一样的产品“ 理论上来说，在 Web 平台上，jQ 的性能天花板会比较高。当然这个不好说，毕竟都 jQ 了，不如直接 http://vanilla-js.com 性能最好

@lolizeppelin 怎么不应该纠结名词 ... 特定的名词在特定的上下文里有特定的意思，相近不等于相等。语言背后的含义当然是最重要的，但是不准确的语言无法准确表达意思

这个帖子的大多数内容其实都是由语言的问题引发的，从楼主的标题开始，就没有能准确地传达意思。其实大家（可能要排除发这贴之前的楼主 ...）都知道楼主标题要表达什么意思，毕竟是 Python 一个 well-known 的坑，但是大家也都在挑楼主”不是真正的多线程“语句上的毛病 ... 以及楼主说的”真正并发还是要靠多进程“ ... 从楼主的回复看楼主是明白一些（英文）名词的，只不过 map 到中文不大会，以及可能发帖的时候没太注意
这一切都恰好说明了把话从一开始说准，说对是非常重要的

我预感此楼可能要 @FrankHB ...

@sun1991 “目前为止还没有人因为买 intel 而被 fire 过”

@KENNHI FreeNAS 给你的意思基本就是，如果你想要违背 FreeNAS 的推荐做法，那么你最好不要用 FreeNAS

@no1xsyzy 对于只停留在语法层面的人不用讲什么 computation，只要 Homoiconicity 就可以了

@secondwtq 不过”对 partial application 友好“和 Python 的”support not only lists, tuples, but all sequences/iterables“其实有点点相通。

只要这一条就够了，因为主要目的是保证一致性。再多的规则用户是难以判断的。很多事情就是说起来漂亮，但是实际情况没这么简单，所以最后吵得什么”优美“应该看的是在各种复杂情况下有没有始终坚持十九项基本原则 ... 哦不是一套简单明确容易理解的规则

光 Zen of Python 就十九条了 ...

简单过了一下，挺民科的 ... 或者说挺 GvR 的吧
没啥营养，排版也不舒服就没仔细看

我来做的话会做成 join :: Show a => String -> List a -> String
纯从签名角度，join 是容器和 String 共有的行为，做进哪个里面都不合适
但是由于是两个参数，这就又有参数顺序问题，参数顺序问题和是 string.join(list) 还是 list.join(string) 本质上是一个问题
把 String 放在前面的原因是这样对 partial application 更友好（和 fmap 的参数顺序是一个道理），很方便能定义 joinBySpace = join " " 和 joinByComma = join ", " 之类的。
当然并不是说函数签名*就应该*以”对 partial application 友好“为原则而设计，我记得看到过相关的观点说这样很不自然什么的，但是如果编程环境中所有的函数都统一以”对 partial application 友好“为基本原则，那么至少参数顺序是*可预测的*，这种一致，没有 surprise 的特征比所谓的”合理“更重要
就好像显示输入设备的颜色问题，虽然很多终端设备的色域和色准很垃圾，但是即使不做印刷品，设计师也一定要在标准化且精确的颜色配置下工作，因为如果设计师统一了那起码还是有标准的，如果设计师都不统一，最后的结果完全无法预测

当然 Python 不搞 partial application 之类的幺蛾子所以就没有这么做的理由，”join() as a built-in function would support only specific data types“ 也挺扯淡的 ...

type 一般写成 ty

不能
好像现在不流行 mirrored usb sticks 了，流行 mirrored flash drives
反正我是随便找了个 SSD 做系统盘

共享文件目前不存在完美的方案，NFS 权限麻烦，SMB 是全平台支持，但是性能不好说，权限也挺麻烦（不过起码能 work ）

你们都远程了，房子谁买…

连牙膏的企业盘都 TLC 了，Macbook 这种玩具就别纠结了
不过貌似 HET 也没了 ...

环保主义者表示强烈抗议并订阅了 :)

iPad 可以让你的孩子更加成功
https://www.theverge.com/2019/11/13/20963166/apple-phil-schiller-google-chromebook-classroom-not-going-to-succeed/

楼主开店是副业？
看楼主买的书跟开店好像没啥关系（不会明年双十一真来道算法题吧

吃一堑长一智