这个关于data的地位的问题，Alan Kay（就是因为Smalltalk拿图灵奖那位，面向对象 的编程的祖师爷）与Rich Hickey（就是发明Clojure的那个民科）还在hackernews上有一个争论(https://news. ycombinator.com/item?id=11945722)。前者认为"Data is a bad idea", 因为data总 是需要一个interpreter。后者认为Data是客观存在的，是第一位的，如何interpret是第二位的。搞计算机技术，要以第一位的东西为中心。
所谓抽象，其实无非是在数据上再堆数据（i.e. tag some existing data with type and other meta information)，那原有数据封起来干嘛啊，还是因为怕别人乱动。数 据如果都是immutable的，那别人也动不了，所以就不必要脱裤子放屁了，因为你早晚 还是要看里面的数据的。
【 在 hci (海螺子) 的大作中提到: 】 不封装就不能抽象了么？抽象不需要封装。 所谓抽象，其实无非是在数据上再堆数据（i.e. tag some existing data with type and other meta information)，那原有数据封起来干嘛啊，还是因为怕别人乱动。数 据如果都是immutable的，那别人也动不了，所以就不必要脱裤子放屁了，因为你早晚 还是要看里面的数据的。 现在OOP不是鼓励用interface了么？其实用interface，就是tag数据而已。
【 在 hci (海螺子) 的大作中提到: 】 C语言就是个打扮光鲜的汇编语言，现在都啥时代了，扯那些老黄历干嘛。我老写C为中 国人民解放军做贡献的时候，很多小孩可能还在穿开裆裤，可能不少都还没生出来。还 指针，Java啥的早就把指针都取消了，哪有指针给你玩。封装是数据随便乱动时代的解 决问题的一个办法，但是，现在人家都在搞immutable数据了，再扯封装就是迂腐了。 时代在变化，要跟上时代才能吃香喝辣。当然你现在还可以去写C，但就不要抱怨不能 吃香喝辣了。 封装保证了专职模块负责专项数据，即安全还有清楚OWNERSHIP。带来的开发效 率远比没有封装强。 Hate to break it to you but "immutable data" is simply myth. You can put some value type data in immutable state but not for real world complex data like a big server database as the real world is inherently mutable.
【 在 NeverLearn (24K golden bear) 的大作中提到: 】 封装保证了专职模块负责专项数据，即安全还有清楚OWNERSHIP。带来的开发效 率远比没有封装强。 Hate to break it to you but "immutable data" is simply myth. You can put some value type data in immutable state but not for real world complex data like a big server database as the real world is inherently mutable.
【 在 dracodoc (david) 的大作中提到: 】 不太清楚你说的“数据”是指什么。 R算function programming language john chambers 有几句话 Everything that exists in R is an object. Everything that happens in R is a function call. 你说的object sytem是指OO实现吗？R应该几乎所有东西都是copy on modify/write的 ，看这个讨论 http://stackoverflow.com/questions/15759117/what-exactly-is-copy-on-modify-semantics-in-r-and-where-is-the-canonical-source data.table不是，因为它专门避免copy来节省内存和提高性能。
这其实在分布式计算
已经用得很多了，各种逻辑可以变成数据结构在节点间传来传去。而Clojure社区现在
意识到，其实单机程序也可以这样写。一个逻辑，能用数据机构表达的，就用数据结构表达，这样更灵活。
这个关于data的地位的问题，Alan Kay（就是因为Smalltalk拿图灵奖那位，面向对象
的编程的祖师爷）与Rich
Hickey（就是发明Clojure的那个民科）还在hackernews上有一个争论(https://news.
ycombinator.com/item?id=11945722)。前者认为"Data is a bad idea", 因为data总
是需要一个interpreter。后者认为Data是客观存在的，是第一位的，如何interpret是第二位的。搞计算机技术，要以第一位的东西为中心。
显然，我是同意Rich Hickey的观点的。因为其实最终的interpreter，是在人的脑子里面。就算再多的type checking, proof, blah blah, 最后还是要人来决定这个程序的
结果是对还是不对。不要以为程序能搞定这个interpreter的问题。
还有一个支持Hickey观点的arugment，是从信息论的角度，就是“信息永远不会增多”的定理（https://en.wikipedia.org/wiki/Data_processing_inequality）。加个
interpreter不会增加任何信息。哈哈。
可惜OOP的祖师爷觉得Object应该成为这样的interpreter. 他举出的理想技术居然是一个人造的用来与外星人通话的语言。所以我觉得图灵奖得主和民科似乎换位了。哈哈。
No wonder OOP is doomed to fail. It's philosophically and mathematically
unsound.
不认为自己是搬砖的人都会比较痛苦。
但是，没有OOP，砖很难搬的动。
很难想象，如果没有继承，封装，多态，抽象这些特性，
如何去改动别人的代码，或者多个人做一个项目。
继承和封装都是不好的主意。继承其实是把世界强迫用树来模拟；如果数据是
immutable的，封装其实不必要。
多态的方式可以很多，OOP多态其实限制太大了，只能despatch by class，其实可以
dispatch by anything.
抽象是计算机科学的核心，没有什么计算机技术不是在玩抽象的游戏。但OOP基于名词
的抽象的限制太过了，一切都必须成为名词（object, class)，搞成了Kingdom of
Nouns （https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html）.而现实世界名词动词形容词啥都有。
如何改动别人的代码，如何多个人做一个项目？ 用数据啊。就像Internet一样，只要
知道了数据交换的协议，按协议规格编程就行了。这都是成熟的方法了，现在把它用在编程上，就行了，其实也不复杂。
计算机各个领域之间的相互借鉴，是很必要的。嗯。
现在各种语言乱飞，个个吹的天花乱坠，其实本质上并没对软件业产生变革性推进。
预测到未来软件界的主力来自于东南亚某国。
天才还有，比如linus，还有王银，那是可遇不可求。
继承是，三哥写了一个上千行的像屎样的class。不要改他的代码，否则他咬死你。继
承一下，override几个method，将就着用吧。
封装是，要三哥把所有的变量放到class，不要毒害环境。
抽象是，三哥好多天偷懒不出货，写个interface要他implement一下。
多态是，三哥可以随便瞎写，但得把我的interface实现。
没有这些手段，软件很难写。
降低熟练工人的门槛。
没有数据写毛code
一边是独门绝技 一边是每个部件上个螺丝 拧紧
而且对人这种脑内内存有限的生物来说, 封装内部结构是做抽象的基础
所谓抽象，其实无非是在数据上再堆数据（i.e. tag some existing data with type and other meta information)，那原有数据封起来干嘛啊，还是因为怕别人乱动。数
据如果都是immutable的，那别人也动不了，所以就不必要脱裤子放屁了，因为你早晚
还是要看里面的数据的。
现在OOP不是鼓励用interface了么？其实用interface，就是tag数据而已。
很多东西底层是一大坨messy细节, 封装打包完, 再tag几个high-level接口才能用.
函数式只有动词，都还是太原始了。
把你洗脑，弄成随时可替代的部分,然后进行重复劳动。
还不是整人吗。
当然了，用Lisp的话，函数其实也是数据。
OOP以为Object能搞定解释器，Haskell人们以为type checker能搞定解释器，其实都是大谬，自以为给数据加些条条框框似乎就给数据赋予了意义了，其实唯一的功能是他们说的“整人”。
用过C的人最怕指针出错。张三的指针出错指到李四的数据上。李四那边发现异
常还莫名其妙不知道咋回事，自己的代码查了半天也没找出原因。最后才明白
原来是张三的指针撒野搞乱了自己的数据，责任根本不在李四。HOHOHO
加封装就是要引入一种安全责任机制，专职代码掌控专项数据。出问题可以快
速锁定病源模块，这样做项目才有效率。甩C语言"李四纠张三的错"那种风格
几条街。反对封装的八成没吃过C语言的苦。
时代在变化，要跟上时代才能吃香喝辣。当然你现在还可以去写C，但就不要抱怨不能
吃香喝辣了。
哪有啥是“inherently mutable”的东西。你孤落寡闻了不是，append-only数据库都
有不少了，rethinkdb, datomic，这些都是用户很多的。Kafka这种系统， 也是append-only.
mutable是为了省硬件省钱，但增加了编程复杂性。现在硬件越来越不值钱，immutable的系统会越来越多。
NeverLearn说的广义上的，hci说的OOP上那种什么都要强制封入object的思想
Clojure不需要这些，别人就也不需要这些吧。
从程序角度，关键是减少不必要的耦合，把该相关的相关，不该相关的隔离。封装和抽象是实现的一种方式，复杂性是增加了，但是从人脑的角度看不见一些东西，不需要了解一些东西就可以放心使用，这是进步。的确这不一定在程序里做，但在C和java的条
件下有这个是实用的。
另外硬件不值钱这个说法也不完全，能够不在意硬件限制的应用越来越多，但同样有些需求增长速度永远大于你硬件进步的速度。
从内存到不限于内存
从单机到多机
这两个变化都需要计算模式的根本变化。单机，内存以内简单，那随时都有问题超过你单机和内存的限制。你用其它存储，用多机，总得用个不同的计算模式，总得限制你自己，多机始终不可能做到像个虚拟的单机一样。
函数又全是动词
有些概念是形容词副词，比如一些decorator
还有aspect
肯定是每个都有其用途
关键是必要的内聚，不必要的减少耦合，我觉得这两个概念比较精确。
能不耦合的不耦合，减少复杂度，减少相互影响。抽象是层次上减少可见信息，封装是加东西来减少可见信息。东西都更复杂了，但人可见的简单了。如果底下的没有做错，人只在上面操作是更好了。
但是必要的内聚实际避免不了。
函数式编程强调无副作用，但是现实生活中没有副作用你程序什么也干不了，打印显示都做不到，影响不了外界你就不存在。
MVC架构是个典型，实际上用户界面这里你无法避免一些耦合，硬分开最后还是要关联
起来。
许多耦合最后只能定义好接口把规矩定好，只考虑子集让问题简化一些。
再回头一看，OO的好处在于数据和代码内聚在一起，然后封装了，一切都是消息传递，不关心内部实现细节。数据代码的内聚就是合理的，互相局限在相关的范围内，问题都简单一些。
当然现实生活中往往没有那么理想的模型，需求再一变化，又是麻烦。那么对于某些问题，动词和数据的概念就可能更合适。
也就是说，有的问题适合用名词描述，可以用类的概念，有的适合用不同动词和数据，这不是很正常吗？
如果真的数据必须要自己解释，这样可以，不过有太多情况不是这种需求了。
是屁股决定脑袋，还是盛名之下，其实难副，还是只是时代造就了成就，不是全靠本人？
有时候，死得早也不是坏事。
这个行业好像不喜欢OOP。
改别人代码成为一个非常难受的擦屁股的事情。
非常之苦逼。
在F作用的过程中，输入X不能改。
这就是输入输出分离。
这是电工的活...
immutable不是说不能改东西，而是说，不在*原地*改东西。所谓改东西，其实是产生
一个新东西。在数据库上用，就是append only，在kafka这种东西上用，就叫
persistent queue.
真正在概念上类似的东西，是copy on write，就是不管改什么，都先copy一个，原来
的不变，在copy上面改。当然如果真copy的话，性能是会很差的。所以immutable数据
结构的技术难点就是如何让人在概念上觉得是copy了，但其实没有copy，至少没有全
copy。实现的办法就是所谓的structure sharing，就是用一个树来track改动，只是
copy改动的树的路径。上述的的算法，最早是Bagwell在2000年的一篇文章《Ideal
Hash Tree》提出的： https://infoscience.epfl.ch/record/64398/files/
idealhashtrees.pdf
Clojure和其他FP语言实现这类算法把它实用化，要在几年之后。所以immutable数据结构，不可能在C++/C#/Java早就有了。
你居然用银行账号做“inherently mutable”的例子，显然不知道这是immutable数据
的一个示范例子，算是immutable数据的killer app.
为什么？因为账目每一次改动，必须都记录在案，改动前的数字，改动后的数字，都必须记下来， 因为要被audit。银行为了在传统数据库上实现这个功能，需要花废很大的功夫，多花很多的钱。而immutable数据库可以免费提供这个功能，因为它们是append-only，改动不会把原来的数字给盖了。
你把变量和identity搞混淆了。identity是逻辑上的一个东西。实现一个逻辑上的东西及其变化，有两种实现办法，1.用一个变量。2.用一个指针来指向immutable的量。
这两种办法，在逻辑上是一样的。变量你懂， 我就不讲了。
用immutable的数据如何实现一个identity的变化？具体来说，如何实现一个帐户数目
的变化？简单，用指针啊。变化前，指向immutable数A，变化后，指向imutable数B，
就这么简单。所谓immutable数据结构，其实是在玩指针的游戏。明白了么？
至于同时操作一个帐户怎么做，简单，数据库Transaction怎么做的，这儿也同样的办
法。比如两个操作，同时来，其中一个可能要被roll back的，或者retry。这些与
mutable, immutable是没有关系的，两者做法一样，无非是一个是改数，一个是改指针指向。
solve race condition的。
我来回顾一下，尝试诊断一下你的思维过程。我在说OOP的封装在数据是immutable的情况下，会成为不必要的限制。你说没有封装就不能抽象了， 我说没有封装也能抽象。
然后你说immutable是const，readonly啥的小trick，不能解决race
condition.。这个跳跃就很奇怪了，如果你的论证试图是说mutable OOP能解决race
condition, immutable不能，那还情有可原，但你又不是在说这个。总之，你随意从一个问题跳跃到另一个完全无关的问题，说明你的思维方式很不严谨，不适合做技术工作。
稍微发挥一下。很多老中在技术工作中被认为表达能力不强，表面上说是英文不好。我个人观察，其实不是英文不好，而是思维方式不符合逻辑，其中文表达的能力也不强。我说的留美学生大多没文化的现象，可能与语言表达能力和思维方式都有关系。所以我说教育小孩，特别在早期，要重文轻理，否则问题很大。
我感觉像git。还有比特币，存变化。当然如果比特币既存变化又存当前结果就好了。
或者至少每月存一次结果。至少可以把几个月前的信息扔掉。比特币现在几百G，才那
么点人参与。
你又说没有所谓的"inherently mutable"，我就拿银行账户做反例，指出存取
账户是典型的"inherently mutable"操作。copy/append/"指针"等immutable
数据结构的小trick在这里没用。
象（identity）的属性的变化，这是两个不同的东西。前者是一个具体的计算机实现，而后者是一个功能需求。
如果你的“inherently mutable”是指一个对象的属性会发生变化，也就是指一个功能需求，那么，你提这个“inherently mutable”的东西是不能用来作为immutable数据
的反例的，因为immutable数据也是用来实现这种功能需求的一种方法。
如果你的“inherently mutable”是指mutable变量这个具体实现，那么你是可以提这
个来做反例。但是，你没有提出任何问题是mutable变量能解决，而immutable数据不能解决的。你提到的银行账号问题，这两个实现都有一样的问题，因此你的论证失败了。
我也是基于你的“inherently mutable”是指mutable变量的假设来说这句“没有什么
是inherently mutable的东西“的。我的意思是说，mutable的变量是现实世界中不存
在的东西，是人想出来的概念，然后用一种计算机实现来模拟的。如果你追根到底，会发现，就连计算机的mutable的变量，也是用一个地址存不同的东西（i.e. immutable value）来实现的，这与数学（人脑产物）上的变量不是一回事。
值本身都是immutable的，比如1， 就是1， 1不会自己变成其他2. 银行账号A，今天的value是1，明天是2，其本质，就是A其实是个地址，今天存1这个值，明天存2这个值。如果世界的本质就是这样，immutable数据就是把这个本质明显化，这样解决实际问题
编程更简单，很多问题，比如如何支持audit等，都不是问题；而mutable变量，想要模拟一个人为产生的假象，所以解决实际问题编程就更复杂，比如想要audit，那就得搞
一套复杂的机制。
而已。新的结果就意味着一个新的reference。
一个东西A，变化之后会产生一个新东西A'。 如果有别的部分的代码指向A，就还是指
向A，所谓immutable就是这个意思。不用担心一个东西在本部分代码不知情的情况下被另一部分代码给改了。如果你想要这个新东西A'，需要外显直接说要A'。
总之目的是把变化搞得很外显，而不像传统编程的变量，变化是隐含的。
作为独立的输入或者信号源吧？这个和simulink一摸一样
的物理属性如果变化了，它其实就是另一个东西了。至于人还是要把这个新东西要赋予一个跟以前一样的identity，那是人的主观认知上发生的事情，与客观物理世界无关。很多情况下，如果物理属性变化太大了，可能人主观上把两个东西赋予同一个identity都很困难，比如一个人如果作了变性手术，肯定会改名。
归根到底，identity是个主观概念。而编程序，说来说去还是在物理世界里操作，按物理世界的规则办，事情就要简单一些。
对比一下芝诺悖论，你这样实际是把变化全部静态化，说没有变化，只有前后不同的东西。
要说呢，变化也的确是一个人造出来的概念，需要时间，更需要认定一个事物在不同时间是同一个东西但又不同，才有变化概念。你可以采用不同的实现方式，不使用这种概念，但把mutable概念就否定，也有点过头。
作为编程语言要宣传新的计算模式，要强调它的优点，能解决的问题是很自然的，但不代表这是唯一正确的方式。
值也同样是人想出来的，最多有客观事实，但只有人去加工才变成值。
计算机执行程序时根据时钟去执行下一条指令，时钟跟你说的一个地址存不同东西不太一样吧。
它的实现有可能比你说的论文要早，不过我不清楚细节，只是乱猜。可能用的不同的实现方式。
举个例子，我做shiny界面的时候，发现很多时候你要实现对人来说比较自然，比较直
觉的操作在逻辑上是不清晰，复杂的。
用户直觉是历史发展出来的，或者纯粹就是为了用起来比较省事，逻辑上未必是清晰合理的。
需要你做一些看起来比较丑陋的东西然后让用户用起来比较简单。如果你坚持逻辑上简单清晰，用户用起来可能要麻烦。
当你的需求就要服从主观概念的时候，你当然就得按主观世界的规则办，你不能去跟用户说你的直觉逻辑不清晰，那不对。
在你的主观上，你还觉得是你，但那是另外一个需要模拟的问题。需要做的，应该是在上面的两个不同的你的表示的基础上，在用更多的数据来表示这两个东西在你的主观上，有相同的identity。
把主观和客观两者混淆，貌似简单了，其实给编程增加不必要的复杂性，因为没有反应出真实情况。
这不是哲学，而是计算机科学，因为我们在试图用计算机准确的模拟现实。
在一起来实现。
这个shortcut，在很多情况下，是够用的。但是，使用者必须要知道它是个shortcut，所以有其适用范围。
现在的问题是，绝大部分人不承认它是shortcut，而是认为mutable变量就是真实存在
的。这就没有什么合稀泥的说法能解决这个问题了，只能说，“你是错的”。
这其实是计算机科学解决问题的本质思路，就是，任何问题都靠增加更多的数据来解决，即所谓抽象。
这就是我的主要论点。
这就是为什么很多人一但用了FP，就再不愿意回去了，这种难易对比的体会是非常深切的。
事比较好。
物理学是对物理世界的一种模拟，是人的对世界的主观认识的一种。
计算机科学是对物理世界和主观世界的模拟，是另一种对世界的主观认识。
上面两种模拟可以相互借鉴，但是相互独立的。
我讨论的问题是，“东西有属性，属性会变”，这种观点，在计算机上如何实现的问题。我推荐的实现办法，是更符合计算机科学的对世界的主观认识的。至于物理学如何认识，不在讨论范围之内。
计算机科学的主要方法就是抽象，就是在数据上加更多数据，一切可以有表征的东西，都用数据来表征: “Solve any problem with an extra level of indirection"
不要以为物理学就是客观世界的本质，它只是人对客观世界的本质的某一方面的一种主观认识而已。
计算机科学可以对客观世界的本质有自己的不同的认识，我这是就事论事，因为我论的是计算机科学的事。扯到物理学才是扯得太远了。
你说的可能是R的object system的实现用copy on write吧？
immutable重要的是在*概念*上要copy on write，而且前后两个copy都是accessible的，相互独立，是两个不同的东西。实现上，实用的算法和数据结构是2000以后才开始出现的，现在也不时有新东西出来。
R并没有这样的概念吧。
但是现实上一个很大的困难一是操作系统call back之类的
东西。
二是自然语言描述的和现实世界的需求分析。
这些东西的命名和api定义什么的，不是stateless的。
最简单的一个例子。例如一个button的颜色。
这个颜色在白天是white,晚上是black.
Functional的想法的话，这个颜色是一个函数的return value.
后续因这个颜色引起的变化用函数的组合解决。
非functional的想法，这是个可变的变量。后续查这个变量
的值就好。这两种办法，我想不少人第一时间会
倾向于后者。
当然这些困难都可以通过中间层解析成functional 的
，然后加一层软件。但这个risk/reward只能是case by case
的看了。
Fp做数学物理模型，以及信号处理模型是天生一致的。
但是现实世界的很多问题，不像数学物理的方法那样，
追求的是回答。我们可以追求解决和克服。
换句话说，数学物理模型本质上，
问题和答案是分开的。
西方现代这个哲学的好处是容易scale up.西方科学的扩散和病毒是类似的。
但是我们东方或者西方后现代有别的哲学。问题和答案，不是可分的。
对问题，可以不追求解答，而是追求解决。回答并不是解决问题的单一路径，也不可能是单一路径。因为你一旦选定了
回答这个办法，约束就上来了。
问题和答案是一个时间内演进的共同体。问题解决后，
形成另一种逻辑。就好比历史的逻辑，战争的逻辑，
界面设计的逻辑等等。这些不是数学物理覆盖的。
myth.
这个话题我以前跟大家争论过多次了，就不重复了。两个观点：
1. 这是因人而异的。比如我自己，比如wdong的小孩，都觉得变量不容易理解。我不排除可能有人会觉得变量很好理解的。我假设这是两种不同的人。
2. 这是acquired taste. 大部分程序员都是学imperative programming出生的，学出
了bias。所以其实不是它更简单直观，而是更熟悉。
另外一个困难，需求分析的自然语言很多地方是非fp的。
人们很多时候想的是自动化一下重复操作，想到的是procedure,不是函数。
Acquired taste这个肯定有。我们电工普遍都是懂
输入输出隔离的。电路图是一块一块分开的。后面的
尽可能不影响前面。
我自己写程序都是尽可能输入输出隔离。
几种“语言”而已，不管是FP也好，还是狗P也好，都是个“特色”而已，把它们放那
么高，眼界啊。。。
要还是不要reference transpancy
这不是个小问题
procedure怎么不是函数了？函数不就是动词么，用来描述procedure不是很直接么。
那把人当作函数就可以了。不要当变量。
人就是一个输出嘛
正因为没有统一的理论，才可以争论嘛。都统一了，大家就只需要讨论学习心得了。
你以前没看到这个明确的理论，现在看到了吧？
这个颜色定义成变量，还是定义成一个函数的
按涨跌的输出呢？
定义成变量的好处是，
万一将来这个颜色将来不按数学规律变了。
也可以容纳。简单说，变量就是假设成可以不讲理随便变的
一个函数。混乱是肯定的。但是表达能力强。
说“一个人长了一岁，其实还是同一个人”，应该表达为：
(=（person-identity X) (person-identity (grow X)))
这样就没有任何信息丧失，完美用计算机表达了一切需要表达的东西。
如果一个函数是“不讲理随便变的”，其表达能力为零 <- 信息论。="" br="">
也好也不好。
mutable都有同样的毛病的，这能说明什么呢？如果你认为这就成了immutable不行的“反例”（你的用词），说明你逻辑思维能力不行。
在计算机上表示加满油的油箱，与空的油箱，必须要用两个不同的数据表征，这没有任何问题。你提这个来说明immutable是不对的，再次证明你思维有点乱。因为你主观上
觉得这是同一个油箱，与在计算机上需要把他们表示为两个不同的油箱，是没有关系的。我们在讨论计算机上如何表示更好。
变量的，函数内也没有状态一说，immutable的思路不能轻视。
从实践来讲。我多年前写的有的code因为是reference transpancy,避免过一次编译器
重大事故。我并不知道什么是fp.
所以我个人看法，凡是明确描述数学物理模型的
代码，尽量和数学定义的函数一致。这样避免自造轮子。
如果需要算法
变种，用别的办法lift up到高一层，不要两种函数混一起。
Alan Kay这种在研究院的，其实没啥实践经验，做的工作，往往是为求新而求新，不是出于真实需要。往往是先有个观点，然后做系统来验证，力图往下走，看能走多远。当然作研究这样无可厚非。
电脑发明者之一，在Atari, Apple都干过。怎么在你这儿变成学院派了。
下面是从维基节选
为了发展Dynabook, 艾伦甚至发明了Smalltalk编程语言，Smalltalk吸取了Simula的
class的概念，并发展出图形使用者界面（GUI）[2]，即是苹果麦金塔电脑的原型。
1970年，鲍勃·泰勒成立PARC研究中心，阿伦·凯成为第一个雇员，他建立学习研究工作组（LRC），并参与Alto计算机的开发。1972年，PARC发布了Smalltalk的第一个版本。1979年，凯邀请乔布斯、Teff Raskin 来到PARC参观，乔布斯对视窗图形用户界面印象深刻。
1983年，凯离开全录，担任Atari公司首席科学家兼副总裁。1984年，阿伦·凯加盟苹
果的ATG ( Advanced Technology Group )。1996年，阿伦·凯加入了迪斯尼公司，任
Imagineering公司的副总裁，开发Squeak软件。
R算function programming language
john chambers 有几句话
Everything that exists in R is an object.
Everything that happens in R is a function call.
你说的object sytem是指OO实现吗？R应该几乎所有东西都是copy on modify/write的
，看这个讨论http://stackoverflow.com/questions/15759117/what-exactly-is-copy-on-modify-semantics-in-r-and-where-is-the-canonical-source
data.table不是，因为它专门避免copy来节省内存和提高性能。
来也没用过啊，这还不是学院派还要怎么才算学院派？我觉得他们比大学教授还要学院派，起码大学教授还要看NSF，DARPA的需求，PARC是谁的需求都不需要看。不要太爽。可惜PARC这种学院派现在是再也不存在了，时代不同了。
Apple，哈哈，Jobs回来可是把整个研究院给cut了。当年我在研究院混的时候，可有不少同事是apple研究院逃来的，这些人都是Alan的手下。这些人的风格，与上面我对他
的描述是完全一致的。我可没说这是啥坏事，我自己在研究院混的时候的风格，也是这样的。哈哈。
在纯FP里面，一般编程不赋值。immutable数据，不能赋值。如果你没用过，可能想象
不出不能赋值怎么编程。哈哈。
R的作者后悔没干脆把R搞成Lisp来着，所以他有FP的倾向，但R不是FP的语言。
Lisp不一定是纯FP的，common lisp, scheme, 这些Lisp，大都还是基于赋值的编程，
不是FP为主的。数据还是mutable的。
Clojure是FP为主的，因为是immutable by default
大家都这样的话，是不是世界会更美好？
蛋的迹象。
For example, 古代拆行拆列重用内存。
在现代谁家的c矩阵求逆，改送进来的矩阵？
这不就是immutable嘛
这事情就是没人去做。
看过一点FP的东西，对于追求纯FP觉得有点偏离现实，没有副作用，打印都打印不了吧？好像也可以找些办法来实现，但是各种绕
有的领域纯FP的优点比较明显，所以用的也多一些。但这不是纯FP一定比非FP更优越，而是更适合问题。
我觉得纯FP还是有点限制太多。
腾一下也能做，至少差不多。