@johnnyb 感触特别深，现在每次用 pacman 都吓个半死，我就装一个 ghc/clang/nodejs … 咱需要整一个 root 吗？简直快受不了这些 Linux 包管理器了。
（也可能是我不会用）

这其实没有什么用，现在的重点是： El Capitan 卡是一种怎样的体验？

如果中间人攻击的话，似乎怎么整都没有用，所以我之前一个小网战直接 HTTPS 明文密码，到服务器端 bcrypt。不过现在感觉至少也要 hash 一下。

不过那个网站是真的超小超 ad hoc。

那不是标准库里的一个很简单的函数吗，自己定一个就好了。

成立一个民间组织，和餐馆合作，看到四肢健全的乞讨者就打电话喊人来，问祂包吃包住不给钱洗碗干不干，当然，住宿条件、吃的条件也不能很好，估计一下子就能筛走一大片。

不考虑相关法律及民众问题。

@ibloging 我汉语很差的，算了……

这个我很喜欢，摘抄一下：

>> Personally, I’m a big fan of simplicity and minimalism in programming language design. I think that smaller languages have the potential to be easier to implement, optimize, teach, debug and understand.

> After reading hundreds of blogs and articles about this or that programming language being supposedly "simple", sentences like the above have come to mean nothing.
> I wish a had a succinct meme to describe what actually happens in the real world around "simple" languages but the concepts are:
> If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild. The "informal" will include things like idioms, patterns, macros, code generators, industry practices, "utility" javascript libraries, etc.

原文的翻译：
>> 就个人而言，我比较崇尚简单和极简主义编程。我认为，较小的语言比较容易实现、优化、学习、调试和理解。

评论的翻译：
> 阅读了数百篇关于各式各样所谓简洁的语言的博客和文章（估计指论文）之后，上述的话对我来说毫无意义。
> 很可惜我不能找一个简明的俗语来描述现实中关于简洁的故事，其概念如下：
> 如果有一个「小」或者「简单」的正式的语言规范，也就代表着还有一个很大的非正式的语言在现实中存在。所谓「非正式」包括了设计模式（Java 躺枪）、宏（C 躺枪，Lisp 躺枪）、代码生成器（Haskell 躺枪[1]），工业实践，JavaScript 工具库（C++ 标准库躺枪），等等。

[1]：部分 Haskeller 表示 Template Haskell 是个不安全的扩展，不安全的扩展，能算 Haskell 吗？

我觉得这个总结的就很好了：你们是指望团队成员进行所谓学习，通过代码规范、代码审核、结对编程什么的来保证代码质量呢，还是相信微软的团队和 Anders Hejlsberg 帮你挑选完、集成在 C# 里的特性呢？至于什么 CoffeeScript，TypeScript，无非就是让一个 preprocesser 完成一个编译器本来就要完成的任务——自动化测试确保代码质量——而已。

不过我感觉 V2EX 主流的态度是宁可相信人的「主观能动性」，也不愿意用靠谱的语言及其编译器、相信业界的大牛，嗯，这个很有道理的。毕竟王垠曾经说过，不要迷信所谓大牛嘛！

上面那个我给的翻译里的「编辑器」是打错了，应该是「编译器」。

WebAssembly is essentially what Brendan Eich told us we didn’t really want or need: a bytecode format for the web. A somewhat more neutral platform for all compilers to target. As a compiler implementer, it still seems to me like it’s a bit of an unfortunate compromise: a way to retrofit a web-bytecode into JavaScript VMs. It’s going to take programs encoded as Abstract Syntax Trees (ASTs) as input, whereas GCC, clang, and other real-world compilers usually generate Control Flow Graphs (CFGs) at the output stage, not ASTs. Forcing compilers to convert CFGs back into ASTs seems like a decision made to simplify the job of WebAssembly VM implementers, at the expense of everyone else.

这是看不懂就不翻了还是觉得 ourjs 的读者只需要看看吐槽就好呢？

不对，这翻译的还有问题哈哈哈：
WebAssembly 基本上就是 Brendan Eich 所说的我们不想要也不需要的东西：Web 界的字节码——一个更加中性的平台，所有编辑器的目标。作为一个编译器实现者，我觉得将 Web 字节码重新塞回 JS VM 是一个愚蠢的妥协。VM 把 AST[1] 化的程序作为输入，而 GCC、Clang、和其他实用的编译器通常输出 CFG[2]，而不是 AST。强迫编译器把 CFG 转回 AST 看起来像是一个方便 WebAssembly VM 的实现者的决定，不过坑了其它所有人。

[1]: AST, Abstract Syntax Tree，抽象语法树
[2]: CFG, Control Flow Graphs

对比原翻译：
从本质上讲Brendan Eich告诉我们的WebAssembly，是希望将所有的编译器设立一个中立的编辑目标，我们真的不希望或需要为Web创建一种新的字节码格式或编译器实现，在我看来，这是一个有点不幸的妥协。


天哪，这都什么狗屁玩意，无法想象剩下的翻译里错了多少。我建议各位直接看原文好了：
http://pointersgonewild.com/2015/08/02/javascript-is-the-c-of-the-web/?utm_source=ourjs.com

HackerNews 的讨论，比这里的讨论有意义的多：
https://news.ycombinator.com/item?id=9995788

然后我再慢慢吐槽……不过我扫了一眼（还没有细看）HN 的讨论，似乎已经把我想吐槽的说出来了。

@JamesRuan
> 反例很容易举出来啊，去看看haskell的代码，几乎没有符号（很多还是自己造的运算符，比如>>=这种），可读性很高吗？反之，很多情况下，简洁的符号就可以提高可读性（支持运算符重载的一个作用）。

你能解释一下为什么你说 Haskell 没有符号，却同时说 Haskell 有很多自造的运算符吗？很多常用的代码里（又在黑 parser，逃）我看到的就是 Applicative Monad Arrow 满天飞啊，什么 a *> b <* c 看到萌死掉了。

可读性这个问题其实跟采取哪种方式没有关联，更主要还是看库的设计。就比如 Haskell 吧，它确实符号满天飞，很多初学者看到 Applicative 那套，肯定疯了，觉得故意炫技，不适合工程。可同时我们必须意识到，Haskell 的抽象概念比别的语言要多那么一点，符号虽然多了，但定义的很好，熟悉起来用着一样飞快。

类似的，用自然语言也是一个样子，库本身很重要。要是你遇到个风格自相矛盾的库，肯定会骂人。至于多打几个字，我真不觉得是大问题。

@Feiox TeX 是反语义化的代表？哈哈哈兄弟率直我喜欢。我觉得世界上最搞笑的一件事，就是 TeX 的宏系统没有对命令和文本有什么明显的区分，TeX 用户却经常标榜自己是样式与内容分离的典范，哈哈哈。我最喜欢黑 TeX了。

不过可悲的是竟然没有比 TeX 好很多的产品可以用。

一、忘记语言只是工具这种话。
二、学习 Haskell。

@sinxccc 我估计是题主干的，他说的跟文学编程没关系。

不对，为什么是「题主」，逃）

我不太清楚 TeX，但似乎只有核心部分是文学编程整的吧，XeTeX LuaTeX 什么的也是用那个 WEB 写的吗？

而且我觉得这种东西吧，其实是与现代的模块化理论背道而行的，所以估计没什么前途。