@Ricepig 不只是窗口管理器，compositing也是在dwm里完成的。所以微软一定是脑抽了，把compositing从内核态挪到用户态来实现，所以照你的说法，现在就只能死路一条了...

@palxex 很不幸Mir和Wayland一样依赖EGL，所以这里不存在你说的问题。

http://en.wikipedia.org/wiki/EGL_%28OpenGL%29

@Ricepig 试问dwm.exe为何物

@Ricepig 那照你这么说Windows NT现在这样子也是死路一条了...

因为Python是一门烂语言...

@wuyamoyun Canonical当年几乎是第一个跳出来说要支持Wayland的。

> The next major transition for Unity will be to deliver it on Wayland

> We’ll help GNOME and KDE with the transition, there’s no reason for them not to be there on day one either.

http://www.markshuttleworth.com/archives/551

现在不仅要自己搞Mir，还乱指责Wayland。

经常出来演示Unity能用Wayland的是Canonical，现在连Wayland是怎么回事都没搞清楚的也是Canonical。当初就不要信誓旦旦地说要支持Wayland了。

https://wiki.ubuntu.com/Wayland

@sqbing 开发Wayland的大部分都是X.Org开发者...

Canonical可是说过Unity会支持Wayland的。可是去年还在号称要用Wayland的。

但是现在看来Canonical连Wayland是怎么样的都没搞清楚就急着推出自己的Mir了

http://www.markshuttleworth.com/archives/551
http://www.phoronix.com/scan.php?page=article&item=ubuntu_wayland_postponed&num=1

因为他们不懂强类型弱类型和静态类型动态类型有啥区别

其实Python大部分时候是强类型语言，有那么几个角落有那么点弱类型

LZ短短一文竟然就毫无压力地黑掉了标题里的5个词啊，太惊人了

不同的二进制发行版选择不同的编译选项，打上了不同的patch，即便包格式统一了，包也不能真的通用 ... 光靠二进制包格式标准，我不觉得能有助于改善现状。

现在这一切已经太复杂了，想要统一估计得更复杂 ...

不如想想，为什么要发行版，为什么要二进制包？

为什么发行版要搞包管理，而每个语言还要搞自己的包管理。各搞一套也就算了，用的时候根本就是两套系统，信息都不统一的。

为什么这么多软件都非要发布目标架构的二进制，而不是中间代码，在最终运行的机器上再编译成目标架构的二进制。真的有这么多和指令集有关的代码么。

@Alex_L spreadsheet在这里可能不是非常恰当，但是这的确可以算是并发的。并发就是有很多相对独立的状态，他们之间相互影响。GUI和并发多少是有点关系。常见的GUI库都是一个大循环不停地回调，号称event-driven，但有一个明显的缺点，一个回调函数不能有耗时操作，不然整个窗口都会卡住，耗时操作怎么处理就变成一个难题了。你可以看看BeOS那种GUI处理风格。你会发现和Erlang的模型更接近。

> Unix管道机制难道也是并发？无非是把各模块组合起来使用的机制罢了

难道不是啊？对啊，处理并发就是要有一个把各模块组合起来使用的机制，通过不同高聚合、低耦合模块的组合来完成复杂任务罢了。OO就是这么点内容啊。被吹成了一个大hype，搞得好像不支持OO就不能很好解决问题了一样。


> Niall Dalton是谁？

我从这里抄来的，应该是Erlang邮件列表上一个人。Joe Armstrong在列表上问怎么样向Smalltalk程序员介绍Erlang。Niall Dalton就说了Erlang is Smalltalk as Alan Kay wanted it

http://www.esug.org/data/ESUG2006/pres/erlang-smalltalkconference.pdf

@Alex_L

> OO是把需要跟数据封装在一起的操作进行封装，没必要的还跟数据绑在一起就是有病了。

就是啊，现在大部分号称支持OO的语言就是有病啊，连Integer都要包一堆方法进去啊。再来展示他们高级的boxing/unboxing的技巧。Immutable的量都有方法明显就是病得不轻了啊。

GUI里并发天然多啊。并发是什么？并发就是有很多状态在同时变化，这些状态还相互关联，一个变了，还能引起很多其他状态变化。就类似Alan Kay的那个mini computer metaphor。就刚才说的spreadsheet，每个格子都有一个值，那就是它的当前状态，接着你去改变一个格子值的时候，别的格子如果定义了公式用到了这个格子的值，那也会相应变化，那就是改变了他们的状态，那就是大量并发啊。


> The large scale one was to find a better module scheme for complex systems involving hiding of details

Message Passing就是为了解决这个问题啊。你并不关心另外一个process内部状态是怎么变的，你把他当成一个黑盒，你发个消息过去就好了。那些把各种方法绑到类型里的语言，就是在意淫调用了一下这个方法就是把这个消息发过去了，结果另外一个object挂了，抛了个错，你也得跟着挂了，这也算封装？只有实现真正的消息机制，才算是封装。消息机制的原型就是Simula 67。OO和传统的过程式语言在概念上有啥区别，过程式语言只有一个过程在顺序执行，OO是有多个过程同时或者交替在执行。

> the small scale one was to find a more flexible version of assignment

Pattern Matching就是为了解决这个问题啊。你是希望写

{ok, Result} = do_something()

还是

errno, result = do_something()
if errno:
raise MyException

还是

try:
result = do_something()
except SomeUnexpectedError:
raise MyException


如果你去翻翻各种邮件列表，肯定会发现Alan Kay提到过最早的那个Smalltalk就是Pattern Matching + Message Passing。

最后，不得不引用一句

Erlang is Smalltalk as Alan Kay wanted it
- Niall Dalton

@Alex_L 真正的OO和Actor Model不完全是同一个东西，但大致上是一样的

OO提出来的时候，Alan Kay说的是，一个程序就相当于有很多mini computer同时在运行，他们之间通过消息相互通信，就好像以太网里的多台computer相互通信一样。他只是受Simula 67启发，有这么个思路而已。他还没去实现呢，到底怎么实现，还没定论呢。所以，才有了后面一系列Smalltalk语言。Smalltalk不是一种语言，Smalltalk是一系列语言。Smalltalk 72和Smalltalk 76完全是两种语言，虽然他们都叫Smalltalk。

Actor Model是Carl Hewitt把这类想法整理出来写了个形式化的定义，并且加入了capability。

等后来OO变成了buzzword，于是几乎所有人都不得不搞混了。假如你的语言不号称支持OO，连你自己都会觉得低人一等的。这要怪也得怪Alan Kay他们，他们后来公开的Smalltalk 80和OO真是一点关系都没有。

所谓对数据和操作的封装，根本就什么都不是。从Lisp角度看，这只不过是把(method x y)变成了x.method(y)。这种语法糖甚至在很多时候会降低代码复用。本来method可以用于多种类型，你把method和数据搞在一起，你需要在每种类型里重新定义一遍。从Erlang的角度看，这就是一个Poor man's pattern matching，只能匹配类型，Erlang的作者们根本不屑于承认他们实现了OO。你再想想，Design Pattern那本书完整叫啥："Design Patterns: Elements of Reusable Object-Oriented Software"。

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

图形界面革命是T-Square和Sketchpad。之前也有图形界面，但是真正向大家展示怎么样写一个图形界面能用来辅助完成工作的，就是这两个了。就相当于是1962年的鼠标，和1963年的平板了。Xerox PARC开始了PC革命，Smalltalk确实一种是为了把PC从军方的实验室里的各种GUI玩具带给广大屌丝们而设计的语言。GUI里，显然有很多并发。比如，你在一个输入框里输入了，就得再另外一个列表里显示出来，比如SpreadSheet，你在一格里填了个数，因为别的格子里有公式，所以它们的值也会变。你再想一想，Emacs里面就是各种Event-driven了，Tcl/Tk也是。node.js只是最近的hype而已。

http://en.wikipedia.org/wiki/T-Square_%28software%29
http://en.wikipedia.org/wiki/Sketchpad


这就是一个著名的anti pattern，想把在一种场景下有效的方法当成golden hammer推广到所有领域的时候。那个buzzword OO可以算是一个，event driven则是另外一个。

http://en.wikipedia.org/wiki/Golden_hammer

Erlang/OTP只不过是模式匹配，消息机制，语言级的抢占式调度，能把处理并发所需要的各种不同逻辑有效的组合起来解决问题。这就是真正实现了OO。根本达不到什么编程范式、软件工程的方法论这么的高度。

阿里云有啥要紧张的？连Google都害怕阿里云呢...

函数总是返回错误代码，由调用的一方去做模式匹配，不匹配说明是碰到了意外情况则抛错，抛错直接导致process crash掉。若无必要，绝不catch。

$ cat mymodule.erl
-module(mymodule).
-export([do_something/0]).

do_something() ->
{error, sorry}.

$ erl
Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:4:4] [async-threads:0] [kernel-poll:false]

Eshell V5.9.2 (abort with ^G)
1> c(mymodule).
{ok,mymodule}
2> {ok, Result} = mymodule:do_something().
** exception error: no match of right hand side value {error,sorry}
3> case mymodule:do_something() of
3> {ok, Result} ->
3> success;
3> {error, Reason} ->
3> failure
3> end.
failure
4>

第一，抛错是一种代价很高的操作，当且仅当发生意外的时候抛错。而如果没有抛错机制，意外情况处理起来很麻烦。
第二，从模式匹配的角度看，if/else, try/except 都是poor man's pattern match，其实你已经在用模式匹配了，只不过每次都自己人肉把模式匹配的逻辑翻译成 if/else, try/except，而且很多时候还很难处理好

很多人对Erlang有偏见，非要认为Erlang是函数式语言，程序员会不习惯。事实上，Erlang是模式匹配语言，模式匹配就是实现正确的错误处理机制的关键。Erlang的函数式特征仅仅是巧合，而不是故意要设计成这样的。Erlang的消息机制就已经是副作用了，已经不能算是纯函数式了。

在没有发生意外的时候就抛错和发生意外了还不抛错，都是不对的。非要说一种错误比另一种错误更不坏是很荒唐的。明明知道模式匹配才是正确的做法，而故意不提那也太赖皮了。恩，我就是怀疑Go的粉丝们在耍赖。

所以要用Erlang啊，模式匹配才是正解

这算什么事啊，一个天生码农，却去当了几年PM，发现很多程序员代码还不如自己写的好，就开始吐槽了。当别人指出他PM当的不好的地方的时候，他却说，你代码没我写的好，那就没资格说我PM当得不好。

@akann 你真觉得COBOL，FORTRAN什么的不算OOP语言？现实是

* BASIC
* COBOL
* CommonLisp
* Fortran
* Forth
* Matlab
* Perl
* PHP
* Prolog
* S/R
* PL/SQL

这些设计目标完全不同的语言都号称支持OOP，或者至少有一种实现号称支持OOP。当他们在说OOP的时候，他们其实指的是不同的东西，有时候是思路上，有时候是实现上。

当你在说OOP的时候，OOP就是那个buzzword，好像一个语言支持OOP就比别的语言高级了一点。你能说清楚什么算是OOP语言？难道你说的过程式语言和你说的OOP语言，真的有显著的区别么？

@akann 因为当OOP是个buzzword的时候，很多语言分别实现了不同的东西，他们都管那叫OOP。

可以认为，Smalltalk是一系列不同的语言，而不是一种语言。Smalltalk 80那个其实也和true OOP没啥关系。最初的时候，Smalltalk 7?(不知道到底是1还是2或者都是)是受Simula 67和PLANNER启发，设计出来的一种语言(好像也没真正实现过)，主要特性包括Pattern Matching，Message Passing以及类似后来被称作Actor Model的东西。Alan Kay管那叫实现了OO。他们还开发了另外多种Smalltalk。后来公开的Smalltalk 80就是其中的一种Smalltalk，Alan Kay在很长一段时间内都在鼓吹OO，于是很多人都以为公开出来的那个Smalltalk 80就实现了OO，而现在看上去是连Alan Kay自己在很长一段时间内都搞混了(说OO的时候Smalltalk就指最初的那个，说Smalltalk的时候Smalltalk就指Smalltalk 80了)...

Alan Kay一开始对OO的定义并不是很明确，只是在Simula 67的quasiparallel process的基础上进行改良，可以实现一种容易理解的，可以用来描述某些并发逻辑的模型。Simula 67的quasiparallel process按今天的说法就是coroutine啊。Simula 67里还实现了用于在quasiparallel process之间通信的队列什么的，已经有了一个比较简陋的。或者可以这么说，在1967年，gevent就已经被实现过一遍了。至于怎么改良，改良成什么样，只有一个大概的想法，也没搞清楚哪些是可行的，哪些是不可行的，有没有漏掉了什么。(http://propella.sakura.ne.jp/earlyHistoryST/EarlyHistoryST.html)

* Everything is an object
* Objects communicate by sending and receiving messages (in terms of objects)
* Objects have their own memory (in terms of objects)
* Every object is an instance of a class (which must be an object)
* The class holds the shared behavior for its instances (in the form of objects in a program list)
* To eval a program list, control is passed to the first object and the remainder is treated as its message

后来，Carl Hewitt在Simula 67和PLANNER的基础上提出了Actor Model的形式化定义。但是他的定义还引入了Capability，导致要完全实现非常困难，一直都没有比较好的实现，也就没有流行起来。后来他又提出了CSP，提供了几乎和Actor Model里的Capability等价的功能。这也就是后来的Newsqueak，Limbo，Stackless Python，Go，Rust这一系列语言所谓的并发模型。但是这就不能算OO了，OO的侧重点是Actor Model里的消息模型。

现在流行的语言里面，接近真正的OO的，也就只有Erlang了。如果你了解Erlang的模型了，你就不会觉得 @est 的想法有啥好奇怪的了。如果用我的话来不严格的总结一下的话，就是He who is not an Erlang fanboy, does not understand OO。