think before coding

2010-03-28 黄毅

think before coding,使用haskell时会比较容易体会到这点,python让人倾向于快速编写可以工作的代码。 而haskell倾向于编码之前先建立函数式的模型,然后转换到代码,最后加上与外部有状态世界打交道的代码。

事实上,从很多haskell程序中都可以看得出来,当你对问题建立了一个完善严谨的数学模型后,转换到haskell代码非常容易,而且产生的代码很易读,甚至你会觉得问题本来就应该是这么描述的。使用haskell很容易构建dsl。

从静态类型的c++ java,到动态类型的python,再到静态类型的haskell。各有各的道理。对于高级语言来说,类型系统是他的灵魂,去除类型系统,c语言就成了汇编,python就成了字节码,haskell就成了lambda。

编程的核心是对问题或者说需求建立模型,类型系统就是用来在代码的层次建立模型的工具。就算是动态类型的python,好的python程序其内在也必然会存在一个良好的严谨的类型体系,python程序员在编程的时候脑袋里也一定装有这么一个类型体系去对应问题领域中的各种概念各种关系。既然如此,那为何不干脆选择一门静态类型语言呢,还能让编译器帮助进行类型检查,何乐而不为,用python干嘛。事实上是大部分的静态类型语言都无法提供组织我们大脑中的这个类型体系所需要的灵活性。不过要能用编译器实现出来的类型系统必然是严谨的固定的,而大脑凭空架构的体系常常并不严密,所以再好的语言与我们大脑的思维之间必然存在这个沟壑,换句话说在思维模型与程序模型之间转换的工作是必然的,问题只在于这个转换需要有多大。c++,java这些语言的表现显然是不够的,设计模式的复杂就证明了从我们大脑理解的模型转换到简单的OO类型系统有多麻烦,我想这也是python,ruby们这么火热的主要原因。而使用python的问题则在于,依靠程序员的大脑去维护模型中的类型关系常常不够精确,尤其是当系统变大以后,类型之间关系变得复杂后,完全依靠文档和程序员大脑对这些关系进行存储和分析就显得捉襟见肘了。

那么haskell会表现如何呢?我很期待,也是我正在学习的地方。


blog comments powered by Disqus

转载请注明出处,收藏或分享这篇文章到: