Haskell 可能永远都不会变成主流

Posted SegmentFault

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Haskell 可能永远都不会变成主流相关的知识,希望对你有一定的参考价值。

【编者按】 和大家一起学习了《类型与函数》,作者 @garfileo 就翻译的一系列关于范畴论的文章发表了自己的看法,认为 Haskell 可能永远都不会变成主流,想知道为什么吗?




这两天一直在翻译 Bartosz Milewski 所写的《面向程序猿的范畴论》。虽然已历时近 1 年,但这本书只写完了 2/3。从这一点也差不多能够反映范畴论还是挺难解释的。


3 年前,Bartosz Milewski 写过一篇文章专门讲单子的,我曾经翻译了过来,详见『对单子的求索』一文。虽然我是逐句认真翻译的,也差不多能理解作者要表达的东西,但是总觉得对于我自己写的一些程序,用 Haskell 这种高度抽象的语言,感觉是舞着屠龙刀来切白菜。


Haskell 这种级别的语言,似乎是为了大型的并发或并行计算程序而设计的,对数据类型与函数的副作用进行严格的控制,有点像动车或高铁……而传统的命令式语言则类似其他交通工具。C 语言像我的美利达勇士600,动态语言像汽车,C++ 像绿皮车,Java 像空调普快……JS 之类的,像是滑板,搞 Web 前端的不要打我。一般的小规模软件,即使是办公软件这种级别的东西,用 Haskell 都有些大材小用了。


插句题外话,感觉段错误网站有点奇怪,这里的居民似乎大部分都是做 Web 前端的……他们的程序几乎不会遇到段错误……话说,自从我用 fishfish 替代了 Bash 之后,再也没收到段错误的信息,因为 fishfish 只会告诉我内存越界什么的。不知道有没有叫『404 错误』的网站……


3 年前,我大概用了有两三个月的时间学习 Haskell,现在很惭愧的说,我已经把它忘的差不多了。还剩下唯一的印象就是,它的代码相当简约……相当于很难产生歧义的文言文。因为你的代码稍微有些不严格,可能就无法通过编译。


当时学习 Haskell 的过程中,我打算写一个文学编程工具。结果写了也就百十行代码,发现再也写不下去了,因为我实在是不知道怎么去修改我的语法树里某个结点存储的数据。我不知道《Real World Haskell》的哪一章能告诉我如何解决我的问题,《Learn You a Haskell for Great Good!》似乎要到最后一章有我想要的东西,然而在此之前我必须得懂单子。


几乎每个学习 Haskell 的人都会去写一篇关于单子的教程……而我做的,就是翻译了 Bartosz Milewski 写的文章。我看不懂《Real World Haskell》里的单子内容,主要是没有耐心,因为 RWH 里面大量的前向引用……等你看到单子那一章时,前面的内容估计也忘得差不多了……LYAH 里面,对单子的阐述理解起来倒是不困难,然而我不是那种天资聪颖的人,即使我看了个差不多明白,我依然不知道怎么去解决我要修改语法树中某个结点内容的问题。


我觉得我得在 Haskell 上至少失败 10 次才能 hold 住它。从这一点而言,我很羡慕那些用 Haskell 就跟喝白开水一样的人。不过……也没看到他们写出来真正能体现出来 Haskell 优势的程序。我知道诸如 xmonad,pandoc 之类的东西是 Haskell 实现的,但是用 C++ 实现的巨型程序已经汗牛充栋了。


在理论上,Haskell 对并发、并行计算的支持胜过任何一种命令式语言,但是不可否认,现在正在运行着的并发、并行程序,它们可能大多数是用命令式语言实现的。虽然命令式语言的贫瘠的数学基础导致它的行为脆弱不堪,但是它们已经在运行着,而如果将这些正在运行的程序彻头彻尾的改造成 Haskell 需要多少年?


程序猿们趋向于选择自己更容易掌握的语言。即使是 C++,掌握起来都比 Haskell 容易了 10 倍。C++ 只是庞大且繁琐了一些,但是它的任何一块知识,中学生都能够理解。在现实中,繁琐的简单总是会『战胜』简洁的复杂。


大部分人有个『天下兴亡,匹夫有责,但我无责』的毛病。例如,面对日益糟糕的空气,人人都知道环保的重要性,但是似乎大部分人却不关心自己的行为是否环保。最简单的例子,高校里教书育人的老师们,他们的家一般就在校内,他们要是去上班,徒步也就顶多 15 分钟而已,但是他们依然开着车去……就连宇宙重启这么重大的事,圣母程心依然想留下 5 公斤的质量不归还。这其实是人类的通病。孔子说,吾未见好德者如好色者也。这条人类定律迄今依然发挥着作用,看看那么多的人已经心甘情愿的沦落为手机的人肉电池就知道了。龙文章说,死都不怕,就怕不安逸。大部分程序猿毕竟还是普通人,他们或许宁愿去做逐渐被加热的命令式语言中的青蛙也不愿意跳到冰冷的 Haskell 世界。这也是 Haskell 在面对的现实。


我觉得 Haskell 的方向是对的,但是与这个方向密切相关的领域,现在还不是主流,这就决定了无论 Haskell 的爱好者如何布道, Haskell 也就无法变成主流语言。Haskell 可能永远不会变成主流,但是它所提出的那些技术很有可能会逐渐注入到现在的主流语言体内,就像当年的 smalltalk 那样,就像现在还活着的 lisp 那样。


大规模的并发计算也许不是那么难以解决,Haskell 取消了变量的赋值,用函数之间传递参数来模拟状态的变化,并提倡用数学证明来保证程序的正确性,经过这一系列措施所改造的程序,你能想象得出它最终会是什么样子么?我觉得最终它像极了人类。人类这个群体,天生就是并发与并行的计算体系。我们每个人都像是一个超级函数,我们各自计算自己的,然后通过语言、文字、肢体动作等通信协议来协作,而不是你直接在我的内存里修改我的计算结果。如果 Haskell 的程序进化到像我们这样『完美』,似乎它也会像我们这样低效:奔跑不如豹子,视力不及苍鹰,力量不及熊罴……人类达到今天我们认为是『快节奏』的现代文明社会耗费了上百万年,Haskell 真是任重而道远。


要知道 Haskell 程序与人类的相似程度,唯一的办法就是借助范畴论,看看这两个范畴能不能形成映射。我学习范畴论去了……



-EOF-


回顾阅读:




阅读原文,和出色的作者神交吧。


专业的开发者技术社区

多样化线上知识交流

丰富线下活动和给力工作机会

以上是关于Haskell 可能永远都不会变成主流的主要内容,如果未能解决你的问题,请参考以下文章

C语言/C++永远都不会过时的编程语言

CoreData:Ubiquity:使用本地存储:1 永远不会变成 0

Haskell:从 ST / GC 泄漏内存不收集?

Rust 变成主流?GraphQL 持续走高?2020年编程新趋势都有啥?

“为什么卡尔达诺用Haskell?难道IOHK将永远运行Cardano项目?

有人可以用*非常*简单的术语解释反射包 API 吗?