(call/cc

Never say never

2018.11 Legacy of Plan 9 from Bell Labs

刚发现，Plan 9 from Bell Labs 6 位作者，4 位是现 Google 员工，全！都！还！在！写！代！码！

其实稍微仔细观察就能发现 Google 更多的 Plan 9 legacy, 不说显而易见的 Go, Google 所有资源都可以由 filepath 定位，很大一部分可以用统一的 File API 读取，还有 D 这样的一眼就能看出渊源的基础模块，然后一翻原始文档，哦 Rob Pike…

2016.11 时代

想想看，如果我的童年在克林顿的经济繁荣时期度过，911 的时候我还懵懂无知，青春叛逆期总统是个木讷、顽固，娱乐节目上总是以丑角出现的干瘪老头，三观形成的关键时期活在奥巴马和反越战学生领袖营造的和平与爱的政治正确泡泡中，那现在我也会有那种整个世界崩塌了的感觉。

2016.07 Ken Thompson在Go里把O_CREAT fix了

“I’d spell creat with an ‘e’.” — Ken Thompson

creat_with_e

Photo credit: @_rsc

害我打 O_CREAT 打习惯了这么多年，现在非要我改写 O_CREATE, 那么久了我还是写一次错一次。

坑人不带坑两次的好吗。

2015.11 总结一下 Facebook css-layout

css-layout 项目是 React native layout 计算的基础，实现了一个简板的 CSS Flexbox 计算，基本特性：

后两点的缺陷，在技术水准上看那确实是弱爆了。实现 percentage 很有必要，percentage 的麻烦之处是得根据 children 的最小长度反算一个 flow 需要的最小长度，以及不满足时的处理策略。文本 measure 这个底层不支持就没办法了，自己实现过的人就知道，这里面全是坑，只要有 percentange, 大部分情况下能绕开。

结论：如果没法在现有框架上加 percentage, 我就得开新坑了。

2015.11 Anti Idiomatic C++

Why Google Style Guide for C++ is a deal-breaker 是一篇对 Google C++ Style Guide 的辛辣批评。我得说，从 idiomatic C++ 的角度看，这些批评都很有道理，这点也得到 Bjarne Stroustrup 的确认。

但对日夜深陷焦油坑的工程师来说，关键问题并非他们是不是 idiomatic C++, 而是它到底能不能解决实际工程问题。Google 的 C++ style guide 实际上是改造 C++ 以适应它的工程环境需要的指南，每一条看似无理的指引（比如批评文章里所有的 1000% deal breaker）都有不得已的工程原因。最后，到改造 C++ 都没法满足需求的时候，他们发明了 Go.

当然也会有人觉得 Go 就是个 1000% deal breaker 啦。

2015.11 TensorFlow

微软盛产优美接口，谷歌擅长龌龊实现 —— 一句话点评。

2015.07 对 Medium 和简书感兴趣

作为一个爱阅读的人，我知道要想看到好内容，就必须要同时给写作者和读者一个好的环境，或者说生态系统。写作和阅读不是简单的生产和消费的关系，它需要有作者和读者间健康活跃的信息流动和创意激发。我认为传统的出版和他们在互联网世界的简单复制是低效的，也有自己的脑洞大开的思考.

我一年多前就有说，在 Hacker News, 乃至其他非科技非创业信息渠道，我都看到了越来越多的来自 Medium 的文章，看来 EV Williams 这次的创造又成了。这两天看见明显借鉴了 Medium 的「简书」（不，不是抄袭，不要一上来看见像就说人抄袭），有点意思，甚至已经做上了「打赏」功能。我想仔细地研究下这俩网站，看看这里面的门道。

2015.07 Markdown

我觉得那种功能繁多的Markdown编辑器是miss the point的：Markdown就是让人能用 纯文本 做出人看得舒服机器又能处理的格式来的啊。纯文本编辑器就是最合适的Markdown编辑器，任何输入文本的地方：邮件、Evernote, 代码注释，都应该直接写 Markdown 标记。

2015.06 Chromebook

最近我刚换上了一台新的 13 寸 Macbook Pro, 高配 i7 CPU, 16G 内存，这是我自 2009 年以来用过的最满意的 Macbook。但下班回到家，我的很大一部分时间仍是花在一台 200 刀的 11 寸 Chromebook 上。

强大、精致的 Macbook Pro, 和这台毫不起眼的塑料廉价货，是个很有趣的对比。开盖即用毫无延迟，从来不用担心电量问题，零系统维护成本，这些点确实连价格接近十倍的 Macbook Pro 都做得不如 Chromebook. 再加上摔来摔去毫不心疼（我的历任 Macbook 都被窝磕得面目全非），Chromebook 才是随时刷刷 Hacker News, 查查下厨房（一个吃货技术宅形象跃然纸上）的最佳工具。

Chromebook 的产品设计并不是在 PC 上做减法。个人电脑曾经是我们信息处理的中心，它必须强大，功能齐全，而它的延伸，从手机到数码相机，在功能上就只需专注一项。而到今天，这个中心变成了智能手机，这个小小的随身电脑发展成万能设备，于是其他的附属个人设备，反而只需专注一项了 —— 要看杂志看视频而手机屏幕永远不够大，那就有 tablet, 要看书，有 Kindle, 要做开发，做设计，你需要一台像 Macbook Pro 一样的工作站；而需要比手机更顺畅地看网页，回邮件，那就还是弄台 Chromebook 吧。

微软做过一系列黑Chromebook广告，基本的逻辑都是，Chromebook 干不了 PC 能干的哪些事，这就真的是关公战秦琼了。这也难怪他们做出像 Surface 这样不伦不类的东西 —— 作为手机的附属设备，大家都在走向专门化，你却反其道而行之搞个二合一，不失败还真有鬼了。

没错，强大完美如 Macbook Pro, 现在也只是手机的附属设备了。你没有一刻可以离开手机，却只有工作的时候需要打开电脑了。微信的各个桌面版本，就做了一个正确的设计。

2015.04 立此存照，Rust两则

呃…… 我只能说Rust是一门设计得不错的语言，可是它只是一个改头换面的 C++ 啊，这个世界太拥挤，有且只有一个 C++ 已经足够了。

Rust没能从C++中吸取教训。C++资源管理模型的致命问题不在于不安全（其实只要严格遵守纪律就不会出事，基本不用脑子），而在于对象ownership成为接口的一部分，暴露了内部实现，导致接口不一致和不稳定。最后，除非有超强的设计能力和可以随时call for refactor的全盘控制，你很难阻止一个C++项目 shared_ptr满天飞，也就是放弃治疗。而Rust大规模应用的后果估计也是Rc满天飞，它还好死不死为解决多核效率问题搞出了个Arc vs. Rc，不早早从根本上fix这个问题，以后有够Rust开发者罪受的。

2015.03 世上绝大部分限定都是自我设限

某大公司数据平台负责人出来创业了，还是做大数据。我说，实时交互式数据分析没有看起来这么难，能把这个点攻下来，能够脱颖而出。

他说，我之间在某大公司组织力量花四个月把 Impala 部署进来了，跑的也挺好，可问题是没人需要它，大家还是要线下分析做报表就足够了。

我知道某大公司的数据「分析」流程，产品经理提出一个数据需求，交给研发，然后研发写 SQL 或者脚本，实现需求，加报表，产品经理看报表。产品经理是不可能懂 SQL 的，也不屑于懂，研发是不关心业务数据的，他们还有功能要做有 bug 要修，没空关心。做个产品数据调研，来回扯皮，一个数据点搞几天，效率瓶颈压根不在查询引擎效率上，但大家也没觉得有什么不妥。

他说，我们初创公司，没那么多力量去攻新技术，我们先去满足现有用户需求。

世上绝大部分限定都是自我设限。

云端，科技

科技文明會自然地向高度專業和分工走，因為這通常更有效率。即使電力在長距離傳輸中損耗巨大，中心電廠加大規模電網仍然比自家弄個發電機有效。估計也就這三五年，堅持要本地計算和存儲能力就跟普通城市人家堅持要買台發電機一樣怪異，沒有無線信號跟停電一樣得算是意外事件。最終人們可能也會發現，把手機和車的電池越做越大是不經濟的，核電池之類也不是出路，真正的遠程電力傳輸可能可以取而代之。

人類會對”系統“愈發依賴，這個進程是不可逆的。之後的兩個可能走向，一是壟斷和獨裁必然產生，在1984的世界中，一個小事件引發的蝴蝶效應可能就能讓全人類滅亡。另一個可能是，整個系統互相依賴牽制，沒有任何一點能達到最高效率，但整體健壯可靠，生生不息。

— Yuheng