• 嗯嗯,关于函数式风潮与SICP


    看见老赵在推这本书。本来写了个回复,当时想了想没发(现在越来越不敢乱说话了)。因为我以前也是推过这本书的。如果现在又泼凉水,似乎有点对什么风都要说不的意思。

    不过,我确实已经好长时间没翻过SICP了,不是因为不看书了或者太狂了,而是这本书根本钩不起我的兴趣。话说回来,当年我可是连夜读完、反复看了好几遍的,眼前一亮和欲罢不能的感觉(很少有)还记忆犹新。借着老赵这个话茬,我就仔细思索了一下这个来龙去脉。

    对于我等命令式起家的程序员,似乎当初看到本书,都不免兴奋。当我们在自己的领域中无法进步时,就会希望“他山之石,可以攻玉”。

    实际上很多推崇FP和SICP的人都是这个理由,而现在我觉得至少对于我来说,并没有获得预期的东西。我在很长一段时间内,相对一般人,都更加深入的实践了FP。比如不仅仅是图局部设计,而是尝试将FP的思路推广到模式甚至架构的级别。

    不提具体的障碍,最终从我今天的视角去看,对于认识的提高这一根本目的来说,一切像是“韩卢逐块”。

    相互印证的作用有没有?有。

    但充其量也就是让我在同一个层次上更加稳扎稳打了,知识、经验和手段也更丰富了一些。比如对无Side Effect的追求,只有FP在强调;在命令式这边,它往往仅分散的隐藏在“不要使用全局变量”之类的具体告诫中。

    对于大多数人来说,只要精研好某一种流行的风格的种种设计方式和实践,再借鉴到对副作用的警惕就足够(并且能得到我在FP中收获的大部分)。现在大家热捧的很多却是FP的其它特点:这是完完全全的舍本逐末。

    那些有关组织形式的内容,真那么新鲜吗?为什么国内外普遍的,在社区层次上的“牛人”(刨除FP起家的)对函数式的理解都不太费劲?

    积累的深度(我们能控制的)让我们吸收此类知识的速度变快,瓶颈(外在的、客观的)的高度决定了此类知识不能帮助我们真正的跃升。对于这一批人来说,FP更多的只能是一种补充,无论是作为写手还是作为工作者。(结果却形成了一些“不FP非高手”的歪风。)

    过去我也鼓吹一些FP说辞;似乎FP的学习能让我们抓住什么更本质的东西。(这真是让人害臊)我想,像我这样较真的人,最初在FP风潮中看到的本来是“进步的曙光”,因为通常未知的东西就代表着新境界的入口。

    现在看来,这仅仅是另一条幻象不同的学习路径罢了。我们从这条路上走一遍,又从那条路上走一遍。风景迥异并不能让我们走的更远;最后发现,靠,瓶颈还在那里:整个过程只是个心情愉悦的旅游观光。

    (提高不能说没有,至少最后会认识到这些路径的大方向是一致的;更本质的提高不是我这一篇的目的(我也不知道如何做【1】),我是来刹车的。)

    更具体的,和其他风格的差异化和掌握的手段的丰富化都没有用,关键是每一件工具,它到底怎么帮到我们,帮了我们多少?在这一点上,相对于我以前“分清角色”的说法,无论对于研究人员还是工程人员,在我们的领域中有的是比FP重要的东西。【2

    可能有人会说,突然碰到一个需求,FP思维的设计方式最合适而你完全没接触过FP怎么办?(如果你确定半年后【3】就要去一个使用Erlang进行函数式编程的环境,这就是硬性需求了,这种情况不必讨论。)

    如果是一个真正“精通”级别的命令式程序员(OO与否无所谓),他会做出一个可以和FP设计一一对应的设计;这比在没学习过DP的情况下写出了某一个模式还要自然。虽然这些方式铁定没有FP的实现来的舒服,但是这说明一个问题:所谓的FP思维,并不用去刻意追求。

    (很显然,如果语言支持那些FP的特性,这样一个有经验的人员可以在完全不知道FP这个词的情况下顺理成章的用上这些特性消除没有这些特性时候的冗余构造)

    总结一下,我的观点是:FP对大多数人的职业成长来讲,都没有什么重要性;虽然对它的学习总归是有益的,但这种益处(从我个人想法上)是非必要的,而且是可被非FP方向的深入实践替代的。

    关于SICP,在很多文章里都提到它是某某的课程,“影响了几代程序员”,这其实并不成为“FP有多好”的证据:这“几代程序员”大多数也不过是平庸之辈,即便其中最出色的群体,其之所以杰出,有多少FP成分在,也是没法落实的。

    相反,在SICP出版以前(或者以后),真正在乎或者推广FP思维的大师级程序员的比例其实相当的小。(即使把那些在不同阵营里跳来跳去或者很运气的提前趴对了某一方法论的某些技术明星也算成“大师”)

    露骨一点说,那些“如果FP了,软件世界更美好”的说法现在听起来像不像“银弹”或者银弹的等价物“狗皮膏药”呢?而布道者们“当年不选择FP的理由(比如效率)逐渐不存在了,产生了更多选择FP的理由(比如并行)”也只是影响了不多的人。

    FP世界著名的“劣币驱逐良币”论我曾经很喜欢;而现在我觉得小资们有理、群众的眼睛也是雪亮的:难道那些大师级群众也是又懒又馋,脑袋不Open吗?如果FP具有某种不可替代的启发性,是不会差点在主流世界断气的;突然又能喘气了,归根结底还是新的领域发掘的实用性。

    其实对于某一本书或者FP或者其它更多更广泛的讨论,归根结底要回到一个问题:我们应该学什么?除了上述被我的个人经验否定【4】的理由,我们为什么选择FP(或某某)?

    我想也许是如何选择下一阶段的学习本身就是一个难事吧,牵扯到短期的、长期的规划等等,这些都不容易理清(也许越博学说明这方面能力越弱)。另外,有时候随机性的学习也许反而会促进对自己未来的选择,这样这个地方就形成了一个先有鸡先有蛋的矛盾。

    最终,从众(不是说绝对意义上的大多数程序员,而是你认同的圈子的程序员)反而成为了一个较佳的选择。但这并不意味着我完全是扯淡:我只是提醒选择学习什么都要谨慎,不是所有的学习都有同样的**性价比**。具体到FP,这篇文章给出一个个人的想法作参考。

    那么我对SICP这本书的评价是什么呢?鉴于社会现实和大多数程序员的具体情况,一本值得一看的*课外*读物,仅此而已。

    P.S. 这篇文章之所以还是发出来了,也正是因为我吐血推荐过SICP,我保证以后尽量不在放首页的文章中凭着一时的认识下任何诱导性的结论。SICP还是值那个钱,但是如果它花费了你的时间,却没在你未来的职业生涯中起到作用,而我的建议是一种第三者的鼓励,我道歉也没啥用了。

    我再强调一遍,这不是(我也不打算争论)FP或者XX到底应该被如何看待的问题;具体到一个又一个的人,这是性价比的问题。时间和精力永远是最宝贵的,如何进行投资和选择,应该当作一个最重要的问题被重视起来,这里,别人的经验不能让你走捷径(包括这篇文章)。

     


     

    注一:

    我个人有一个估计,应该是在各自“理解费劲”的地方,甚至应该比我们入门两眼一摸黑时还费劲。越往上越难进步似乎很合理。

    如果谁感觉有点如鱼得水,学习的时候轻松的“大有收获”,我想他就应该警惕了:这种暂时的掌握或求知的快感往往是虚假的。

    这时候往往这个人,应该去寻找更高层次更加艰深的知识,眼前即使看到的大不相同,也可能仅是一种隐藏了相似性的经验重复。

    注二:

    如果于一个人不想成为一个一辈子的纯程序员兼程序员中的“博学者”,FP甚至远不及DP重要。(除非是FP起家的而且将在起家的领域中很有前景的干下去,可又有多少人是如此呢?)

    这是由于在多人项目中适当的设计和组织是不可或缺的,而现在稍微好点的形式大多又都基于面向对象。虽然DP仅仅是一个发挥某形式特点的一组手法,但对于工程人员来说DP的学习却应该有更高的优先权。

    这有点像一些游戏,比如每次升级如何分配点数,如果角色培养都要动动脑子,难道活人的学习却可以“普适”了吗?所以,具体到DP、FP或者任何XX也不一定在所有人的优先级表的前列,只是学习的目的越清晰越好。

    注三:

    如果你明天就要去,而半年前你还不知道,那就是你对自己的规划和预测的一个大大的失败。

    补充一点的是,我们应该对F#/Erlang/JS等下的深度FP编程与自己的交集做个可能的预测,预测到半年后足以。

    注四:

    我的个人经验未必对另外一个个体而言是对的,虽然一个人现在不认同也未必代表我的观点对他来说是错的。

  • 相关阅读:
    LeetCode算法题-Binary Search(Java实现)
    LeetCode算法题-Kth Largest Element in a Stream(Java实现)
    LeetCode算法题-Search in a Binary Search Tree(Java实现)
    LeetCode算法题-Degree of an Array(Java实现)
    LeetCode算法题-Count Binary Substrings(Java实现)
    LeetCode算法题-Binary Number with Alternating Bits(Java实现)
    之前见汤姆大叔 写过一系列的 js 深入理解 呢 很是感觉经典
    xsd 和 wsdl
    发现 一个业务管理系统 解决了 orm 和 前端框架 剩下的 是 业务逻辑 了 。 哈
    uwp 嗯 我最近 准备开发一个 应用 。 嗯 走起
  • 原文地址:https://www.cnblogs.com/guaiguai/p/1524693.html
Copyright © 2020-2023  润新知