记得导出数据库，主题的设置都在里面

楼主这英文。。。

@tioover := 有什么问题？

因为你不写语法解析器

@HiVPS 阿里系，google，twitter。。。一般是上了规模的公司才用Java，玩具才用php。

RIP

@hyh1048576 我觉得我在说事实而已。大概我得说dropbox无论市场、商业、技术都跟淘宝是一个量级的才不算小看。哈哈，今天天气真好。

@hyh1048576 比商业比技术，reddit，dropbox加起来也比不过阿里系的一个淘宝。哎呀PGVS马云真是好口水贴。

@tioover 比技术也就算了，YC旗下那些公司加起来能超过阿里系么

一入糗百深似海

不需要但不反对用。事实上把IDE用好学习成本也挺高，既然是编程初学者，还是把主要精力放在学习编程上吧。我觉得也没太多必要折腾编辑器，vim用不来用gedit, sublimtext也没问题，emacs自带c语言补全。编辑器有个语法高亮就够了，自动补全都不是那么必要。编译、调试没图形界面又能有多麻烦，更何况现在好多人入门学的是解释性语言。

@bhuztez 你举的spreadsheet的例子跟并发一点关系都没有。你输入一个指CPU计算后再输出来，就这么简单。相比人的手速和反应，IO都太快，CPU不仅没并发，还得等待IO事件。不能理解个人计算机GUI跟并发有什么关系。当然进程级并发在GUI之前就有了。

> The large scale one was to find a better module scheme for complex systems involving hiding of details
Unix管道机制难道也是并发？无非是把各模块组合起来使用的机制罢了。Unix哲学是do one thint do it well,通过不同高聚合、低耦合模块的组合来完成复杂任务，而模块间用管道等IPC机制组合起来，某种程度也就是消息传递。

Niall Dalton是谁？

@bhuztez 插句闲聊，你对Erlang的狂热让人印象深刻。

@bhuztez

“OO提出来的时候...并且加入了capability。”
这些都没问题，我们的理解一致。

你批评OO的封装降低代码复用：“本来method可以用于多种类型，你把method和数据搞在一起，你需要在每种类型里重新定义一遍。”
我不是太理解这句话的意思，能举个栗子讲一下吗？我的理解是像迭代器这种东西可以用于多种类型，也不需要在每种类型里重定义啊。如果一个method能用于多种类型，必然能通过组合、继承等手段抽象出来；如果一个method需要在多种类型里定义，必然不能适用于多种类型，不关OO事。OO是把需要跟数据封装在一起的操作进行封装，没必要的还跟数据绑在一起就是有病了。

“GUI里，显然有很多并发。比如，你在一个输入框里输入了，就得再另外一个列表里显示出来，比如SpreadSheet，你在一格里填了个数，因为别的格子里有公式，所以它们的值也会变。”
输入框这个例子跟并发有什么关系？GUI里并发多在哪里？

“Erlang/OTP只不过是模式匹配，消息机制，语言级的抢占式调度，能把处理并发所需要的各种不同逻辑有效的组合起来解决问题。这就是真正实现了OO。”
模式匹配什么时候成OO标配了？语言级的抢占式调度跟OO有关系吗？你对"true OO"的理解还是解决并发问题。Alan Kay设计OO的动机：“Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether.”真的不是并发。OO跟Actor Model的关系是为解决不同问题用到了共同的思想。

编程范式就是人写程序的方式，方法论的潜台词是你不这么干也能出活，真心没到什么高度，至少不是你想的那种高度。

@bhuztez 你好像搞混了OO和Actor Model，虽然二者真的很像。

OO跟Actor Model解决的问题不同。OO是一种编程范式、软件工程的方法论，通过对数据和操作的封装提高代码复用性。Actor Model是一种计算模型，解决并发和分布式计算问题。

虽然Alan Kay在采访中提到Actor Model近似与OO中最好的那部分精华，可OO不是Actor Model。Smalltalk和OO概念不是为了解决并发而提出的，而是图形界面革命的产物。

@mytharcher JS中switch语句的写法继承自C，是陷阱还是缺陷在C语言中就饱受争议，能实现更复杂的控制结构同时也更易出错。

我觉得你可能只是觉得有转译这么一层东西不太舒服，就像当年汇编程序员看不惯用编译器的高级语言，编译型语言程序员看不惯用解释器的动态语言，C程序员至今认为真男人就要手动管理内存。

如果不是浏览器的限制，JS的事实标准地位和Eich设计JS时的仓促，我们本能在浏览器里使用更好的语言的。

->是来自Haskell
这篇文章暴露了楼主对Ruby, Haskell, Python完全不了解，对自己批判的CoffeeScript几乎停留在不了解状态（Coffee语法看下来不用半小时吧？），对自己熟悉的JavaScript也不怎么了解：JS因为语法糟糕被吐槽很多好吧。难道你只用过JS跟PHP？