最近看到线程和面向对象一些文章, 想法和疑惑

我一直在学 JS, 多线程和并发没有清晰的概念, 对函数式和 OO 觉得理所当然网上总是会有人发表的各种声音, 或许还相互冲突最后只能凭自己松散的根基去搜索, 询问和想象

出于个人对语言的理解, 我期待语言是清晰易用的, 其次才是强大最初从 Python 看 OO 觉得好复杂, 后来看基于原型的 OO, 才渐渐明白这里对象的概念基于原型链的 OO 通过 __proto__ 和 .bind() 或者 __index 和 setmetatable() 改变搜索变量的方式我相对喜欢原型链这种更直白的方式,

另外不太消化地看了下面的文章...

知乎上高人对比了类和原型, 并说原型的效率不如类: http://www.zhihu.com/question/20239354
还有 lich_ray 在博文里侃基于原型的 OO 和 lambda 的关系: http://lichray.iteye.com/blog/89241

无类语言从已有的 lambda 演算理论中寻找适合解释面向对象思想的部分。

我一般只是在 Node 和 jQuery 中享受 OO 带来的方便以致我觉 OO 的好处更多在于有一个类似表的结构, 将操作绑定到了对应的数据上边我在知乎上解释了问题, 但回答更让我觉得重点不在 OO 上.. http://www.zhihu.com/question/20405888 而且对于 OO 的态度, 我印象很深的说法是 http://www.zhihu.com/question/20275578

面向对象在 WIMP 的环境中是很必要也是很成功的。原因是 WIMP 环境需要重量的实现继承提供的重用， WIMP 的对象种类能很好的被单继承模拟，WIMP 的属性和类别容易区分。而面向对象扩展到 WIMP 之外的环境中就失败了

另外我在学习 MVC 框架时也积累这对于 OO 的困惑, 于是去知乎询问怎样才是纯粹的 OO, 结果反而没有完全信赖的回答 http://www.zhihu.com/question/20185591 这时自然想到去追溯更接近 Alan Kay 的一些说法来理解了 http://blog.csdn.net/turingbook/article/details/1873481

对我而言，面向对象程序设计只意味着消息发送（messaging），状态处理的局部保存、保护和隐藏（local retention and protection and hiding of state-process），还有一切东西的极端迟绑定（extreme late-binding of all things）。这些在Smalltalk和LISP中都可以实现。可能还有其他系统，但我不知道。

对象就像是生物学里的细胞，或者网络中的一台计算机，只能够通过消息来通信（因此消息概念出现很早，但是它在程序设计语言中实际可用却花了较长时间。）

而且来自权威的一些大神的声音反而让我更为困惑 http://www.infoq.com/cn/news/2010/07/objects-smalltalk-erlang

似乎认为Erlang“可能是唯一的面向对象语言。” 因为Erlang具备面向对象编程的三原则：基于消息传递机制，对象分离和多态。有一点倒是, 随着搜索, "Actor 模型"这个词多次出现在视野当中了 http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=3 Binstock: How do you view the Actor model? Kay: The first Smalltalk was presented at MIT, and Carl Hewitt and his folks, a few months later, wrote the first Actor paper. The difference between the two systems is that the Actor model retained more of what I thought were the good features of the object idea, whereas at PARC, we used Smalltalk to invent personal computing. It was actually a practical programming language as well as being interesting theoretically. I don't think there were too many practical systems done in Actors back then.

因为我只是写 JS 的基础, 所以只好继续从网上检索 OO 的信息关于 Actor 模型我找到了 JeffreyZhao 的博客, 很明白地, 那是关于并行的 http://blog.zhaojie.me/2009/05/a-simple-actor-model-implementation.html

Actor模型为并行而生 Actor模型的理念非常简单：天下万物皆为Actor，Actor之间通过发送消息进行通信。 Actor模型的执行方式有两个特点：

每个Actor，单线程地依次执行发送给它的消息。 2 .不同的Actor可以同时执行它们的消息。

也刚好 logickthing 给的关键词里我遇到一个打动甚至让我信服的说法: http://weibo.com/2701649502/yyigOxs4E

根据 OO 最初发明人的几篇重要论文来看, 对象是一种描述并发性的设施. 他们设计的各种 OO 特性都是为了支持现实世界的并发性, 而后人几乎把并发性给遗弃了，演变成为一种事物关系的模式, 进而夹缠于哲学问题.

到这里就有真的很震撼我的信息出现了, 因为纯函数的就是为了解决并发学 Haskell 我接看一些博文, 临时先找一篇说到的 http://blog.csdn.net/manyoo/article/details/5405252 编程语言因为不同线程共享状态, 同时修改发生冲突会出错, 因而出现了锁的概念更高级的 Clojure 是用事务内存, 在少见的冲突时才回滚重新修改, 也是为这个而函数式语言选择了不修改的状态, 有个 Erlang 和 Haskell, 平常写脚本我受不了纯函数, 后来这样明白这是为并行而设计的当我看到 OO 最初也是面对同一个问题, 顿时有些吃惊

在 Node 的介绍里我慢慢有点明白上边的说法 http://www.ibm.com/developerworks/cn/web/1201_wangqf_nodejs/

得益于基于事件驱动的编程模型，Node.js 使用单一的 Event loop 线程处理客户请求，将 I/O 操作分派至各异步处理模块，既解决了单线程模式下 I/O 阻塞的问题，又避免了多线程模式下资源分配及抢占的问题。

似乎在别的文章我看到了, 因为数据只在一个线程中能够被访问和修改那么不存在不同进程访问相同数据带来的冲突, 也就适用于并发而 JS 本身就是单线程, 明显就不会有不同进程破坏数据一致性的问题到这里关于 OO 我遇到的困惑总算能说清, (自然关于细节还要继续学...) 在很多框架里呈现的很整齐的对象封装, 那种对于对象过度的信赖也可以解释

从我的角度, 大概不成熟, 的看法, 我觉得 OO 并未在我扮演多正要的角色首先为了数据和操作排列有序, 我没需要的是 JSON 或者 Lua 中表的结构有了表, 从另一模块引用的代码清晰地绑定在对应的变量上边, 操作数据的方法也类似另外借助 __index 之类属性, 我们在需要时也能快速构造出此类结构关于 OO, 我主要是不想遇到代码就出现 class 之类强行设定我思路的结构作为还不是码农, 我期待的是代码清晰地展示大脑思考和代码运行的结构, 而不是框架的积习

在学 Node 过程中, 我花了相当长时间去适应带有 CPS 风格的回调传统同步代码, 比如 ret = prompt() 会阻塞进程, 然后将返回值传给 ret 在 Node 中 fs.readFile('name', 'utf8', cb) 就只有 undefined 这样的返回值了进而, 我试想在消息的世界当中, 同步代码的返回值将不再常用如果说一切写得极端了, 全部的颠覆.. 我只是觉得会比较有趣, 当然明显不实用

然后我看到了 CoolShell 上关于线程模型的思考 http://coolshell.cn/articles/4626.html 还有徐昊写的"对象已死?"的文章, http://www.infoq.com/cn/articles/object-have-dead 开始期待着线程概念早日被更高级的抽象所取代

coffee-js / languages

最近看到线程和面向对象一些文章, 想法和疑惑 #2