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

Monox

回复 51# OwnWaterloo
当时回帖的时候确实不知道自己在写什么（唉，不过那个无所谓了）。我也好久没用Haskell了，该忘的也差不多忘光了，不该忘的也忘了。不过按照我的记忆，Arrow本不应该拿来和type class比的，它应该拿来和Monad比。不过，另一方面，HXT确实有利用你说的接口统一，因为HXT使用Arrow解析XML的结果是虽然结点类型是自己定义的，但是XML解析完了以后结点的容器就是列表啊一些Haskell的通用类型，可以和其它Haskell的系统统一处理。而根据你说的Text.XML.Light的工作方式，我明显得感觉到这个库的设计受到了很大程度上的其他命令式语言的影响，相当于是其它语言的XML库直接用Haskell实现了而已，并没有考虑如何在Haskell里实现才更适合在Haskell里使用。大概你看到的别人说它简单的理由也是因为它和其他语言里已经司空见惯的XML的解析库的用法很类似吧。所以如果使用的是HXT的话就只存在  Prelude.lookup和 Data.Map.lookup 的不统一，不过我也不确定List的lookup和Map的lookup是否真的没办法统一了，因为这两种类型都是Haskell里使用很广泛的数据结构，应该已经有type class（其实Monad也是一种type class，而List和Map应该都是某种Monad的实例，或许……）把它们统一起来了，而不需要自己去写。其时type class根面向对象的interface真的很像，所以对于强类型的语言来说这些type class对数据的统一处理是很有必要的，一方面Haskell提供了自己定义和实现type class的功能，另一方面常见的type class大多都已经是Haskell里很成熟的实现，所以即给了程序员自由度，又没有给程序员过大的负担。我觉得在使用Haskell的时候被其它语言影响导致的一系列问题太容易被认为是Haskell本身的问题，不过，另一方面这些确确实实是在写Haskell程序的时候特别需要注意的地方，特别是刚开始入门的时候（像我都学Haskell快一年了，还只能算正在入门，主要还是平时没有机会用，之前的工作要求只能用C，现在我找到的工作应该或多或少可以尝试用一下Haskell，因为我的新工作除了Java是肯定要用的以外，还有一些工作不管用什么语言都可以，只要得到结果就行）。

zhouzhenghui

typeclass应该跟c++ concept最接近，不过c++引入类型推导后，也应该可以通过非侵入式接口自己设计实现monad这样的东西了。
我觉得函数式本身跟类型是两个侧面，只是搞形式验证这帮人肯定是一起都做的，函数式本质应该是算法抽象，控制流程的东西，当然有类型lambda后，类型也可以一起计算了。类型计算方面，c++模板也很强大了，现在有了自动推导，估计不弱于haskell，反正我看到很多人叫嚷着要做monad库。
然后说一个很本质的东西，continuation，函数式编程的很大一部分好处都是基于这个上面的，有人说continuation是一切调用之母，我深以为然，在haskell里，continuation monad可以实现所有其他的monad，所以也是monad之母。
所以除了语法外，最新的语言基本上都涵盖了这些内容，没有本质谁强谁弱的问题，以后还是改进语言本身，meta programming，DSL之流，我看很多新的语言被热捧，里面引入各种各样的新表达方法，但也增加了噪声，如何更加一致起来，是未来语言要考虑的一个问题。

_HellAngel_

说好了要来捧一下场。
纠结了一段时间，觉得还是来捧一下的说。（以上废话）。

函数式编程语言，听着觉得很高深啊= =，好吧，只接触过ML。（不要想 歪= =）pia。。好吧，是我想歪了。不知道有没有类似经验的前辈。
作为小菜，也没有什么经验分享= =。就是觉得比较有趣，Haskell也听说过，据说OW君很喜欢（pia，说重点)。（貌似还是废话）- -。

恩，大概就是这样= =。（纯水贴。。。。。。。）

uxyzp

接触契机：最近在学Python，而Python是一门多范式的编程语言，它同时支持过程式、面向对象和函数式的编程范式（我不是来拆Haskell台的）
使用动机：暂无非常明确的动机，仅为拓宽思维，因为听说函数式的历史更悠久……
实际经验：也就写写运维脚本，还没深入挖掘函数式的好处……还是说我的工作任务不太符合函数式？
应用前景：我觉得是在数学建模方面……

OwnWaterloo

回复 55# uxyzp
The fate of reduce() in Python 3000
恐怕Python的作者不是这样认为的。

OwnWaterloo

回复 54# _HellAngel_
ML这梗都用烂了。。。

OwnWaterloo

回复 53# zhouzhenghui

C++的类型推导和Haskell完全不同。 一个是从参数出发推函数内的表达式， 一个是从函数内的表达式推参数。。。

continuation是本质，本质到随便那个语言里都有这个概念，不同只是在于语言是否将它暴露给程序员用。

Haskell里真正离不开但又不起眼的我觉得是显式地严格求值方式6.2  Strict Evaluation。

大多数语言都不将continuation暴露给程序员用， 也都这么过来了。。。
Haskell一开始也没借助Monad概念来处理副作用，而是受到Miranda用的缓式列表。。。
在依然保持non strict语义的前提下离开了显式地求值机制这语言就真的只能当玩具了。。。  没法控制副作用发生的顺序。。。

各种新表达方法确实很不和谐。。。

OwnWaterloo

回复 52# Monox

Text.XML.Light简单完全是轻信了那个帖子里的言论。 不过也没有时间一个一个去试就是了。
用过之后并不满意， 也就是前面提到的它自定义类型的同时需要新的操作数据的方法， 所以才会继续提到type class。
而你说Arrow是因为HXT用它吧？

List是有Monad instance的， 不过不是用来做查找的而是list comprehension。
不能确定会不会有人会为Map实现一个， 但base里好像没有。

Prelude.lookup和Data.Map.lookup在base里好像也没有相应的type class。 Data.Foldable 可以用， 但对查找来说太低效了。
非常极端的是这货： ClassyPrelude 。。。
虽然作者的初衷并不是这样。。。
不过作者原本意图那样使用type class也能缓解数据类型一改，一大堆代码都要修改的问题。。。

和type class相比interface弱爆了。。。

一方面interface是操作与对象耦合，于是它就没法：

1. 
   
2. minBound :: Bounded a => a
   
3. maxBound :: Bounded a => a
   
4. mempty :: Monoid a => a
   

复制代码

等等。 要实现：

1. 
   
2. (==) :: Eq a => a -> a -> Bool
   
3. (+) :: Num a => a -> a -> a
   

复制代码

等等也会比较麻烦。
像

1. 
   
2. elem :: Eq a => a -> [a] -> Bool
   

复制代码

这样的操作，那个实现多态的东西会重复出现在集合的每一个元素上。

Haskell里没有这样的耦合，并且可以需要的时候再将操作与对象耦合在一起。

另一方面，interface将定义数据类型与实现interface耦合。

定义数据类型时怎么可能想得全它可以实现哪些interface？
比如前面提到的Data.Map， 不管是为它实现CanLookup还是IsMap都是在定义Data.Map之后而不是同时发生的事情。
不管实现与否，不管实现多少个，Data.Map总在那里，总是那个Data.Map。

而如果必须同时定义数据类型并实现相应的interface， 就会出现这样的情况。。。
A定义了X类型并实现了I接口。
B发现X其实还可以实现J接口。 于是他就面临选择：
1. 等作者改。 不一定能得到
2. 自己改。 要能获取源代码。 并且还得考虑接下来和upstream的合并问题。 有可能并不是upstream懒，而是他因为各种原因不愿意让X实现J。 那之后就只能自己考虑将upstream的更新合并到自己这里。。
3. 定Y作为X的wrapper，并实现I,J接口。。。

Monox

回复 59# OwnWaterloo

    嗯，我提到Arrow确实是因为HXT用了它。
    看你的回复，明显可以看出你最近肯定看了不少Haskell相关的东西。我自己对Haskell的了解还是很浅，刚看完这本趣学指南，不过这本趣学指南是基础的基础，要熟悉Haskell还有很长一段路。
    另一方面，Haskell的base提供的功能是很有限的，一般都会需要base以外的模块。即使是Haskell Platform 提供的那些模块可能有时候都不够用。不过我也不知道是否有模块实现统一的查找方法，确实在base里没有找到相关的type class。不过多半有这样的type class吧，就算没有也肯定可以自己实现，因为 lookup 的signature 大概可以写成这样嘛 Ord k => k -> t k v -> Maybe v。大概之所以base里没有提供相关的type class是因为list的lookup 一般不要求key 是Ord的实例，它只要求是Eq的实例，而Map为了提高查找速度，要求k是Ord的实例。不过，另一方面，list可以很方面的和Map之间进行转换，这也可能是base里没有相关type class的原因，因为觉得没必要。
    我也觉得type class比interface强，事实上我在其他语言里找不到有和 type class这样即灵活又强大的东西了。不管那些拥护面向对象编程的人是怎样想的，我都觉得面向对象里没有能和type class相比的东西。
    不过，确实也得承认Haskell里的很多特性实际上并没有所宣传的那样好，这个在任何语言里都一样，你接受一门语言的优点的时候同时也得受到相应的限制。
    唉，因为对Haskell还是算不是精通，所以上面的回复写得有点泛，希望有一天自己回过头来看的时候觉得这些话语有多幼稚可笑。

_HellAngel_

回复 57# OwnWaterloo


    好吧= =。。唔= =。。还是可以用一次的嘛= =。。话说。。这书还是蛮好看的呀。。。