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

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

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

  

  

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

    说说我自己的理解. 关于未来的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会在未来占据越来越重要的位置. .

 

字太小了，我看不清楚，下次弄大点。

你应该配眼镜了

ls太狠了

我不觉得  “关于未来的web领域. 开发上无疑是往更"敏捷"方向发展”

如果作坊也算敏捷的话，那开发确实是越来越作坊了

我个人觉得新的开发方式总是伴随着开发者对前一种开发模型的理解和改进

现在敏捷很多时候是作坊式开发的借口，这样看来，敏捷确实是未来的方向

但是出于对作坊的无比痛恨，于是很多开发逐渐又走近瀑布了，一口吃不成个胖子，那么多人还没有完整经历过传统的瀑布模型，就想着蹦敏捷了，那不是上完小学就上大学么。

    这里出现了一些理解问题..  囧哥哥.. ..

              为什么我的敏捷带了引号..其实我的意思是快速开发的意思. 并不是真的"敏捷"...

              跟真正的cmm .. 敏捷. 什么瀑布. 什么演进..一毛钱关系都没有..当然你觉得用敏捷能够更敏捷的话. 那还是敏捷吧.

这个 。。。 天气 不错 哈哈 天气不错

我从来没觉的敏捷能够梗敏捷。。我是作坊里面长大的孩子。。。 － －！

道个歉，一时图个嘴上痛快，犯了一看标题就吐槽的坏毛病了

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

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

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

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

    fx大大来鞭策 .. 我感激涕零..   以上是引用自wiki的内容. 

    其实还是要涉及到函数式编程的掌握程度的喽..性能 .伸缩性什么的. 写的太烂. 什么语言都是浮云吧..

    鲁棒以后不写了. 乖乖写健壮吧..  ..  鲁棒性跟你的编程水平也有关系. 我的罪过..

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

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