谢谢邀请。
程序世界里,选择了一门语言,实际上也同时选择了很多东西:一种思维方式,一个平台,一个社区,往往还限定了一个工程领域。所以,选择一门语言没有那么简单。
思维方式而言,两者相差并不多。考虑到函数式编程并不是如今程序开发的主流,无论是 Lisp 还是 Haskell,它们和主流工程实践都相差很多。但具体到函数式程序设计语言之间,基本的思路是类似的。函数式程序设计的风格的实质:去除赋值的副作用,自包含上下文的高阶函数,以「值」的流动而不是操作的变化为中心设计程序,这在两门语言中都是一样的。当然,在细节上两门语言仍然有区别:Lisp 的宏展开,弱类型/动态类型,Haskell 的惰性求值,强类型,都有各自的区别。具体开始使用时,需要注意其特性才能用好。
在社区上,Lisp 有固定的社区,但由于大量 Lisp 方言的存在,导致如今的分裂得很厉害。除了 Common Lisp 这个大型社区外,还有各种小型 Lisp 社区,星罗棋布。这使得 Lisp 社区事实上很难形成合力做出一个各个方言通用的平台——是的,即使 Common Lisp 是最大的社区,从源流上看,它也依然是方言之一。我必须承认,这一点上 Haskell 要好得太多。Haskell 的社区通过
http://www. haskell.org很好地被统一在一起,无论是教学还是开发,都容易集合整个社区的力量。
谈到工程领域,至少目前为止,Haskell 社区在宣传时一直是将其定位为一门通用程序设计语言的。但恕我直言,现在这个社区还没有找到真正适合自己的工作场景,或者说,这个社区的成熟程度还不足以支撑一个适合自己的工作场景。在我的眼里,这个社区的核心,仍然是一门玩具语言。反观 Lisp 社区,他们的应用场景简单而专注:符号推演和人工智能;与此同时,许多 Lisp 方言也将自己的触角伸进实际工程领域,配合其他语言使用。也有 Emacs 和 Gimp 这样各自领域内公认的通用软件。
注:不要误会,我对 Haskell 语言本身没有恶感。作为工具,语言无所谓好坏。但是,作为严肃的工程人员,我们应该理解这样一条基本原理:语言作为工具,它必须也只能立足于解决问题。但是 Haskell 这个社区显然不理解这样一条原则。这个社区一开始热捧的惰性求值,以及后来的 Monad,再到最近似乎又被拉出来宣传的所谓类型自动推演,无一不是这门语言本身的特性。而对比其他社区,我们不难看到,这个社区至今也没有生产出哪一个可以使用的,可以解决通用工程问题的软件。我知道 Haskell 爱好者会出来反对,但我仍然坚持认为:仅仅是满足于在各个公司里做一些边角的小工具,是不足以证明其作为通用程序设计语言的价值的。而即使是这个社区热捧的语言特性,在编译器理论中,事实上都不是新鲜事物。作 Haskell 社区曾经的一员,我很难想象一个社区会如此十几年如一日地陶醉在自己的语言特性中不能自拔。不过,公允地说,Lisp 社区中的一部分人中也存在这种恶劣的倾向;但是 Lisp 社区中专注于工程实践的力量能在相当程度上平衡这种缺陷,让社区保持清醒。
所以结论:Lisp 可以作为学习时的主力语言,和工业开发时的辅助语言。如果提问者的专业是符号推演或人工智能,Lisp 可以说是必须学的语言。至于 Haskell,我仍然要重复我在无数场合说了无数次的结论:有空可以玩玩 Haskell,但不要认为它是能够胜任工程实践的工具;尽可能避免接触 Haskell 这个社区,那不是一个健康的社区。
顺便说一句,如果确实希望学习类型系统和强类型环境下的函数式程序设计风格,我更推荐 O'Caml。这门语言的特性也许没有 Haskell 那么多,但其社区要健康许多。