函数式编程语言急先锋：Haskell（获奖名单已公布-2014-3-28）

lost_templar

万恶的骆驼命名法---

starwing83

现在用命令式的脚本很多，函数式已经几乎很多年都没用过了，但是函数式的一
贯思想，其实还是一直在写代码的过程当中着的。

倒不是说什么很虚的“精神”“方法”之类的。不是，完全不是。Haskell是我
08年开始学的，当时还印了一本report，还翻译了前面的四章（后面的到monad
IO就翻译不下去了= =）。学习Haskell当时的一个功利的想法是，这货号称“只
要编译过了程序就没错”，这个想法促使我去学Haskell了。

从这个角度上来说，Haskell是有一些很“先天”的东西的——它会强迫你去做
什么。就如同束缚衣一样。束缚衣穿习惯了以后，就感觉和没穿一样了，然而就
算脱下来，你也会在程序里面去维持某种“束缚”，这样的束缚本身就能够保证
了你不至于犯太大的错。从这个角度上来说，“只要编译过了程序就没有错”正
是将“束缚”（编译器规则）和“正确性”联系在一起的第一件束缚衣。

这样的束缚衣思想，贯彻了整个函数式程序。函数式程序不像命令式，给出“做
这件事情的详细步骤就OK”，而是更深层次地去思考“怎么才是最和谐的方式？
”这种思考促使了许多在函数式角度看来十分自然的演变：解耦、抽象、关系。

比如说，“赋值不变性”就是将“程序状态”和“处理步骤”分离开来。由编译
器来对你束缚让你不要引入不必要的状态——甚至即使状态是必要地，也让你强
制性的去思考怎么才能更加一致性的解决这个问题，而不是在局部采用
dirty-and-quick的方法去解决问题。而所谓“函数式的列表操作”则是对操作
的标准化抽象的尝试，它致力于产生出足够抽象而强大的原语，在性能和灵活性
上得到统一——同样的，类型系统也是使这个机制真正实用的另一件“束缚衣”
。

而，类型系统的最关键的因素，就是“类型之间的关系”了。这恰好就构成了
Haskell的基石，这应该是函数式多年的沉淀产物。

现代的流行编程方法是“自由”、“快速”、“原型开发”。提倡“减少束缚”
、“放飞思想”。以此带来的后果就是越来越普遍的“无法调试的脚本程序”。
为什么明明是毫无检查措施的脚本程序，就有人能写出很健壮的程序，然而有些
人写的只要一超出正常状况就各种崩溃呢？脚本程序是快，但是并不能够完全没
有束缚。这种束缚脚本可以不提供给你，但是你自己必须提供给你自己。

从这个角度上来说，在这个脚本盛行的世界里面，函数式——特别是其中语法语
义最为严格的Haskell——恰好就是这么一件束缚衣，这么一种能够让你把精力
集中在如何解决问题，而不是构建各种没用的所谓“范式”的自我束缚能力，这
种能力在开发的过程中的重要性不言而喻。

相对于“敏捷开发”、“文档”和“结对”这种种行政、团队上的束缚力，从技
术上就产生的束缚显然会更对程序员的口味。所以Haskell作为束缚作用的一门
语言，还是很重要的。对我来说，现在函数式的存在意义已经从写代码的日常语
言变成了一种其他的东西，一种只要你想到，你就不会在代码里面写某种东西的
因素——这样的束缚作用，是我们现在这个程序员门槛降低、素质急剧下降时代
所必须的。

这就是我对Haskell在整个编程角度的看法。

至于实际应用中的场景——恩，先送本书让我学会了再说哈……

zhj1011

新的东西，了解下先。

OwnWaterloo

回复 10# jieforest

Scala虽然没有实际使用过，但平时会关注它的一些信息。
于是看到了这样一篇文章：http://blog.goodstuff.im/scala-s ... ent-near-impossible。
指出Scala里存在下面的问题：

An attribute of Scala is that the Scala compiler generates fragile byte-code.  This means that all the code in an executable (JAR or WAR) must be compiled with the same library and compiler versions.

请教一下：
1. Scala是倾向于从源代码编译还是使用预编译好的jar？
2. 如果是预编译好的jar，是否有遇到过文中提到的问题？ 打算同时使用多个库，但找不到一致的版本？
3. 如果遇到过又是怎么解决的呢？

OwnWaterloo

回复 12# starwing83

“只要编译过了程序就没错”确实很diao啦。 但另一方面，处理其他一些问题的时候，比如xml： http://hackage.haskell.org/packa ... ML-Light-Types.html 。
静态类型会不会太不方便了？

HappyPonder

函数式编程是数学思维的计算机体现啊！语言的先进性总是比实用性早~

starwing83

回复 15# OwnWaterloo


    不方便是很正常的，毕竟束缚就是束缚。脚本语言开发速度快这个是客观事实。不过那网址的虽然看不太懂，但是感觉还是很厉害嘛（不明觉厉……）。

不过，静态类型本身就意味着需要认真而正式地去思考一些东西，你看xml里面那么严谨的命名和规则神马的，就知道这样其实也还蛮不错的= =

对于xml这种情况……我觉得发展DSL是一个出路，比如xpath神马的，语言内DSL或者嵌入式DSL都可以接受……

beyondfly

接触函数式编程的契机以及学习并使用函数式编程的动机。
   接触过erlang，主要是没有学过函数式编程语言，想熟悉一下这方面的知识。erlang在海量并发的应用中具有很大的优势，原因是其内置的虚拟机机制。

OwnWaterloo

回复 17# starwing83

动态类型语言里直接用内建数据类型与数据结构就可以表示xml了。 你看看那个链接里有多少类型。。。 为了处理xml。。。
即使是静态类型也可以尽量复用内建数据结构（以及它们支持的操作！）来表示xml。  但大部分Haskell程序(库)喜欢再定义专门的类型来表示。。。
至于“编译通过就很少有运行错误”与这种“定义专门的类型”倾向之间有没有必然联系就不清楚了， 经验不够。。。

starwing83

回复 19# OwnWaterloo


    定义专门的类型是肯定有好处的。比如说XML本身就有一套规则，保证XML文件的结构的正确性（是叫DTD？）专门的类型可以保证这一点。

没有类型的json是很容易吃亏的，反正……