Chinaunix

标题: 函数式编程语言急先锋：Haskell（获奖名单已公布-2014-3-28） [打印本页]
作者: OwnWaterloo    时间: 2014-02-25 13:30
标题: 函数式编程语言急先锋：Haskell（获奖名单已公布-2014-3-28）
获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-4133289-1-1.html

函数式编程正重新进入人们的视野：

在各种函数式编程语言中Haskell都可以算函数式“味道”非常浓烈的语言。
例如仅“默认使用非严格求值”就可以在上述提到的编程语言中独树一帜。除此之外Haskell还采用了许多在其他编程语言里难以一见的编程概念：
等等。

正因为相比主流编程语言（甚至许多函数式编程语言）Haskell有太多独特之处，选取Haskell作为学习函数式编程的载体是一件有趣且又富有挑战性的工作。
这种时候有一本合适的入门级教程会让人取得事半功倍的效果。满足该定位的中文书籍非《Haskell趣学指南》(Learn You a Haskell for Great Good!)莫属。

本期话题（包括但不限于）：

活动时间：2014年2月25日-3月25日
本期奖品：参与讨论质量最优秀的会员，奖励《Haskell趣学指南》图书一本，共6本， 点击这里购买

图书简介：

原书名：Learn You a Haskell for Great Good!: A Beginner's Guide
原出版社：No Starch Press
作者：(斯洛文尼亚)Miran Lipovaca
译者：李亚舟 宋方睿
丛书名：新锐编程语言集萃
出版社：人民邮电出版社
ISBN：978-7-115-33559-3
上架时间：2013-12-28
出版日期：2014 年1月
开本：16开
页码：301
版次：1-1

样章阅读： http://learnyouahaskell-zh-tw.csie.org/zh-cn/chapters.html 。
前言： qy.doc (32 KB, 下载次数: 31)
目录： ml.DOC (679.5 KB, 下载次数: 14)
具体章节： 01.doc (245 KB, 下载次数: 30) ； 04.doc (274.5 KB, 下载次数: 15)


活动要求：
1、 要言之有物，不能低于20个字
2、 本次话题主要关注与函数式编程（特别是Haskell）相关的讨论，其他问题可能不做重点

fy.DOC

649.5 KB, 下载次数: 17

yzx.DOC

23.5 KB, 下载次数: 18
作者: 2009532140    时间: 2014-02-25 14:05
看看！
学习一下！！
作者: 2009532140    时间: 2014-02-25 14:06
老总的样章地址估计很多公司都屏蔽了...
作者: to407    时间: 2014-02-25 15:24
赞一下,.                  
作者: Herowinter    时间: 2014-02-25 16:29
恭喜晋级实习版主。
作者: lz小骆驼    时间: 2014-02-25 16:43
占楼，来看看        
作者: jimmy-_-lixw    时间: 2014-02-25 17:05
支持楼主的讨论话题。
作者: qingduo04    时间: 2014-02-25 19:35
路过.......mark
作者: OwnWaterloo    时间: 2014-02-26 00:18
感谢大家支持，还请多多分享一些经验呗~
作者: jieforest    时间: 2014-02-26 16:39
本帖最后由 jieforest 于 2014-02-26 17:08 编辑

接触函数式编程的契机以及学习并使用函数式编程的动机。
在实际工作中使用函数式编程的经验。
函数式编程在实际应用中的前景。
——————
三个问题我放在一起讨论吧。

在众多函数式编程语言中，我比较喜欢的是Scala。

Scala语言是基于JVM的，可以在程序中同时使用函数式编程思想和过程式编程思想，也支持面向对象编程，还可以调用庞大的Java库，尤其是类型安全，代码简洁。

几年前最初接触Scala语言是因为Play框架。Play框架是一个Web开发框架，也是一个全栈式的应用框架。Play框架包括MVC模型、类似于Hibernate的ORM、基于Groovy的模板引擎、基于Apache Mina的HTTP服务器，跟Ruby社区的Rails框架相似。Play框架还有开发效率高、排除故障方便、支持异步开发、支持热部署等特性。

由于Play框架同时支持Java和Scala，因此我开始尝试了解Scala。并在学习Scala的过程中逐步体会到它的强大之处。

还有Scala语言的Akka库，用于简化编写容错的、高可伸缩性的Java和Scala的Actor模型应用，极端的强悍。

有些项目的个别模块我们就是采用Scala开发的。

对使用函数式编程的最大体会是它能拓展开发者的编程思路，让开发者不再局限于OO编程思想，解决问题的方法也不至于很狭窄了。

目前面向对象仍然是主流，函数式编程还是小众，就像萝卜青菜，各有所爱那样，没有谁能取代谁。函数式编程至少给程序员的编程生活带来了一些乐趣。
作者: lost_templar    时间: 2014-02-26 21:07
万恶的骆驼命名法---
作者: starwing83    时间: 2014-02-27 16:01
现在用命令式的脚本很多，函数式已经几乎很多年都没用过了，但是函数式的一
贯思想，其实还是一直在写代码的过程当中着的。

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

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

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

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

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

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

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

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

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

至于实际应用中的场景——恩，先送本书让我学会了再说哈……
作者: zhj1011    时间: 2014-02-27 16:32
新的东西，了解下先。
作者: OwnWaterloo    时间: 2014-02-27 16:33
回复 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    时间: 2014-02-27 16:51
回复 12# starwing83

“只要编译过了程序就没错”确实很diao啦。 但另一方面，处理其他一些问题的时候，比如xml： http://hackage.haskell.org/packa ... ML-Light-Types.html 。
静态类型会不会太不方便了？
作者: HappyPonder    时间: 2014-02-27 17:10
本帖最后由 HappyPonder 于 2014-02-27 17:11 编辑

函数式编程是数学思维的计算机体现啊！语言的先进性总是比实用性早~
作者: starwing83    时间: 2014-02-27 20:44
回复 15# OwnWaterloo


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

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

对于xml这种情况……我觉得发展DSL是一个出路，比如xpath神马的，语言内DSL或者嵌入式DSL都可以接受……
作者: beyondfly    时间: 2014-02-27 21:53
接触函数式编程的契机以及学习并使用函数式编程的动机。
   接触过erlang，主要是没有学过函数式编程语言，想熟悉一下这方面的知识。erlang在海量并发的应用中具有很大的优势，原因是其内置的虚拟机机制。
作者: OwnWaterloo    时间: 2014-02-28 00:39
回复 17# starwing83

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


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

没有类型的json是很容易吃亏的，反正……
作者: Monox    时间: 2014-02-28 23:22
回复 19# OwnWaterloo

因为Haskell是强类型语言，这是需要（准确来说是能够）定义那么多类型的基础，也是编译通过就没什么错误的很重要的因素之一。并不是说你一定得那样定义，Haskell里也有字符串，列表，数字等等其他脚本语言里有的数据结构，你完全可以只用这些结构完成对XML的解析，但是正因为Haskell的强类型语言加上你自己可以定义很多类型，而这又是一个强大而有用的工具，所以还要去自己定义的，不是必须得去自己定义，而是有必要自己去定义。强类型首先可以保证笔误导致的类型错误等等的bug在编译阶段就可以全部排除掉，另一个是自定义的强类型事实上提供了一种处理数据的统一接口，真正体会了，会觉得和面向对象在本质上有很多相识的优势和特点，甚至比面向对象的方法更灵活方便。
Haskell是强加了很多束缚，但是正是因为这些束缚开启了另一片天地，让它在另一些方面更自由、直观、简单。你知道在Haskell里树型结构表示起来有多自然吗？你知道利用所有这些技术，用Haskell的Parsec库进行语法分析有多简单吗？

我就不进一步展开了，因为最近正忙着找工作，心情都不怎么好，并不想考虑如何回答顶楼的问题，只是实在想回一下19＃的问题，但是也不想继续深入了，实在实在没心思。

不过，话说回来，顶楼有一个问题是如何接触函数式编程语言的，我就奇怪为什么没人说是因为Pugs项目而开始接触Haskell的呢？这个论坛和我一样因为Perl 6开发史上的Pugs项目而开始接触Haskell的人应该还是蛮多的吧。
   
作者: _____BlueGuy_    时间: 2014-03-01 01:33
提示: 作者被禁止或删除 内容自动屏蔽
作者: dfsr    时间: 2014-03-03 10:37
Haskell刚刚开始，看Real World Haskell到第二章。
Scheme也在学，在Windows下，使用DrRacket，Haskell在Linux。
我是一名编程爱好者，主要用C，创造的快乐让我停不下来。学习函数式编程主要是听说Lisp是为人工智能而生的，而我正在开发自己的操盘辅助系统。
Haskell我刚刚开始，连门还没有进。但是有一点我很喜欢，就是它对数字的处理，整数、小数自动处理，不需要显示声明，很符合人的思维习惯。
我的计算机第一堂课，编程老师就说我们学的vb也是一门语言，是人机对话的语言，那是二十几年前的事了。比较而言，Haskell更自然，更符合人的模式（我才看了两章书，妄下结论，高人见谅！）。
作者: jieforest    时间: 2014-03-03 17:19
回复 14# OwnWaterloo


    这问题还真没注意过，我们团队的Java环境长期使用的是同一个版本，Scala的编译也使用的同一个JDK版本，还从未注意到这个问题。等空闲的时候我可以做个测试。
作者: 刺客阿地    时间: 2014-03-04 12:39
路过，看看。。。霸气的楼主！
作者: goingstudy    时间: 2014-03-04 16:24
本帖最后由 goingstudy 于 2014-03-04 16:25 编辑

最近刚开始学函数式编程，但不是学的hasksell，而是学的oCaml，应该思想上差不多吧
1. 学习的契机，其实很早就想学一下函数式编程，但是在上学到过程中实在是没有用到的机会，但是在接触到Xen后，又了解到Xen 的一个子项目Mirage OS（估计没几个人知道，http://openmirage.org），感觉挺有趣的，而且这个项目好像时间还不是很长，希望能参与一下，而且与Xen相关，又是用oCaml作为主要的开发语言，因此就学了。
2. 还没工作，不过作为Xen的一个子项目，感觉Mirage OS还是很有发展前途的，而且搜了一下，发现好像有个很有名的金融公司JaneStreet 就是用oCaml作为主要语言的。
3. 个人觉得函数式语言还应该是主要用在对稳定，安全要求比较高的地方，如银行，证券公司等，国内还没有听说哪个银行用了，当然好像阿里的Erlang用的挺多，对并发要求高。
p.s. 发一下牢骚，为什么functional编程版那么冷清，问个问题，没个人来回答，刚开始学，这个思维还是有点不大适应，还是挺费劲的，没个人指导下
作者: folklore    时间: 2014-03-05 10:28
版主好，
版主吉祥～
作者: sdau    时间: 2014-03-05 14:10
不明觉历....
作者: mqiezi    时间: 2014-03-05 21:20
**函数式编程的契机以及学习并使用函数式编程的动机：
我是个实用主义者，学习的主要目的就是以用为主。在OO思想充斥的**中，能够不拘泥于一种风格，灵活实用是我最大的学习目标和动力。

在实际工作中使用函数式编程的经验：
这个说实话，还真没有，虽然了解了一些但是还没有深入到用的层次上来。这本书是一个基础学习类型的书，应该比较适合我。

函数式编程在实际应用中的前景：
OO讲究的面向对象特征在一定层次上说就是一种高层次的抽象组合。抽象从宏观概念上来说，应该包含不止一种的层次，比如函数层的抽象、算法层的抽象、语言层的抽象，对于这些等等。函数式编程在我的理解中是对算法的一种语言级抽象。当然因为所知有限，可能说的不全面。函数式编程应该在算法复杂度较高的项目中有广泛的应用前景。
作者: MMMIX    时间: 2014-03-06 09:08
starwing83 发表于 2014-02-27 16:01
现在用命令式的脚本很多，函数式已经几乎很多年都没用过了，但是函数式的一
贯思想，其实还是一直在写代码 ...


很新颖独特的角度，算是对“函数式语言一旦学习，你以后的代码就会留下它的印记”的一个注解吧。
作者: sdau    时间: 2014-03-06 10:27
跟lisp类似么？
作者: fender0107401    时间: 2014-03-09 17:04
函数式编程貌似没有什么实际应用吧。

我感觉有OOP就足够了，不需要其他的编程范式了。
作者: kwest    时间: 2014-03-09 22:17
听说过，没用过。
作者: liuhua11    时间: 2014-03-10 17:22
提示: 该帖被管理员或版主屏蔽
作者: Hugo801122    时间: 2014-03-11 00:49
学习了！很不错！
作者: cuusrname    时间: 2014-03-11 23:54
传说中对提升逼格有着深远影响的语言。。。
作者: MMMIX    时间: 2014-03-12 09:54
本帖最后由 MMMIX 于 2014-03-12 09:56 编辑
fender0107401 发表于 2014-03-09 17:04
函数式编程貌似没有什么实际应用吧。

你还真敢说：
1. http://homepages.inf.ed.ac.uk/wadler/realworld/
2. http://en.wikipedia.org/wiki/Fun ... ing#Use_in_industry
3. http://programmers.stackexchange ... ctional-programming

我感觉有OOP就足够了，不需要其他的编程范式了。


其他人可不这么想。
作者: fender0107401    时间: 2014-03-12 09:57
MMMIX 发表于 2014-03-12 09:54
你还真敢说：
1. http://homepages.inf.ed.ac.uk/wadler/realworld/
2. http://en.wikipedia.org/wiki/ ...


有什么不敢说的。
作者: xcltapestry    时间: 2014-03-12 22:05
纯围观，听说过Haskell，是因为唐龙要用这个重写Perl，刚看了下，不适应。书的配图真好看。
作者: Monox    时间: 2014-03-13 08:45
回复 40# xcltapestry

不是唐龙，也不是重写Perl，那个人以前叫唐宗汉，现在叫唐凤。所做的事是开发了一个叫Pugs的东西，这个Pugs是对Perl 6的一个尝试性的实现。Perl 6和一般所以的Perl(也就是Perl 5)基本可以看成是两种不同的语言，所以不能说重写，而另一方面，Pugs出现之前也没有一个完整的Perl 6的实现（现在也仍没有特别完整的实现），所以Pugs也不是对Perl 6的重写。
   
作者: Okelani    时间: 2014-03-13 10:04
本帖最后由 Okelani 于 2014-08-14 15:56 编辑

好多没见过的呢！
作者: xcltapestry    时间: 2014-03-13 14:37
回复 41# Monox

牛人啊，我凭印象说的，受教了。
   
作者: cokeboL    时间: 2014-03-15 12:40
老是把书给那些言之有物的。。。言之有物的都会了，为了普及应该给不懂的！
作者: OwnWaterloo    时间: 2014-03-15 17:04
回复 21# Monox

我也并没有说Haskell一定得这样，而是大部分Haskell程序库倾向于这样。

就xml来说，我不觉得前面提到的Text.XML.Light.Types会比

  2. ["pre" {"class" : "json"} subnodes...]
复制代码
更简单。

并且一旦定义一个新的类型，就丢掉了统一处理数据的方式。它需要特定于该类型的一个小语言。
Why have both deftype and defrecord?
It has always been an unfortunate characteristic of using classes for application domain information that it resulted in information being hidden behind class-specific micro-languages, e.g. even the seemingly harmless employee.getName() is a custom interface to data.

虽然上面是在说OO，但对Text.XML.Light.Types同样适用。
比如它就需要 http://hackage.haskell.org/packa ... XML-Light-Proc.html 里面的一堆特定于这些类型的操作方式， 不能继续使用统一的操作线性结构或关联结构的函数。

当然，在Haskell里还可以继续实现一些type class来回归到统一的处理方式，不过Text.XML.Light没有这样做。

总之，我前面想说的是，Haskell达到编译成功就可以排除很多运行时错误并不是凭空得来的，是通过写额外代码换来的。
定义特定的类型，定义该类型上的操作方式或实现特定的type class或两者兼有。
Haskell的优势只是提供了写额外代码的机制，即带类型推到的静态类型。而很多其他语言可能想写这样的额外代码都没机会。。。

关于Pugs。。。 因为我不会perl。。。
作者: OwnWaterloo    时间: 2014-03-15 17:15
回复 44# cokeboL

没能普及的原因是缺少书吗？
作者: Monox    时间: 2014-03-15 21:12
回复 45# OwnWaterloo

你在这楼的观点我基本认同，事实上，我上面回你帖的时候就想提OO的，事实上，根据我的理解，在Haskell里之所以有必要自己定义一堆的类型就像面向对象语言里需要定义一大堆的类是一样的。在很多面向对象语言中类都不是必须定义的，但是大多数人还是倾向于定义更多的类来处理特定的数据类型。当然面向对象的编程技术也是倍受争议的领域。不过另一方面，我之所以之前没有拿面向对象来类比，是因为Haskell的自定义类型在我看来比类更强大灵活，因此显得更有必要。这个特性确实是Haskell写出来的程序只要编译通过就几乎没有bug的一个很重要的方面。事实上这种特性对于避免bug进最终的程序是如此的重要，像Ada这种（可能）比Haskell更有名的语言虽然不是函数式编程语言但是也提供这种特性。而Ada就是为了开发安全的军用软件而开发的。
    另一方面，我这里就不评论Haskell的代码简单与否了，这个是多方面的问题不太好说，很多事不能说要么是0要么是1，世界是多元的。我对Text.XML.Light.Types并不熟悉，这个库也并不一定是Haskell里解析XML的代表库，并不一定写得很好。我倒是用过HXT这个库，这个库用了很多Haskell里比较高级的概念和技术，比如Arrow之类的，接口啊什么的就设计得很简洁很有Haskell的味道，而且不同的解析结果可以很好的统一处理，统一处理这个并没有使用type class的技术。在Haskell里type class虽然很强大，但是并不是唯一的技术，而且很多时候并不是最好的技术。
Haskell达到编译成功就可以排除很多运行时错误确实需要通过写额外代码来换，但是这并不表示Haskell会增加代码的复杂性和长度。有三个方面的原因，首先，这些额外的代码并不仅仅是为了达到编译成功就可以排除运行时bug，很多都是为了和Haskell的其他子系统进行整合。而这些整合的代码恰恰可以用来降低整体代码的复杂性和长度。另外，正如前面提到的，写C++之类的，也要写类啊什么的很多额外的代码，而这些额外的代码常常会导致代码过于复杂，并且降低可扩展性，从而在需要扩展的时候又要增加更多的代码。第三，我忘了我要说的第三点了，算了。
唉，其实我也不是不想说Haskell也有很多问题了，并不想说Haskell就是最好的语言，更何况我自己对Haskell的了解也很有限。不过，我觉得只有自己真真去体会Haskell的设计思想和决策并真正的爱上那些特性才能体会那些特性到底有多好，而另一方面其他人坚持说那些特性没有说的那么好什么的我觉得这些也无所谓，任何试图把自己的想法强加给别人的尝试总是会以失败告终。所以，是不是别人说的那么回事还是自己去判断要好点。
结论是我很喜欢Haskell，不在意其他人不喜欢Haskell，更不在意其他人试图让我相信Haskell没有传说的那么好。

或者，再多加一句话吧（其实我写这帖是让自己不去思考，让文字跑到我的指尖的时候按下键盘写成的），像Lua只有一种数据结构，叫做列表，它一样工作得很好，我觉得拿一种语言和另一种语言比并没有什么太大的好处。在Haskell里到底要不要自己定义类型也是写代码的人自己决定。写C++的人也一样可以一个类也不写，不过，什么是好代码，什么不是好代码那是另一回事了，更何况这个Text.XML.Light.Types也并不一定是好代码。好吧，我真不知道我都写了些啥，为什么写这些内容，唉。
作者: pitonas    时间: 2014-03-16 19:27
刚看了下，维基百科
  1. 唐龙（1477年－1546年），字虞佐，浙江承宣布政使司金华府兰溪县（今浙江省兰溪市）人，明朝政治人物，官明朝吏部尚书、刑部尚书、兵部尚书，同进士出身。
复制代码
你还真敢说

回复 40# xcltapestry


   
作者: pandaiam    时间: 2014-03-18 09:25
哈哈，ow主持的啊，一直没看到。


得反省下自己，除c外，有过了解common lisp， scheme，haskell，erlang
最近在看golang。
cl买过实战编程，看了不少章，但写的都是书上的例子。
scheme的用ikarus或者chez 学sicp，好像是两章半。
haskell也是看real world和主贴里的这本书，rwh也是前两章。。。
erlang有买 erlang otp并发实践，看了几章。。。

这是我最大最大的问题，不能坚持，
内容简单的时候还可以，稍微有难度，需要有突破点的时候，往往突破不了就会放下，然后就慢慢健忘，转移了。
需要改变。

最近在用golang写个很小的blog程序，还是先坚持这个吧。
作者: OwnWaterloo    时间: 2014-03-19 02:15
回复 49# pandaiam

感觉Go的函数式风格不如你提到的另外几门语言那么强啊。。。
有空多分享分享经验呗。。。
我也想弄一个blog。。。
作者: OwnWaterloo    时间: 2014-03-19 03:11
回复 47# Monox

其实自己相比动态类型更喜欢静态类型一些。学Haskell的原因之一也是动态类型语言用多了总感觉有点心虚于是想找一个静态类型的语言来学。。。

而前面对Haskell静态类型的那些言论主要是为了避免自己盲从一些新技术。
除了它本身是什么之外，还包括它意图解决的问题、适合的领域、和其他解决方案的比较等等。
可能是C++留下的习惯吧，如果总想把学到的东西尽可能地用上，一般来说最终是会倒霉的。。。

关于选择Text.XML.Light。
因为当时需要解析darcs的输出，于是根据这里的推荐：
I would recommend:
    xml, if your task is simple
    haxml, if your task is complex
    hxt, if you like arrows
    hexpat if you need high performance

没有多余的时间一个一个尝试而选了（他说的）最简单的那个。。。

关于统一处理，我的意思这样的。
如果有一套函数能统一地将[(k,v)],Map k v,以及xml里的attributes等等当作关联性容器处理而不是分别使用Prelude.lookup, Data.Map.lookup或者Text.XML.Light.Proc.findAttr各自一套，那么根据问题领域定义不同的类型也没什么问题。
所以才提到type class。
而Arrow不是解决这个问题的吧？ 还是我理解错了？
作者: Monox    时间: 2014-03-19 08:59
回复 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    时间: 2014-03-21 23:58
typeclass应该跟c++ concept最接近，不过c++引入类型推导后，也应该可以通过非侵入式接口自己设计实现monad这样的东西了。
我觉得函数式本身跟类型是两个侧面，只是搞形式验证这帮人肯定是一起都做的，函数式本质应该是算法抽象，控制流程的东西，当然有类型lambda后，类型也可以一起计算了。类型计算方面，c++模板也很强大了，现在有了自动推导，估计不弱于haskell，反正我看到很多人叫嚷着要做monad库。
然后说一个很本质的东西，continuation，函数式编程的很大一部分好处都是基于这个上面的，有人说continuation是一切调用之母，我深以为然，在haskell里，continuation monad可以实现所有其他的monad，所以也是monad之母。
所以除了语法外，最新的语言基本上都涵盖了这些内容，没有本质谁强谁弱的问题，以后还是改进语言本身，meta programming，DSL之流，我看很多新的语言被热捧，里面引入各种各样的新表达方法，但也增加了噪声，如何更加一致起来，是未来语言要考虑的一个问题。
作者: _HellAngel_    时间: 2014-03-22 18:30
本帖最后由 _HellAngel_ 于 2014-03-22 18:35 编辑

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

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

恩，大概就是这样= =。（纯水贴。。。。。。。）
作者: uxyzp    时间: 2014-03-24 21:01
接触契机：最近在学Python，而Python是一门多范式的编程语言，它同时支持过程式、面向对象和函数式的编程范式（我不是来拆Haskell台的）
使用动机：暂无非常明确的动机，仅为拓宽思维，因为听说函数式的历史更悠久……
实际经验：也就写写运维脚本，还没深入挖掘函数式的好处……还是说我的工作任务不太符合函数式？
应用前景：我觉得是在数学建模方面……
作者: OwnWaterloo    时间: 2014-04-13 07:08
回复 55# uxyzp
The fate of reduce() in Python 3000
恐怕Python的作者不是这样认为的。
作者: OwnWaterloo    时间: 2014-04-13 07:10
回复 54# _HellAngel_
ML这梗都用烂了。。。
作者: OwnWaterloo    时间: 2014-04-13 07:21
回复 53# zhouzhenghui

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

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

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

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

各种新表达方法确实很不和谐。。。
作者: OwnWaterloo    时间: 2014-04-13 09:04
回复 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是操作与对象耦合，于是它就没法：

  2. minBound :: Bounded a => a
  3. maxBound :: Bounded a => a
  4. mempty :: Monoid a => a
复制代码
等等。 要实现：

  2. (==) :: Eq a => a -> a -> Bool
  3. (+) :: Num a => a -> a -> a
复制代码
等等也会比较麻烦。
像

  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    时间: 2014-04-13 11:56
回复 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_    时间: 2014-04-18 13:03
回复 57# OwnWaterloo


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



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2