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

   晚上在风月群跟燕大师聊天. 大师说.聊聊未来各自的方向. 说到未来. 我说 未来可能会看<--深入理解计算机体系. 编译原理. 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会在未来占据越来越重要的位置. .

 

评论

37 楼 iaimstar 2009-09-04  

这个括号 好惊艳

36 楼 night_stalker 2009-09-04  

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

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


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

35 楼 RednaxelaFX 2009-09-04  

来跑题 =v=
.NET的CLR里的第一个GC是用Common Lisp写了原型之后用一个翻译器全自动转换成C的

34 楼 potian 2009-09-04  

coolspeed 写道

当年不是CPU oriented，而是computer oriented的C出现。数学上利落的lisp出现。后来人们嫌C麻烦，向着不同方向离开C，其实你说能离谁更近，无非lisp。非此，语言要往哪儿建设呢。
lisp胜在什么都不说，不会“言多必失”。缺点也是什么都不说，都得你说。每个人写的lisp都是它自己的语言括展，都是自己的personal lisp。也就没有了lisp。人们就倾向于膜拜不存在的东西——lisp。

按你这么说世界上第一个网上商店不存在，然后美国航天航空局远程调试、控制的太空飞行器都素空气？

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

33 楼 coolspeed 2009-09-04  

当年不是CPU oriented，而是computer oriented的C出现。数学上利落的lisp出现。后来人们嫌C麻烦，向着不同方向离开C，其实你说能离谁更近，无非lisp。非此，语言要往哪儿建设呢。
lisp胜在什么都不说，不会“言多必失”。缺点也是什么都不说，都得你说。每个人写的lisp都是它自己的语言括展，都是自己的personal lisp。也就没有了lisp。人们就倾向于膜拜不存在的东西——lisp。

32 楼 Saito 2009-09-03  

RednaxelaFX 写道

Saito 写道

   

Lisp之根源 写道

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

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

可以参照这里和这里 XD

    很和谐啊.XDD  

    Greenspun's Tenth Rule
    Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

    Morris's Corollary
    Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp including Common Lisp.

    Prolog follow-up
    Any sufficiently complicated LISP program is going to contain a slow implementation of half of Prolog.

    Erlang follow-up
    Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.

    Generalization
    Any sufficiently complicated platform contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a functional programming language.

    Saito's Corollary
    Any sufficiently complicated platform contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a functional programming language including functional programming language.
    

31 楼 RednaxelaFX 2009-09-03  

Saito 写道

   

Lisp之根源 写道

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

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

可以参照这里和这里 XD

30 楼 Saito 2009-09-03  

   

Lisp之根源 写道

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

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

29 楼 Trustno1 2009-09-03  

Saito 写道

night_stalker 写道

Trustno1 写道

赋值既IO,IO既通信,通信既时序,此乃命令式语言的不传之密.

真是奇妙 …… 可惜小波分析的课没去上过 ……

Saito 写道

night_stalker 写道

不涉及副作用的代码，没有时间因子，说玄点就是不受因果律限制，可以编译期运行，把调用替换成结果，也就是可以做最大限度的优化。

pure FP 便是从语法上区分了副作用（当然语法上不区分也有可能做这种优化，只是不好做）。

百度百科!!! 写道

辨证唯物主义的因果律：认为任意宇宙状态都是其前宇宙状态积累的结果。任意运动状态均是其前运动状态积累的结果。具有最为广泛的普遍性。

    话说我长这么大都是由以前一直在吃的这个状态累积的结果..  XDD

- - 我讲多错多，扯淡起来受无限流影响，当 joke 看就行了

    我小波分析倒是去上了. 除了听了第一节课老师讲了讲小波分析的历史. 到第二节课过渡到傅里叶变换的时候. 我就彻底昏睡过去了.. 话说比数学分析是难多了.. 基本不在一个难度次元上..

小波,是难了一些要学一些复分析,当然你不去搞测度那套东西复分析也不是很难.DFT其实没啥难的，就是高数加上中学里的三角函数运算而已.

28 楼 Trustno1 2009-09-03  

night_stalker 写道

Trustno1 写道

赋值既IO,IO既通信,通信既时序,此乃命令式语言的不传之密.

真是奇妙 …… 可惜小波分析的课没去上过 ……

这个蛋,应该怎么扯法?

27 楼 coolspeed 2009-09-03  

Saito 写道

night_stalker 写道

不涉及副作用的代码，没有时间因子，说玄点就是不受因果律限制，可以编译期运行，把调用替换成结果，也就是可以做最大限度的优化。

pure FP 便是从语法上区分了副作用（当然语法上不区分也有可能做这种优化，只是不好做）。

百度百科!!! 写道

辨证唯物主义的因果律：认为任意宇宙状态都是其前宇宙状态积累的结果。任意运动状态均是其前运动状态积累的结果。具有最为广泛的普遍性。

    话说我长这么大都是由以前一直在吃的这个状态累积的结果..  XDD

貌似此因果律讲的是决定论。原文的因果律不做评价。

26 楼 Saito 2009-09-03  

night_stalker 写道

Trustno1 写道

赋值既IO,IO既通信,通信既时序,此乃命令式语言的不传之密.

真是奇妙 …… 可惜小波分析的课没去上过 ……

Saito 写道

night_stalker 写道

不涉及副作用的代码，没有时间因子，说玄点就是不受因果律限制，可以编译期运行，把调用替换成结果，也就是可以做最大限度的优化。

pure FP 便是从语法上区分了副作用（当然语法上不区分也有可能做这种优化，只是不好做）。

百度百科!!! 写道

辨证唯物主义的因果律：认为任意宇宙状态都是其前宇宙状态积累的结果。任意运动状态均是其前运动状态积累的结果。具有最为广泛的普遍性。

    话说我长这么大都是由以前一直在吃的这个状态累积的结果..  XDD

- - 我讲多错多，扯淡起来受无限流影响，当 joke 看就行了

    我小波分析倒是去上了. 除了听了第一节课老师讲了讲小波分析的历史. 到第二节课过渡到傅里叶变换的时候. 我就彻底昏睡过去了.. 话说比数学分析是难多了.. 基本不在一个难度次元上..

25 楼 night_stalker 2009-09-03  

Trustno1 写道

赋值既IO,IO既通信,通信既时序,此乃命令式语言的不传之密.

真是奇妙 …… 可惜小波分析的课没去上过 ……

Saito 写道

night_stalker 写道

不涉及副作用的代码，没有时间因子，说玄点就是不受因果律限制，可以编译期运行，把调用替换成结果，也就是可以做最大限度的优化。

pure FP 便是从语法上区分了副作用（当然语法上不区分也有可能做这种优化，只是不好做）。

百度百科!!! 写道

辨证唯物主义的因果律：认为任意宇宙状态都是其前宇宙状态积累的结果。任意运动状态均是其前运动状态积累的结果。具有最为广泛的普遍性。

    话说我长这么大都是由以前一直在吃的这个状态累积的结果..  XDD

- - 我讲多错多，扯淡起来受无限流影响，当 joke 看就行了

24 楼 Trustno1 2009-09-03  

赋值既IO,IO既通信,通信既时序,此乃命令式语言的不传之密.

23 楼 Saito 2009-09-03  

night_stalker 写道

不涉及副作用的代码，没有时间因子，说玄点就是不受因果律限制，可以编译期运行，把调用替换成结果，也就是可以做最大限度的优化。

pure FP 便是从语法上区分了副作用（当然语法上不区分也有可能做这种优化，只是不好做）。

百度百科!!! 写道

辨证唯物主义的因果律：认为任意宇宙状态都是其前宇宙状态积累的结果。任意运动状态均是其前运动状态积累的结果。具有最为广泛的普遍性。

    话说我长这么大都是由以前一直在吃的这个状态累积的结果..  XDD

22 楼 night_stalker 2009-09-03  

不涉及副作用的代码，没有时间因子，说玄点就是不受因果律限制，可以编译期运行，把调用替换成结果，也就是可以做最大限度的优化。

pure FP 便是从语法上区分了副作用（当然语法上不区分也有可能做这种优化，只是不好做）。

-----

现在的编译器已经非常 nb 了，像 gcc 的 -O3 选项会把一些循环展开成并行的，但还是不够智能。
如果把遍历操作抽象出来（map、filter、fold ……），编译器就知道哪些循环是顺序无关，哪些是顺序有关，并行化的优化也会更出色。

要做性能比较的话，可以说：函数式是自动档，命令式是手动档，如果你的技术高超，精力无限，手动档最 imba，不然还是自动档的比较来风。

优化性能的话，好钢用在刀刃上，大部分设成自动档，让程序员集中精力搞瓶颈的效果更好。所以性能 critical 的程序经常会见到混合编程。（譬如游戏就经常是脚本结合 C++ 甚至汇编）

-----

复合函数可以看作一种 eval。eval 有多强大多 evil 大家都知道 ……
复合函数还可以看做泛型、模版、Annotation/Attribute …… 一个特性满足 n 个愿望 ……

语法糖不是无关紧要。糖是 pattern 的抽象，你用到这种模式时不用搬来教科书抄一遍，直接糖就行了，糖多了往往能揭示另一种思维角度的效果。
譬如 rails 大量出现的糖 &:xxx，看起来就像 FP 语言里传递一个函数一样。
又如 scala 的下划线语法糖（如 sortBy(_<_)，看起来已经很像 haskell 的 sortBy (<) 了），它清晰表明了传递的是计算而不是变量，就不用费脑筋想自变量的名字了。

复合函数的灵活，意味着你可以定义一些看起来很像新语法的结构，或者糖。有了自己的糖，描述离不开 专业术语、黑话、行话的领域逻辑就更方便，更靠近业务了，便是所谓的 DSL。

-----

C++ 和 java 的区别不仅在于内存分配，还在于声明。 C++ 可以拆分声明和定义，但是不声明的东西就不能用，所以程序员还要自己控制声明的顺序。
java 就不需要指定声明的顺序，定义了一个类，便相当于所有其它代码都知道了这个类，不需要 include 相应的 .h 文件就能用到这个类（注意 import 和 include 不同，package 相当于 namespace，import 相当于 using）。

这种设计的好处就是声明式代替命令式，程序员不需要考虑代码的编写顺序了，顺序无关（楚轩：脱离因果律制约哦）可以推动另一种程度的并行化 —— 代码编写的并行化。这是对团队协作的作用。

object 和 closure 本质上没什么不同，class 声明可以 morphism 到 FP 中去，纯 FP 无非是彻底一点，把声明式贯彻到底，还原出一个纯粹的世界。
没有 object 和 class 的 lisp 和 haskell 也能做 OO 的设计， a.do(sth) 和 do a sth 只是语序的区别而已。

21 楼 coolspeed 2009-09-02  

RednaxelaFX 写道

iaimstar 写道

从第一次听到鲁棒×性这个词
我就觉得好和谐
今天还有玉米啃，太和谐了

从第一次听到鲁棒性这个词我就往下想……为了不往下想，还是啃啃玉米好了

@Saito
中文wiki的可靠度经常跟伪基有的一拼……三条规则很好理解
啊发就是换个马甲
啊呗就是把鸡蛋装篮子里
啊唉就是装着鸡蛋的篮子跟不装鸡蛋的篮子都一样是篮子
...@"_"|||...

数学上是复合函数。支持复合函数应该是FP不同于命令式地把操作当成更主要的操作对象，而不是数据。因此对操作的分派会更灵活，对数据的处理性能不高。把副作用隔离就是把对操作的操作和对数据的操作分离。

但是我不确定复合函数是不是非常必要。

20 楼 RednaxelaFX 2009-08-31  

Saito 写道

     倒是有一个疑问. 函数式编程在不可避免的需要大量保存state的情况下. 用monad是不是还不如直接像scala之类的直接用oo直接处理掉..(适用场景: I/O GUI  etc .. ).  pure fp 在 gui 方面貌似不是很在行啊..

如果你想尽情享受名词轰炸的话，你可以看看reactive programming的相关资料，然后functional reactive programming……FP跟GUI不是天生对立的 =v=

我……我一直有个不成熟的看法，拿出来晾晾：一般来说FP让我们可以少显式指定东西，例如我们不必显式指定某个函数是否要用循环；写得少了，“威力”却更大了。如果一个函数是尾递归的，那么编译器/运行时理论上可以选择最适合当时的执行状况的实现方法，例如说在单核单线程上用单个大循环，在多核多线程上通过分析数据依赖性来把运算拆分到多个线程上的小循环。类似的分析，对用命令式语言写出来的程序不是不能做，而是有时候为了保证程序语义，很多优化只能保守的做，很别扭。命令式语言里，有时候可以抽出公共子表达式的地方，可能会因为指针的别名分析有困难而只好放弃；纯FP语言则可以激进的做优化，比较好分析。
我想说的是，我们写得少了，给出的自由度高了之后，现代的编译器/运行时才能更好的工作，反而能帮我们做更多事情。以前有人提出过一种语言结构，看起来跟顺序结构类似，但显式规定了其中的语句的执行顺序是未定义的。多好。

基本上FP没硬件直接支持，都得靠软件来实现其语义。像消息传递风格的编程，如果真的每次传递消息都把整条消息复制来复制去，那效率肯定很糟糕。有些系统是给消息贴上token，真正复制的只是token，消息的实际内容放在buffer里，由系统来控制其ownership。只要同一之间只有“一个人”拥有某条消息的ownership，它就跟“复制了”表现得一样，因为状态再怎么变也无法被其它部分观测到。
所以之前我说FP思想很重要，实现方式也很重要；后者反而又会涉及大量命令式的内容……呵呵

19 楼 下一站，火星 2009-08-31  

等ruby2.0出现的时候，谈这些就没有多大意义了

18 楼 Saito 2009-08-31  

RednaxelaFX 写道

Saito 写道

lambda演算是什么. 就是 一个函数定义式跟一条变换规则.

不是一种记法和三条变换规则么……？

又见鲁棒性～啊，今天还没啃玉米，罪过罪过

引用透明性是好。不过如果不慎靠太多的参数来“传递中间结果”的话，涉及的复制开销也客观。不是说“没有副作用”之后性能/可伸缩性就自然会变好，里面怎么实现的也很重要。

     这个应该可以通过continuation来改善吧. 或者通过别的方法去 Refactoring .. 

     倒是有一个疑问. 函数式编程在不可避免的需要大量保存state的情况下. 用monad是不是还不如直接像scala之类的直接用oo直接处理掉..(适用场景: I/O GUI  etc .. ).  pure fp 在 gui 方面貌似不是很在行啊..