对不起.我也喜欢跳大神...

   晚上在风月群跟燕大师聊天. 大师说.聊聊未来各自的方向. 说到未来. 我说 未来可能会看<--深入理解计算机体系. 编译原理. sicp Functional programming tcp/ip-->然后就又被我扯到了fp(functional programming)上..  说到这 .我还是狠狠的站出来跳个大神吧..

   无疑未来是多核.并行的.

  

引用

Saito﹏<[e-mail]> 23:02:52
    我有个大胆的预测.. 未来 3~5年以内.. Java会持续萎缩.. 然后 jvm 群魔乱舞. 但是有一个将领. 那就是 Scala . .然后在处理 http请求上. 会有函数式语言冒出来. 毋庸置疑. 肯定是 Erlang .   仅限于互联网行业.. 像什么外包的crm 工作流什么的. 我不保证. 安安心心oo吧..

  

引用

回复暂时的常量(729381297) 23:06:25
    看结果没意思

    引用摘自 晚上 跟大师聊天.  拍脑袋想出来的. .大师觉得只有结果没意思..

    说说我自己的理解. 关于未来的web领域. 开发上无疑是往更"敏捷"方向发展. 快速开发成为一个标配..笨重的Java正在被web领域逐渐抛弃. 而web领域在做大了之后都会面临一个问题.服务器支撑不了这么多pv .这么多人跑上来服务器就要挂掉. twitter面临到了.Javaeye也面临到了.越来越多的公司都面临这个问题..所以肯定要想办法去解决. Twitter是用scala . 一些公司选择了Erlang .为什么 .. 其实FP功不可没..

    命令式编程的祖宗是图灵机. 图灵机是什么. 就想象成一个机器. 然后一个无限长的纸帯穿过机器.就行了. 图灵机所依赖的状态的判定以其达到正确的执行结果.而函数试语言的鼻祖lambda演算并不是一个具体的有一个实物可以想象的..但是后来 邱奇跟图灵还是发现其实他们做的是一个东西..这两个东西实际上是等价的..能力上等价证明了函数式编程能做出来的命令式语言也能做出来. 因为他们等价. 但是 . 实际上他们在哲学上是有差别的..

    未来是 面向多核的. 面向并发的. pure的函数式语言天生的没有"副作用"..导致他在开发的时候没有命令式语言大量的状态保存.在函数式编程的世界里. 只要我写定一个function .那这个function不管我传多少次相同的值进去.我所得到结果都是一样的.换句话说. 命令式语言实际上依靠的就是状态的变更来让程序达到想要的结果...本来纯的函数式语言里面根本就没有变量这一个概念..函数式语言的起源是lambda演算. lambda演算是什么. 就是 一个函数定义式跟一条变换规则. 所以最早的那批语言里面 像scheme 连for循环都没有.因为用递归就可以实现. 这也从侧面说明了为什么尾递归优化对于函数式语言至关重要.对于状态的变更其实函数式语言也是支持的..在不纯的函数式语言其实也可以 set!. 而纯的里面要想达到状态的变更. 一般有两个方法. 一个是通过递归(对还是递归).将返回值再作为参数传递. 而另一种就是利用Monad. 用T1大大的解释.要理解monad. 先把近世代数的群论 跟 范畴论 搞清楚. 对我这个数学专业的孩子来说. T1大大的文章也只是勉强读懂.. 暂时将 monad 归为引入副作用. 和保持函数式语言的纯洁性. 其他暂且不表.当然. 函数式编程也还是有缺点的. 那就是学习门槛有点高.以及程序本身可读性的质疑(但实际上我觉得这个不是问题.) 但带来的是什么?并发的良好支持..(完全可以甩开命令式语言几条街..命令式语言在并发上那么困难.究其根本还是"副作用"的关系.程序之间为了state. 不得不增加锁机制..来保证状态的变更顺序等等..).程序鲁棒性的提升. 伸缩性的良好提升.

   Erlang(ps: 跟我念 /air-lang/)采用的并发模型. 轻量级进程 各进程独享自己的内存空间. 通过消息传递的方式的 这种模型. 再加上Erlang本身成熟的OTP库.太合适了大型互联网公司了.. 你用命令式语言在里面搞并发.lock过来lock过去的.一会就把自己lock住了..想死的心都有了. ..也为难那么多大佬们写了那么多命令式语言多线程开发的书..  而scala(ps: 跟我念 /sgale/  如果你跟上面的Erlang都念错了的话. 那恭喜你. 跟我一个水平了.)由于是oo+fp的..采用了actor模型后在twitter上大放异彩. 说实话.我现在不肯定 oo + fp的方式会怎么样. 但是如果不做规范的话. 将来可能会在开发上有麻烦.  而ruby .说白了. 我暂时把他当作是Java的一种"敏捷"替代. 他提高了我们效率.让我们快乐编程. 但在思想上. 并没有跳出编程所谓的固定思维.

   最近. 越来越多的发现. 冒出来的命令式语言其实都参杂了很多的fp的东西. 从简单的闭包.到lambda表达式. 未来是混合编程的时代.是多核.并发的时代. 到底是糅合oo和fp的类scala的时代 . 还是oo 与 fp 继续分开的混合编程时代. 都值得我们期待. 无疑. fp会在未来占据越来越重要的位置. .

 

评论

57 楼 seen 2009-09-23  

我坦白 计算密集型轮不到我做 只能做IO密集

56 楼 coolspeed 2009-09-22  

昨夜山风空灵，我顿悟了。所谓函数式语言就是"映射语言"。跟printf()那种函数八杆子打不着。我被骗了。人家function的意思是“作用”的意思。都说软件业要卖service，意思确实还是软件行业是服务行业的意思。软件不可能是瞬生瞬灭的service。软件是server。想要服务就要有命令，哪需要那劳什子的映射。想fp都干些什么，负载均衡是映射，lisp曾用来干的所谓的AI——定理证明是映射（就是希尔伯特那帮人集合论里闭集合里的定理自推），还有数据库，想当年我就是被fp与SQL同构等那些小魔术骗得一愣一愣的。数据库又不是操作库，明显是映射，与sql同构了有什么了不起的。
我倒是给fp出个主意吧，不嫌麻烦，就写编译器吧，那才是你该干的事。
软件行业呢，既然咱卖的是服务，就老老实实的一条命令一条命令地垒server吧。
话说这潭水是多核搞浑的。本来命令式写得好好的，为了并行，不得不抬起头来左顾右盼邻居家fp是不是有啥招。确实，映射可以并行。但那顶个啥用，我们需要的是命令——祈使句。CPU厂商把电子逼到死路，光子还弄不出来，就把多核交付出来对付，根本就是胶着在一起的多台机器嘛。自从这个星球上有了第二个微生物，“人”与“人”之间便再也不可能没有交流障碍了。
在强人工智能出现之前，我怀疑通用计算机根本不可能自动并行化。因为我们还处于一条一条地教计算机怎么干活的阶段。是我们YY了，多核这趟车很难指望搭上便车。
多核与并行是不同的，GPU浮点渲染管线本就是并行的。以后的计算机能力提高要靠异构(GPU不是通用处理器，游戏编程就是异构的)以及重构(指的是硬件动态重构)了，本游戏coder专用的GPU也开被始其它专业程序描上了，但是通用程序想搭上这车，这个也够呛吧。。。。
说着说着都快把自己绕进去了。STM，学习了，现在似乎懂了，又似乎不懂。同意偶像观点，既然自动并行化不可行，普通程序员可能也没必要操并行这份心了吧。

update:
数字电路分组合逻辑电路和时序电路。组合逻辑电路是并行，但是时序电路是串行。于是VHDL（Ada的同门师弟，一种硬件描述语言）里面也有所谓的pure function和副作用函数。组合逻辑，包括累加器，都是靠映射去暴力实现的，并不是像机械计算机一样地在那里真正地累加。于是，发生了并行->串行->还想再并行的尴尬局面。再于是，开始掀开冯诺依曼机，绕过时序。

55 楼 Trustno1 2009-09-22  

Saito 写道

    其实这也是大牛们为啥都紧盯着paper不放的原因. Google不就是从paper中来的么..

    另推荐一下O'Reilly Open Source Convention(OSCON)的讨论精华.


   

引用

并发构造纵览
Ted Leung 一直是一位有趣的演讲者 — 他为动态编程语言社区做了许多工作，尤其是在 Python 方面。他的演讲详细讨论了多种并发方法；其中一些是大多数读者熟悉的，但是一些方法对于主流计算机科学课程和实践程序员来说相当深奥。Leung 列举了六七种并发模型 或范型。

大多数程序员最熟悉的并发模型是线程化。大家同样熟悉线程化的问题：锁冲突和死锁。在一般情况下，用锁实现的并行总是需要开发人员做大量显式的计划工作。其他方法虽然都有缺陷，但是大都支持更高层的抽象，避免显式地锁住资源。

一种并发方法是软件事务性内存，这在 Haskell 中已经比较普遍了。 这种方法按照与事务性数据库系统相似的方式对待内存，也就是操作保持原子性，在发生请求冲突时执行回滚和重试。 事务性内存可能导致重复计算，但是在操作冲突不多的情况下，开销仍然比锁机制低。

另一个模型是 Actor 模型，这在 Erlang 中尤其知名（但是 Leung 谨慎地指出 Actor 模型和 Erlang 的发展是相互独立的）。Actor 模型基本上是 “不共享任何东西” 体系结构，在向其他 Actor 发出请求时 Actor 总是传递自含的消息。在去年的 OSCON 上，我写过一份关于 Actor 的讲稿。

Leung 提到了 Linda 和 ParallelR 底层的元组空间模型，但是由于时间的限制，并未详细讨论。在这种模型中，任务按空间和时间分隔开，读和写也是分开的。

Leung 还提到了 Bill Ackerman 的 “数据流” 概念，这个概念支持声明式并发。这种方法的问题是，尽管它对问题进行划分，但是无法处理非确定性因素（也就是说，它只适合纯功能性语言）；如果需要处理真实的非确定性因素（比如输入和输出），就需要 Actor。

Leung 讨论的最后一种模型是持久化数据结构。这是一个不完整的模型；它不能解决所有并发问题。但是，它是一种良好的措施。这种模型很早就出现了，但是在最近一两年，由于在 Clojure 语言中的应用开始流行了。基本思想是所有数据结构都被保存（即不可变），通过建立副本表示各种修改。实现不可变性之后，与锁相关的所有问题就不存在了。并非每个数据结构都是稳定的，但是大多数广泛使用的数据结构都有变体，它们会保持对应的可变版本的 big-O 效率（关于 big-O 表示法的更多信息请参见 参考资料 中的链接）

。

    其实纵览下来. 最重要的有两种模型. 一种是Actor . 还有一种是没有详细介绍的底层的元组空间模型 .这种模型暂时不是很了解. 其他的模型应该还是有待进一步改善 或者 完善的..

除了数据流之外,绝大部分的模型其实还是currency的问题.并行这个东西跟编程设施没有什么具体的关系了,关键是算法和硬件设施.很多问题不是说你只要把串行程序原封不动地搬到thread里面去就能并行了,而是要对原来的问题从新设计算法。做惯上层应用开发的人都喜欢从直观的角度去设计算法。除了很简单的情况,这样做出来的算法,看上去是可以并行计算的。但是复杂度可能与串行相当甚至还要高。在并行这个行当里就这个就叫做naive algorithm.
还有很多问题有并行的解决方法,但是在现在的cpu和os架构上就没法做.比如一个问题单线程处理2毫秒,理论上可以分成1000份来做,但是你在cpu和os级别上就没法干,thread的线程切换和锁的消耗可能都比2毫秒要高.都需要通过一些特殊的硬件去完成,现在的GPU可以分担一些但是也很有限。所以有人说，真正关心性能的人都是自己设计硬件的。

至于tuplespace那个东西，基本上就是分布式计算的问题.在大尺度的并行上还是可以用的，但是我们有什么计算需要大尺度并行呢？寻找外星人，计算蛋白质?貌似都不是我们能干的东西。

一般来讲,留给应用程序开发层面解决的问题都是IO密集型的问题,计算密集型的问题都不太可能留给应用型的程序员去开发，他们不会干也干不好,他们最后应该看到的只是一个个library而已.

54 楼 Saito 2009-09-22  

    其实这也是大牛们为啥都紧盯着paper不放的原因. Google不就是从paper中来的么..

    另推荐一下O'Reilly Open Source Convention(OSCON)的讨论精华.


   

引用

并发构造纵览
Ted Leung 一直是一位有趣的演讲者 — 他为动态编程语言社区做了许多工作，尤其是在 Python 方面。他的演讲详细讨论了多种并发方法；其中一些是大多数读者熟悉的，但是一些方法对于主流计算机科学课程和实践程序员来说相当深奥。Leung 列举了六七种并发模型 或范型。

大多数程序员最熟悉的并发模型是线程化。大家同样熟悉线程化的问题：锁冲突和死锁。在一般情况下，用锁实现的并行总是需要开发人员做大量显式的计划工作。其他方法虽然都有缺陷，但是大都支持更高层的抽象，避免显式地锁住资源。

一种并发方法是软件事务性内存，这在 Haskell 中已经比较普遍了。 这种方法按照与事务性数据库系统相似的方式对待内存，也就是操作保持原子性，在发生请求冲突时执行回滚和重试。 事务性内存可能导致重复计算，但是在操作冲突不多的情况下，开销仍然比锁机制低。

另一个模型是 Actor 模型，这在 Erlang 中尤其知名（但是 Leung 谨慎地指出 Actor 模型和 Erlang 的发展是相互独立的）。Actor 模型基本上是 “不共享任何东西” 体系结构，在向其他 Actor 发出请求时 Actor 总是传递自含的消息。在去年的 OSCON 上，我写过一份关于 Actor 的讲稿。

Leung 提到了 Linda 和 ParallelR 底层的元组空间模型，但是由于时间的限制，并未详细讨论。在这种模型中，任务按空间和时间分隔开，读和写也是分开的。

Leung 还提到了 Bill Ackerman 的 “数据流” 概念，这个概念支持声明式并发。这种方法的问题是，尽管它对问题进行划分，但是无法处理非确定性因素（也就是说，它只适合纯功能性语言）；如果需要处理真实的非确定性因素（比如输入和输出），就需要 Actor。

Leung 讨论的最后一种模型是持久化数据结构。这是一个不完整的模型；它不能解决所有并发问题。但是，它是一种良好的措施。这种模型很早就出现了，但是在最近一两年，由于在 Clojure 语言中的应用开始流行了。基本思想是所有数据结构都被保存（即不可变），通过建立副本表示各种修改。实现不可变性之后，与锁相关的所有问题就不存在了。并非每个数据结构都是稳定的，但是大多数广泛使用的数据结构都有变体，它们会保持对应的可变版本的 big-O 效率（关于 big-O 表示法的更多信息请参见 参考资料 中的链接）

。

    其实纵览下来. 最重要的有两种模型. 一种是Actor . 还有一种是没有详细介绍的底层的元组空间模型 .这种模型暂时不是很了解. 其他的模型应该还是有待进一步改善 或者 完善的..

53 楼 night_stalker 2009-09-22  

其实巨头都养着些两群人：科学家和大骗子，战略指导也是他们制定的。
听科学家的没错，而且忽悠人的东西也少。

52 楼 lin_style 2009-09-22  

想得太简单了。 语言的需求绝对不是引领行业的标准。更别提什么函数式了(80年带就有的概念了)。语言的细节标准是左右不了的。
还是多关心关心大厂家的战略指导吧。JAVA带来的绝对是个主流的思想(但可能被斩杀)，平台化的编程微软千年之初就开始提倡，而且到目前铺垫得非常好。但这个还不是我讲的重点，cloud 的出现，让微软付之东流，虚拟存储，虚拟信息一步也没跟上。
多关心关心巨头的战略思想吧，关注语言细节是科研，想做战略的指导绝不是这些。

51 楼 coolspeed 2009-09-20  

中国这个行当的奇怪之处在于，卖的明明是山寨品，却不得不跟着国外的新技术走。是先天残缺的。要不就干脆像印度coder那样看得开。CPU, 编译器, ……不说了，通通都是国外的。如果是别的行当，用着D版的Matlab或者D版而又不明原理的VHDL compiler， 机械、建筑CAD，国外淘汰的流水线，包括科研，淘汰下来的实验设备，那会自然而然地怀有正常的山寨心态，不会觉得太分裂。开源的共.产主义在软件领域实现，这怎么看都是奇迹，难道是因为人天性喜欢编程所以不一定索要报酬？
中国的计科科研，（一锅烩吧：是些工程院院士，清华两院院长级别，剩下的也差不到哪儿去了），怎么搞什么都用java呀？太不神秘了吧，这经费还怎么好批呀？Ada不行怎么着也得cpp吧。你不买mac那算符合国情用度合理，你用xp怎么也得用正版吧？用D版也就算了，用原版呀，别是“臭名昭著”的番茄呀，用番茄也别在论文截图里露出来嘛。(这个没证据，像我这样的UI控会DIY掉XP第三方主题限制)
一颗平常心。

50 楼 iaimstar 2009-09-19  

1981年。。。

引用

鼠标的 Alto 和 Dorado 工作站、大型立式点阵显示屏、所见即所得（WYSIWYG）的文本编辑器、图形编辑器、面向对象的互动式编程环境与综合类库（class library）、局域网、激光打印机、电子邮件

真幸福啊。。。81年都还在看小人书呢。

49 楼 Trustno1 2009-09-19  

Saito 写道

Trustno1 写道

Elminster 写道

FP 粉渐渐有些太多了，不够小众装 13 了呀！考虑变身 FP 黑终极 BOSS 中 ……

话说你才发现这个事实么?本人已近脱离这个圈很久了。混程序员这个行当,要的就是"你们现在捣鼓的这些东西都是老子当年玩剩下的"气势压。

    希望不要脱离T1大大太远. 以至于以后我想说一句"你们现在捣鼓的这些东西都是老子当年玩剩下的"都没处说.

不要向我看齐,要向这些人看齐。

引用

PARC 是计算机科学界的圣地，我们常说（半开玩笑地），世界上最顶尖的 100 个计算机科学家中有 80 个在 PARC。我可以在办公室里随便就溜达进一些业界名人的办公室，比如艾伦·凯（PARC 学习研究部的负责人，今日许多用户介面上的创新都产生于此），查克·葛许可和约翰·沃诺克（二人后来联合创建了 Adobe），以及发明了 B-Trees 的艾迪·麦奎特。他们都花时间来回答我的问题，并不在乎提问者只是个长得像竹竿的古怪少年。学习研究部和 PARC 的其他地方，都充满了世界上最聪明和最有创造力的人。为什么还会有人想要离开？


1981 年中，我终于研究生毕业，但不确定我想要做什么。在 PARC 工作会令我梦想成真，而这个梦想已经萦绕了我三分之一的人生。但也许我应该去到「真实世界」 。PARC 远远超前于世界其他地方——我们有带鼠标的 Alto 和 Dorado 工作站、大型立式点阵显示屏、所见即所得（WYSIWYG）的文本编辑器、图形编辑器、面向对象的互动式编程环境与综合类库（class library）、局域网、激光打印机、电子邮件——如果在业内找个「正常」的工作，肯定会倒退。但通过与学习研究部的资深成员阿黛尔·戈尔德伯格，还有 我的好友蕾切尔·卢瑟福的谈话，我意识到我真的需要尝试一些新的东西——如果我不离开 PARC 这个舒适熟悉的环境，我可能会后悔。

48 楼 night_stalker 2009-09-19  

你们现在转的火星帖都是老子当年看剩下的 

47 楼 Saito 2009-09-19  

Trustno1 写道

Elminster 写道

FP 粉渐渐有些太多了，不够小众装 13 了呀！考虑变身 FP 黑终极 BOSS 中 ……

话说你才发现这个事实么?本人已近脱离这个圈很久了。混程序员这个行当,要的就是"你们现在捣鼓的这些东西都是老子当年玩剩下的"气势压。

    希望不要脱离T1大大太远. 以至于以后我想说一句"你们现在捣鼓的这些东西都是老子当年玩剩下的"都没处说.

46 楼 Trustno1 2009-09-19  

Elminster 写道

FP 粉渐渐有些太多了，不够小众装 13 了呀！考虑变身 FP 黑终极 BOSS 中 ……

话说你才发现这个事实么?本人已近脱离这个圈很久了。混程序员这个行当,要的就是"你们现在捣鼓的这些东西都是老子当年玩剩下的"气势压。

45 楼 coolspeed 2009-09-19  

potian 写道

现在还有几家很牛的美国公司只招Lisp程序员

不认为是该语言的工业竞争力，而是可以称为lisp programmer的人综合实力竞争力。
p.s.
program重音在第一音节，怎么m要双写呢？写惯了倒是自然而然。

44 楼 coolspeed 2009-09-19  

Elminster 写道

FP 粉渐渐有些太多了，不够小众装 13 了呀！考虑变身 FP 黑终极 BOSS 中 ……

fp现在还行吧。想开辟新阵地的去做异构计算好了。考虑到瓶颈在网络这边，吹语义网不错。
我倒是希望fp进入广泛实用阶段。
p.s.
fp黑终极boss是什么？

43 楼 Elminster 2009-09-19  

FP 粉渐渐有些太多了，不够小众装 13 了呀！考虑变身 FP 黑终极 BOSS 中 ……

42 楼 Teok 2009-09-17  

potian 写道

seen 写道

potian 写道

现在还有几家很牛的美国公司只招Lisp程序员

哪几家？

具体忘了，在一篇关于Lisp市场的文章中看到的，大概是做金融和生物软件的，看过它们的介绍，包括项目介绍，校园招聘计划什么，感觉非常牛（其中一家公司的网页上规定应聘者只能是几所世界上每个人都知道的学校，要不就不要投了之类的话）

我一个同学的公司也用lisp，他们是安防的，听他在全国也数一数二的吧。不知道是不是真的

41 楼 potian 2009-09-04  

seen 写道

potian 写道

现在还有几家很牛的美国公司只招Lisp程序员

哪几家？

具体忘了，在一篇关于Lisp市场的文章中看到的，大概是做金融和生物软件的，看过它们的介绍，包括项目介绍，校园招聘计划什么，感觉非常牛（其中一家公司的网页上规定应聘者只能是几所世界上每个人都知道的学校，要不就不要投了之类的话）

40 楼 seen 2009-09-04  

potian 写道

现在还有几家很牛的美国公司只招Lisp程序员

哪几家？

39 楼 potian 2009-09-04  

Saito 写道

   

Lisp之根源 写道

我认为目前为止只有两种真正干净利落, 始终如一的编程模式:C语言模式和Lisp语言模式.此二者就象两座高地, 在它们 中间是尤如沼泽的低地.随着计算机变得越来越强大,新开发的语言一直在坚定地 趋向于Lisp模式. 二十年来,开发新编程语言的一个流行的秘决是,取C语言的计 算模式,逐渐地往上加Lisp模式的特性,例如运行时类型和无用单元收集.

    我们的programming language是这种模式的话. 岂不是看透Lisp . 就看透了未来? .

不管是否事实，paul graham的文章确实让人心有戚戚

这家伙不但卖自己的程序卖得牛叉，现在的公司名字更加牛叉，投资的效益更加牛牛叉

说明眼光很毒呀

38 楼 potian 2009-09-04  

night_stalker 写道

有个 joke ：KGB 发现 NASA 用 lisp，因为一个特工在 NASA 偷了一张纸，确信是某个程序的最后一页，上面写着

))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))


类 C 语言的括号不比 lisp 少，只是一部分变成了大括号，还插入了很多换行，看起来就没这么夸张了。

其实写多了以后，很多括号就可以视而不见了