十年学会函数式编程:Type Class

上一篇博客中我们聊了ADT,我们知道了ADT也是关于类型的,我们还和面向对象的class做了比较。此时再看到 type class 这样的词语是非常崩溃的,我的天呐到底还有多少和类型相关的专业词汇。Type 我也认识,Class 我也认识,合到一起又是什么鬼?Type Class 确实又是一个难以理解的概念,我觉得难理解和名字起的不好有很大的关系。词汇真的是匮乏,又不能凭空造一个词出来。但是 Type class 又是必须要理解的一个概念,不然的话可能连 cats 的文档都看不懂。

十年学会函数式编程:ADT(Algebraic Data Type)

几乎每一本讲 FP 的书里都会提到 ADT 这个概念,但是好像没有人彻底讲的明白,所以我之前一直不理解。ADT 到底是什么呢?Algebraic 这样的词让人一看就很头疼,写个代码怎么还跟代数产生关系了呢?让我们看看维基百科上的定义:In computer programming, especially functional programming and type theory, an algebraic data type is a kind of composite type, i.e., a type formed by combining other types.

没有什么特殊的,只不过是一种组合类型,由多种其他类型组合而成的类型。Algebraic 是体现在哪里呢?Haskell wiki 是这样描述的:

  1. sum is alternation (A | B, meaning A or B but not both)
  2. product is combination (A B, meaning A and B together)

Algebraic 体现在组合的方式上。把 product 换成 and,sum 换成 or,是不是就容易理解了?product 是 X has an A and a B,sum 则是 X is an A or B。虽然 ADT 看起来很复杂,但其实我们每天都在用,只是没有意识到背后的概念罢了。

十年学会函数式编程:入门的最差实践

不知道大家有没有类似的体验,有些概念如果直接告诉你它是什么,无论如何都理解不了。但是如果再告诉你它不是什么,可能就恍然大悟了。同样的,有些事情告诉你怎么做(Dos)往往不如告诉你别怎么做(Don’ts)来的更有效。回顾我学习FP的历程,确实存在这样一些最差实践,如果避开这些坑,入门应该是不需要十年的。

十年学会函数式编程

Peter Norvig 大神多年前写过一篇 Teach Yourself Programming in Ten Years,阐述了为什么学习编程是持久战,没有捷径可以走,以及应该怎么去学习编程,每个程序员都应该看一看。里面有句话讲得特别好(不仅仅局限于编程领域):

The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.

Peter文章的“十年”是个夸张的说法,主要是为了强调学习编程没有捷径,引导大家摆脱急功近利的心态,他学编程当然不需要十年。我的这篇文章标题差不多,就多了一个Functional,但我是真的用了十年的时间才学会的,而且顶多只能算是入门而已。所以对我而言十年并不是夸张的说法,是智商真的有限。

其实函数式编程(Functional Programming,以下简称FP)并不神秘,只是很多人把它吹得过于神化了。

Protocol Buffer高阶玩法:如何优雅地批量修改proto文件

每个程序员少不了和Protocol Buffer打交道。Protobuf现在几乎已经是业界标准了,设计rpc接口协议不会考虑其他的选择。可能也有人喜欢造轮子发明自己的一套协议,但是请相信我,造这种轮子除了可以用来汇报之外(前提是先说服老板允许你浪费时间造轮子),基本上不会给公司业务、后台服务上带来什么效率的提升。Protobuf有诸多家喻户晓的优点,比如广泛的支持各种语言、具有良好的版本兼容性、体积小解析快等等。作为后台协议这些特性可以说是基本的要求。但是protobuf之所以这么优秀,我认为还离不开它丰富的api和可扩展性。

Why Emacs?

Emacs已经陪伴我十几年了,称得上是第二个人生伴侣,只要开电脑就习惯性地打开Emacs。内心由衷地感谢Richard Stallman,开发出这样一款编辑器,给平淡无奇的程序员生活带来许多乐趣,是时候给Emacs写一篇软文了。Emacs诞生于1972年,可以说是相当古老了。现在已经2021年了,这个老古董还能继续用吗?

Done is better than perfect

又发现了自己的一个缺陷,不管做什么事情都像绣花一样慢,事情做的是不错,但是效率极其低下。比如,博客文章从开始写到发布至少要经历两三周,各种精雕细琢,但就是迟迟不能发布,总觉得还少了点东西。就是追求完美,一定要做到无可挑剔才行。实际上完美是一种永远都不可能达到的状态,从0到80分很容易,从80到99的时间是指数上涨的,从99到100,一定要耗费巨大的精力和时间。

逃离舒适区

所有生物都是趋利避害的,人也不例外,本能的都想让自己更舒服一点,少遇到一些挫折和痛苦。“不要停留在舒适区”的道理大家都懂,我也从来不认为自己还在舒适区。最近反思了一下,发现舒适区比我的认知要大很多,我以为自己走出去了,其实并没有,还是在这个圈子里面,这比心甘情愿留在舒适区还要可怕。今天来深刻反思下我犯过的一些错误。

该不该用-webkit-font-smoothing?

跟InfoQ中文站、36kr这些国内的站点对比了下,发现我博客上的字体非常的别扭,尤其是在外接显示器的情况下。但是看用的字体也是一样的,都是PingFang SC,为什么呢?于是把css一行一行的拷贝过来测试,最后发现是下面这两句导致的差异。

body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

之前看起来字体非常的粗,都挤到一起了。加上这两句,体验好多了,变得异常的清晰。在Retina屏幕上变化不算明显,但是在2k分辨率的外接显示器上,完全是两种体验。

体验问题解决了,还想再深入了解下原理,看看MDN上的介绍。这两个样式都不是css标准样式,而且仅在Mac下生效。font-smooth曾经是标准的,但是后来被移除了。MDN上有红框警告,建议在生产环境不要使用该样式。看到这个警告,内心开始产生怀疑了,用这个是不是有什么坑呢?

又搜索了下,发现有人在google font的仓库里面提issue,希望去掉google font页面的-webkit-font-smoothing样式,因为这会导致字体与实际的表现不同。作者也出来回应了,“谢谢你的建议,但我们还是要保留,因为要以最好的状态来展示这些字体”

另外还看到一篇文章建议不要再使用,Please Stop “Fixing” Font Smoothing。里面提到了,让浏览器自己选择才是最好的,次像素防锯齿才是最好的,即便开了antialiased看起来更舒适,但那也是不对的。说了一大堆道理,恳求大家不要再用了。讲真的,我差点就信了。为了确认下作者是不是在说实话,我打开Inspector检查了下,看到了下图。

幸好没盲目的听作者的。文章比较老了,不确定是不是作者写完文章后来又改变了想法把它加回去了。即便如此,那也应该更新下的。这篇文章出现的频率还是很高的,不知道会误导多少后来的人。其实有很多官方的Guideline也存在同样的问题,比如苹果的开发者文档,经常文档里面说一套,官方的app又不遵守。所以这些规则和最佳实践可以去参考,但是没必要盲从。还是要结合自己的具体场景做出选择。

顺便看了看其他网站,基本上都有使用,比如苹果的开发者文档、MDN文档。所以放心大胆的用吧,没有任何的副作用,这才是最佳实践。

Clojure开发初体验

先说说我为什么想试下Clojure。作为Emacs的忠实用户,有时需要用Emacs Lisp实现一些功能,但是Emacs Lisp的文档写的比较简洁,网上相关资料也非常少。很多时候都不了了之了。后来发现,有些基本概念是Lisp系语言共有的。搞不懂的问题,可以查查其他Lisp语言的资料,或许能有答案。

因此萌生了系统性学习Lisp语言的想法,想看看冰河翻译的Practical Common Lisp。但是如果看完只能解决我使用Emacs的问题,好像成本有点高了,毕竟Common Lisp不能拿来干活啊。

除了Common Lisp还有别的选择吗?当然有,那就是Clojure了。做为一门Lisp方言,Clojure有着优雅的语法和强大的表达能力,最关键的是真的可以拿来干活。跟Scala、Kotlin一样,Clojure也是基于jvm实现的,这意味着有大量成熟的Java生态的工具可以直接使用。

书籍

第一个步骤肯定是找些书来看看了。经过我的搜索,这些书都还不错,可以挑一些来看看。