A path to enlightenment in Programming Language Theory

https://steshaw.org/plt/

@Yiki 原来大家都选择 35 岁清退是因为本命年 ...

其实 DLang 大概是 Java 和 C# 之后各种挑战 C++ 的 PL 中比较特别的一个，很多核心成员都是 C++ 和 D 两边玩的，尤其看到 Scott Meyer 这家伙还以为 D 被 C++ 钦定了 ...
最扯淡的是自己还差点把自己搞成 Python

@weakish App 我一直都是读“啊啪啪”

当月 20 号发本月的工资 ...
刚来的时候只呆了半个月但是被打了一个月的工资一脸懵逼

@Tony042 这个兄弟的回复可以看下，这两天 MSFT 刚刚发布了 Windows Sandbox，应该算是官方解决方案

顺便这个大概能代表 WPS 官方姿态？ https://www.ifanr.com/app/1137948

@secondwtq 更正，s/C++/C#，C++ 和 Haskell 这种编译要慢若干倍

@likuku 你错了，写个 C，C++ 什么的根本不需要性能，前端才需要性能

问题很简单：电池没问题，Chrome 越来越垃圾，在 Chrome 上跑的东西也越来越垃圾

作为一个巧克力爱好者（只是喜欢味道奇怪的甜食，并非黑巧那种），我每个月都要买一点“韩国 CROWN 巧克力榛子威化饼干”

楼主说“极端音乐”我第一反应是极端金属 ...
参见 https://en.wikipedia.org/wiki/Extreme_metal

所以按照这个 definition，楼上推荐的什么 Iron Maiden 之类都不能算“极端” ...
你问我什么叫“极端” ... 抱歉我也不知道，准确来说我觉得对于我们这种随便听听的人来说，过于刻意的做这种区分，构建“鄙视链”确实很没意思 ...

不过标题我觉得有点用词不当，电子没听过，但是 Common Practice Period 的古典大概只能算小众，算不上极端

不过既然都开始折腾古典了，要不 Jazz 也来一点？

@echo1937 脉脉把从软件业的 EULA 一路传承下来的传统发扬到了极致，直接要权限不给通讯录就不能用，iOS 根本没有区别，反而由于 iOS 本身不是可编程的，不配称为“智能”手机的操作系统，伪造通讯录更麻烦

因为我联系人都在 Google 帐号里面，所以直接把 Google 帐号绑定删掉清联系人，然后照楼主的方法重新搞了一份 vcf，iOS 不能直接导入还得稍微 workaround 一下

然而最讽刺的是，我以不想卖朋友的信息为动机，折腾了半天，并没有办法避免通讯录里面有我的同事 /同学把我卖掉 ...

所以楼主最好搞个阿里小号之类的试一发？

哪需要 41 MB，只要不到 10MB 就足够卡到需要载入时强行 kill 进程，调试到半路强行 kill 进程，跑着跑着两个进程都需要强行 kill ...

看了前两段，这无非是顺便利用了“现在浏览器调试工具很不适合技术发展趋势”的缺陷而已

Google 和 Mozilla 等厂一方面鼓吹强行要在 Web 上做乱七八糟的应用，同时用 Web 技术做了自己的调试工具，结果拿来调试复杂应用的效果一塌糊涂，完美打了自己的脸

别说游戏，只要随便引几个稍微大点的 npm 包做个 bundle 就够卡死了

借地发点无关紧要的牢骚 ...

和什么 FP 或者 OOP 都没关系，楼主应该了解下 http://wiki.c2.com/?SufficientlySmartCompiler

看不到图，不过似乎可以看下这个 https://github.com/tgjones/gemini ？

用 Windows 只玩游戏的，VGA Passthrough 了解下？

个人意见：不知道楼主上没上过体系结构的课，我们有一部分是讲 IO 的，当然是硬件层面，先讲了 busy wait 模式，然后说这样会阻塞 CPU 不实用，然后讲了 interrupt 和 DMA 模式，这个是现代 CPU 一直在用的

而在学写 server 时（同样处理 IO 问题），会先学写单线程单请求的，然后是多线程每个线程一个请求的，然后是多路复用的

有没有发现区别 ... 硬件上处理 IO 根本就没有线程的概念，因为主流体系架构使用的 IO 控制机制压根就跟线程没关系（当然 interrupt handler 执行之前会触发 context switch，不过线程建立在此基础之上），用线程来处理 IO 问题的抽象是不合适且不必要的

你可以粗暴的认多路复用是系统提供给用户操作更底层 IO 处理机制的最低成本的一种抽象

@xuanwu 提到了一个有意思的例子：React 和 Vue，不谈技术问题，还是谈“开源”与“先发优势”的关系

产品 Y 开源有利于产品 Y 的公共社区的发展，这应该是被普遍接受的观点，现在做推理：

* React 以开源的形式发布，发布了之后大家觉得吼都去用，形成了一定的社区，过了两年同样开源的竞品 Vue 发布了——这是实际情况，我们假设 Vue 从 React 社区抢下的市场 = x
* React 没有开源，发布了之后大家觉得吼都去用，形成了一定的社区，过了两年开源的竞品 Vue 发布了—— Vue 此时有开源的优势，Vue 从 React 社区抢下的市场应该是 > x 的
* React 没有开源，发布了之后大家觉得吼都去用，形成了一定的社区，过了两年竞品 Vue 发布了，同样没有开源——这个 case 和开源没有关系，Vue 从 React 社区抢下的市场应该约等于 x

可见开源与否只在竞品同样开源与否的前提下有意义，非开源的产品，同样会有自己的先发优势和社区，两个同样开源的产品竞争，和两个同样非开源的产品竞争是一样的。