最近在思考系统设计相关的问题。代码层面的，如面向对象编程、函数式编程；在面向对象编程中的各种设计模式，函数式的使用场景等、还有微服务系统设计的模式等以及DDD，到CAP与BASE等分布式理论。从代码层面到系统层面的思考。内心抛出来几个问题？
- 函数式编程的函数是第一公民，函数是可以作为参数的，那么数据呢、数据是否可以转化为函数去放置？范型编程的思想，到最终能不能也是一个函数呢？那么静态程序语言的类型系统又能有什么作用呢、或者换句话说不能仅仅是动态类型吗？
- 函数式是无状态的，所以处理并发肯定没有竞争，为什么不将所有的并发问题都转化成函数式编程呢？
- 面向对象编程与现实的思想那么靠近，将数据与操作抽象为一个类，大多数人都是可以对应出相应的系统设计的（前提是有足够的背景知识），而设计模式会提供很好的管理类的框架，让我们把管理与业务逻辑隔开，当然这里也需要很多对继承、封装、抽象的理解。而在单体设计以及微服务设计则是基于整个系统层面对软件、机器、人力的整体权衡，毕竟康威定律、pizza法则这些都在。而DDD是微服务设计的业务层面的思路集合对吗？
- 。。。。
在机缘巧合之下，我想起了《计算机程序构造和解释》这本书。带着这些思考，我过了下整本书，解答了我几个疑问。特别是一个并发的问题，以及函数的状态问题。为了方便思考，因为之后会基于函数式、面向对象等角度去深入看这本书。
这本书使用lisp这个上古语言写的，有一些章节在引入语法的时候，会带入一些编程思想，读起来又晦涩又舒服，晦涩是里面很多都是基于数学相关（如不动点、牛顿法等）以及对lisp的不熟悉，舒服是它的组织结构让你感觉很像读《think in java》的感觉，把编程思想无声无息的带给你，以及它在3章开始后对一些技术的思考，让我很是受益。
比如，它从函数式的代换模型讲到引入赋值操作后环境模型带来的收益以及问题（有一点对我是比较深刻的，可能是我之前一直有研究并发相关的问题），赋值后在函数中引入了状态，而状态带来了不确定性，如果并发的操作同一个带状态的函数，那么将出现问题。我当时读到这一段的时候，我串起来一件事情，为什么会有并发问题，是因为并发操作同一个数据，而并发处理同一个数据就是set了同一个内存地址（这里书上有提到），突然间哪些通了一些东西如内存屏障、CAS、互斥通信这些技术。那如果我不想引入这些问题，那我能不能做到向函数式编程这样呢？用代换模型已经能保证数据的正确性操作，无状态的，那就让我想到了读写分离（涉及到拷贝）等技术。
还有，这本书介绍了无状态的函数式、以及有状态的面向对象编程。让我在软件设计这块又串联了些知识，以及分离了些知识。后面还有解释器、寄存器这些好玩的事情。所以，会持续更新这一块的感想。
ps：最近一直在思考怎么写博客，我持续学习俩年多了，感觉好多东西想写，又一直不敢写，想了很多都不敢下笔，也存了很多草稿。看了一篇文章，感觉给自己加了太多戏了。语雀学习日志
[BetterExplained]为什么你应该（从现在开始就）写博客
http://mindhacks.cn/2009/02/15/why-you-should-start-blogging-now/ [BetterExplained]为什么你应该（从现在开始就）写博客
https://coolshell.cn/articles/10169.html 类型的本质和函数式的实现（耗子叔的 R.I.P）
