# 计算机领域的三个重要思想：抽象，分层和高阶

## 有关抽象

### “数学抽象”

Dr. Dan:

（客套话略）

I’m here to ask you a question that has confused me for a while. The story may be a bit long, and I’m genuinely sorry for that. Many of my friends have been devoted themselves to PLT for many years. And, as their friend, I noticed there is a deep connection between PLT and mathematics — especially those overwhelmingly perplexing and abstract subdisciplines, e.g. Abstract Algebra. As a programmer, I’ve also noticed that there’re many (and even more and more) articles are intended to introduce some algebraic concepts to programming, e.g. Monad, Functor. Most of these articles use some analogy like a box, funnel, to make them more understandable.

One of my friends has the following comment on these articles: he said that the only way to truly understand abstraction, is through abstraction, and inaccurate analogy cannot help. He said that to effectively (or even usefully) learn these abstractions, you have to learn mathematics, not some rough material, all it has is analogies.

This trend — perplexing words used to boast, perplexing explaining articles read to have nothing — is not good. Personally speaking, I think these abstract concepts are just not useful. Just knowing a Promise in JavaScript is a Monad per se, and Functor “is a box” could NOT help you being a better programmer. Using these words in your own library makes the newcomer feel uncomfortable.

So, here’s my question: What’s your opinion towards these abstractions, many of them are quoted directly from abstract mathematics? Can learn these abstractions helping me be a better programmer? And if I just “know” them but not “understand” them in a more abstract manner (which is the Abstract Algebraic), can I still be a better programmer? Would you recommend a “Joe Coder” to learn or use these words during his career? Will you write some easy-to-read articles to make “Joe Coder” learn them by showing them bunches of analogies?

My personal answer is No. And here I quoted a paragraph from Bjarne’s paper and is said by Alexander Stepanov:

At that time I discovered the works of Euler and my perception of the nature of mathematics underwent a dramatic transformation. I was de-Bourbakized, stopped believing in sets, and was expelled from the Cantorian paradise. I still believe in abstraction, but now I know that one ends with abstraction, not starts with it. I learned that one has to adapt abstractions to reality and not the other way around. Mathematics stopped being a science of theories but reappeared to me as a science of numbers and shapes.

As a personal answer I’d like to say that reading those articles, just “knowing” them won’t help you become a better programmer. And using those words in libraries makes things even worse. A programmer should be honored if and only if they use and write things technical superior, not something mathematical superior.

And this is my question. I’m eagerly waiting for your reply, as I think your opinion could really help me being a better programmer, and should I learn these concepts, how can learning them help me (if it could).

Have a nice day!
Ray Eldath
GitHub: github.com/Ray-Eldath MyBlog: han.ninja

Ray,

These are good but unanswerable questions as it is easy to end up down the path of “what does it mean to learn or understand something” which is a question of consciousness well beyond my expertise. :) For my own worldview, I am a fairly die-hard “operational semantics” person which comes through in my teaching. I believe you can understand monads and functors for programming purposes in terms of how they compute – what the rules are for operation’s like a monad’s bind operator. Yes, there are algebraic laws that should be followed, but to understand “what code does” these are not necessary. Entities like monads are very abstract and general – it’s a concept that describes a broad set of programming patterns / data structures / libraries / APIs and the power is that this is a guiding principle for how to both design and use such abstractions. The connection to advanced mathematics has value and helped develop these powerful abstractions, but it is not my view that effective programmers need to understand the full connection. Others will, naturally, vehemently disagree. :-)

Best,
Dan

## 有关分层

### “Hyrum’s Law”

John Ousterhout 当时还愣了一下问啥事 Hyrum’s Law，主持把这个东西的简明定义说了一下，然后附了一句 “actually I Googled this” wwww 看来大家都不是很知道这个东西 😉

Hyrum’s Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Hyrum’s Law: 只要一个 API 有足够的用户，那么无论你在接口契约中承诺什么，你的系统的所有可观测行为都会被某个用户所依赖。

Hyrum’s Law（又作 The Law of Leaky Abstractions）描述的是这样一种现象： 被创造出来的本意是通过分层这一过程，从而界定一个清晰、明确的边界。这一边界划定了接口 / 契约实现细节之间的界限，从而一方面提高了程序员的工作效率（“我只要用它就好啦”），另一方面——更为重要的是——降低了程序员的门槛，并减轻学习负担（“既然只要用就好了，那我应该就不用关心底层的实现细节了吧？”）

• 众所周知，TCP 承诺可靠、有序、无差错的数据传输。然而，有一天你突然发现服务器组中的某两台之间的基于 TCP 长连接突然变得极慢。你调试了半天，排除了所有的应用程序导致的元素，你终于把视线移到了 TCP 本身。

这时候你被迫去学习有关 TCP 实现细节的知识，你了解到网络中其它未部署端到端拥塞控制算法的协议（比如 UDP）很可能会严重影响 TCP 协议的工作（这些协议被称作是 TCP-unfriendly 的），你啃了啃几篇论文，终于了解到工作在 FCFS（First Come First Serve，先到者先处理）状态下的路由器处理 TCP – 无拥塞控制算法协议 的混合网络有各种各样的问题，典型的比如 unfairness，还有 congestion collapse——后者的效果甚至会导致在网络的送达率没有任何提升的同时仍然（毫无意义地）大大降低 TCP 的工作效率。你最终认识到在路由器上部署 WRR（weighted round-robin，带权重的轮询选择）算法或许是一个解决方案。

这时候，TCP 作为一个，它原本承诺的减轻程序员学习负担这一效果完全没有体现：网络的异常逼迫我们去学习有关 TCP 实现细节的知识，这些知识完全没有包括在 TCP 提供可靠、无差错的数据传输 这一契约中。

## 参考文献

• Stroustrup, Bjarne. “Evolving a language in and for the real world: C++ 1991-2006.” Proceedings of the third ACM SIGPLAN conference on History of programming languages. 2007.
• Dan Grossman. Private communication.
• Hyrum’s Law. https://www.hyrumslaw.com/
• The Law of Leaky Abstractions. Joel Spolsky. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
• A Philosophy of Software Design | John Ousterhout | Talks at Google. https://youtu.be/bmSAYlu0NcY
• Floyd, Sally, and Kevin Fall. “Promoting the use of end-to-end congestion control in the Internet.” IEEE/ACM Transactions on networking 7.4 (1999): 458-472.
• Würthinger, Thomas, et al. “One VM to rule them all.” Proceedings of the 2013 ACM international symposium on New ideas, new paradigms, and reflections on programming & software. 2013.
• Perugini, Saverio & Williams, Brandon. (2017). Revisiting the Futamura Projections: A Diagrammatic Approach. Theoretical and Applied Informatics. 28. 15-32. 10.20904/284015.
• lyzh 聚聚. Private communication.
• Robert Glück. 2009. Is there a fourth Futamura projection? In Proceedings of the 2009 ACM SIGPLAN workshop on Partial evaluation and program manipulation (PEPM ‘09). Association for Computing Machinery, New York, NY, USA, 51–60. DOI:https://doi.org/10.1145/1480945.1480954

https://ray-eldath.me/programming/three-important-ideas/

Ray Eldath

2021-03-06

2021-06-22