本来就是：
1. 国内院线本来就喜欢多剪。第一硬伤。
2. 目前的 3D 也就够区分前后景。特写镜头区分鼻子和眼窝都不行。
3. 眼镜不舒服。还划眼镜。现在一幅镜子上千，没来由被 200 块的 3D 镜划了。

今天正式更新了一篇比較長的： http://techsingular.net
http://sipoint.wordpress.com

你不用寫一個完全的編譯器，只是一個簡單的 parser，大約四五條 BNF 語法，生成 AST 之後再從葉子節點開始求值。

HiDPI 的两大障碍是显卡性能和 app 的 resolution-independence。

RI 说来容易做起来难。一开始各大 OS 都想玩 abitrary factor。结果 app vendor 不配合。最后 Apple 搞了一个 @2x 方案才解决问题。

显卡性能仍然是瓶颈。rMBP 15' 是极限了。

我已经在 Twitter 及 facebook 上做了一周的 rMBP 广告了。

你推荐别人去 New York 人家未必想去。你到了 New York 发现那里的人都是想去 New York 的。

老人至少会把大小写用对。

括号的必要来自于无歧义的需求。你可以看看法律文本，那种繁复程度会让你发现编程语言并不是那么糟糕。

如果我有了车库，可能考虑装一台玩游戏。住公寓还是 MBP-only 吧。

轻度接触 rMBP 有三个月。正式使用一周。
文字非常清晰。对于 non-retina 的图片，是否像打了薄码，我不能认同。感觉像打了薄码的大多是把图片和周围清晰的文字或者其它 app 的元素比较。如果把同样的内容和一台 non-retina MBP 放到一起比较，根本看不出二者的明显优劣。

Touch 的不要买，体验垃圾。

App Store 哪里有什么「官方」充值？都是各家银行自己实现的。用招商银行就可以用 Safari。

@muxi 其实我觉得大规模项目还是用静态类型语言做比较好。不过，写软件至少要写两遍，第一遍是把自己的想法快速的落到 code 上，第二遍是把 code 改成别人能看懂的。动态语言适合第一步，静态语言适合第二步。

不过当今软件开发的难点是：动态语言的 code 不是那么容易就能改写成静态语言的。所以我们都在凑合：要么爽在第一步，但是项目越大越发愁；要么慢在第一步，但是项目大了不会失控。不好说 Lua 完全解决了这个问题，但是我觉得它的 C API 至少向正确的方向走了一步。

Go 是静态语言，它也是用来更好的完成第二步的。至于第一步的衔接如何我不太清楚。

@adspe Lua 不是最快的。不过它有一个冠军。Lua 算是用 ANSI C 实现的最快的 VM。其它 VM/JIT 多少要用到一些编译器扩展或者汇编。所以在高度跨平台的项目中 Lua 是不错的。而且在使用编译器扩展和汇编的前提下，LuaJIT 是非常快的实现。

我也不想说 Lua 能包打天下，只是说明各种语言它们的流行度的来源。比如 JavaScript，它的语言本身设计很差（相对的，当然和编译语言相比要轻量），流行度主要来自 browser 环境的成熟度（node.js 也是借用了这一点）。

了解了渊源，大家可以自行判断前景。

@BigZ 所以呢？Lua 没有这些优点吗？Lua 诞生了多少年？而且它是从哪个国家诞生的？以 Lua 的年龄和发源地能取得今天的流行度，不能说明一些问题吗？

@clino 所以呢？难道技术好反而变成不能胜出的充分条件了？我列出 Lua 的优势，当然是在各种 context 下考虑的。其中 non-browser 环境下可以说 JavaScript 没有什么显著优势。

@adspe

JavaScript 的优势在于在 browser 上的成熟度（Lua 有以 JS 为目标的 VM 可以运行在 browser 上，不过成熟度自然没有 native JS 高）。

从语言角度说，JS 有的功能和 expressiveness，Lua 全都有，而且是用更 elegant 的方式设计和实现的。能嵌入到任何 app 中（Lua VM 没有 ANSI C 之外的东西，没有太多的宏，没有全局变量，不会劫持 message-loop 和 main()，所以完全不会污染现有代码）。

孰强孰劣？

@smilebaby Lua 的 prototype-based OO 比 JavaScript 实现的更简洁，但功能相当甚至更强。在 Lua 里，只要把所有资源置于 GC 之下（写好 __gc metamethod），lua_error() 就是 exception。而且对于支持 multi-return-value 的语言来说，exception 不是什么必要的东西，甚至不是什么好东西（Go 语言也同意这个观点）。