Kode Vicious - @kode_vicious
PDF下一件大事
一位态度鲜明的程序员 KV 回答您的问题。他可不是 Manners 小姐。
本月 Kode Vicious 思考了函数式编程的未来，并提出了他的五条协议设计技巧。请享用！然后将您自己的代码相关问题发送至 [email protected]。我们将以正宗的 Queue 小饰品表示感谢。
尊敬的 KV：
我知道您在之前的一篇文章中列出了一些要读的书（“Kode Vicious Bugs Out”，2006 年 4 月）。我还想补充《How to Design Programs》，该书可在网上免费获取，网址为 http://www.htdp.org/。
这本书非常适合解释编写程序的过程。它使用 Scheme 语言并介绍了 FP（函数式编程）。我认为 FP 可能是编程的未来——IBM 研究实验室的 John Backus 在 1977 年就提出了这一观点 (http://www.stanford.edu/class/cs242/readings/backus.pdf)。甚至微软也通过在 C# 中使用 LINQ（语言集成查询）引入 FP 概念而屈服于 FP。您是否认为 FP 在软件开发中拥有未来，还是我们注定要使用具有越来越多特性的当前语言模型？
完全函数式
亲爱的 Functional：
我没有读过您提到的那本书，但我熟悉函数式编程、它的优点和缺点。我是否认为 FP 是软件开发的未来？一言以蔽之，不是。
您在这里提出的经典银弹论。好像只要我们都用以下语言编程，好吧，随便您选：Lisp、Basic、Fortran、汇编程序、PHP、Cobol、Prolog、Perl、Python、C、C++、C#、Java，或者任何本周流行的语言，那么世界将变成一个美好的闪亮之地，就像明日世界一样，只是食物更好吃。
换句话说，没有圣杯。
您的问题实际上是以前问过的关于语言 X 是否比语言 Y 更好或更差的更一般版本的问题。我之前在这个专栏中讨论过这个问题（2006 年 11 月、2006 年 2 月、2005 年 9 月），答案仍然是一样的：视情况而定。
您是否使用函数式编程取决于您要解决什么样的问题，在什么环境中解决它，以及与谁一起解决它。有些问题可以很好地分解为用函数式语言编写的程序，而另一些则不然。许多问题可以用函数式编程来解决，但有时不应该这样做。
因此，如果您有一个看起来很容易用函数式技术解决的问题，这意味着解决方案将是优雅的、易于理解的，并且在预期的工作负载下性能良好，那么您可能想用函数式语言来解决它。我说可能，因为我刚刚给出的条件只是需要克服的第一个障碍。例如，如果您在一个 C 或 C++ 是绝对流行的语言，并且大多数问题都是使用这些工具解决的地方工作，并且您的大多数同事都在使用这些工具，那么您使用任何其他工具都将是愚蠢的。与许多事情一样，环境和设置很重要；否则，您将面临糟糕的旅程。
现在，如果您在一个风格和工具多样化的地方工作，并且与您一起工作的人愿意使用函数式编程，那么您绝对应该使用它。许多伟大的软件都是使用函数式编程编写的，我预计这种情况会继续下去。当然，也有很多垃圾软件是使用函数式编程编写的，我也预计这种情况会继续下去。软件最终通常与其说是工具，不如说是人和投入其中的思考过程。因此，务必跟上函数式编程的步伐，但我不会现在就把您的 Kernighan 和 Ritchie 的书扔掉。
KV
尊敬的 KV：
我在一个分布式系统项目的工作中陷入了一场有趣的争论。我的项目中的一个人坚持认为，我们新的轻量级更新系统中发送的所有数据都应编码为类型/长度/值，而不是仅仅类型/值。既然我们有类型，我不明白为什么长度很重要。我们总是可以从另一个推断出一个。
该协议需要尽可能轻量，因为它可能会通过 SMS 传输到手机，以及通过更强大的网络（如互联网）传输。
您认为长度真的必须包含在内吗？
想知道长度的价值
亲爱的 Wondering：
有趣的是，这么多有趣的争论都带来了不有趣的后果。实际上，最有趣的事情是您将互联网称为“强大”，但我认为我现在就先把它放在一边。
网络协议和协议设计是 KV 心之所向，是的，KV 确实有一颗心。我不只谈论长度的重要性，而是要扩大我的答案范围，并为您提供 KV 的五条网络协议设计建议。
1. 始终编码长度。 既然您询问了类型/值与类型/长度/值编码，我就从这里开始。在数据包或其他类型的编码中省略长度是缓冲区溢出灾难的根源。如果从线路读取数据包或数据的程序无法以简单的方式弄清楚要读取多少数据，这将总是导致有人编写代码，其中他或她试图猜测要读取多少——而不得不猜测是很糟糕的，非常糟糕。一个糟糕的猜测通常会导致缓冲区溢出，并且由于我们正在讨论网络协议，因此该缓冲区溢出可以被远程利用。恭喜，您的新协议现在已成为互联网的新替罪羊，因为一波又一波的脚本小子能够编写微不足道的安全漏洞，从而破坏您构建的东西。
2. 协议需要版本号。 那些认为“哦，这是一次性的”的人需要被解雇，或者也许礼貌地从项目中移除。软件中很少有一次性的东西。您需要像设计和构建软件一样设计和构建协议，以便可以更新它们。如果没有在协议中的某个地方编码版本号，则不可能在不猜测的情况下升级它——而猜测，再说一遍，是很糟糕的。
3. 对齐您的字段。 早在过去，正如我的一位老朋友所说，“恐龙漫步地球”时，尽可能地将每一位都挤入数据包中非常重要；因此，协议的设计通常没有考虑到数据对齐。接收数据包的程序将不得不读取整个 8 位、16 位或 32 位实体，然后与检索到的值玩位操作游戏，以获得它真正关心的 1 位或 2 位。尽管当前相反的趋势——即人们设计协议似乎有意浪费带宽——是一个问题，但需要取得平衡，并且应该朝着字节对齐字段的方向取得平衡。对齐问题最常出现在协议设计者决定向其数据包添加标志时，因此这使我们想到了...
4. 分组您的标志。 我所知道的几乎所有网络协议都有一些标志（即，单个信息位），它们需要进行通信。将标志分组在一起，以便可以更轻松地进行字节对齐（参见第 3 项）。
5. 留有增长空间。 设计一个只使用一次的协议是更多工作的根源——如果您在最初提出协议时留出一点扩展空间，您就不必做这项工作。一些额外的标志位和稍后进行数据包扩展的能力是每个协议设计者在发布 1.0 版本之前都应该考虑的两件事。最后一点不是浪费空间的借口；而是呼吁思考未来会发生什么，未来可能近在下周。
显然，这个列表可以更长，实际上可以成为一整本书的主题，但目前这些是我的前五名。如果您能做对这些，那么也许您的协议将变得非常流行，每个人都会要求您“再做一次！”那不是很有趣吗？
KV
KODE VICIOUS，凡人称为 George V. Neville-Neil，以网络和操作系统代码为乐和盈利。他还教授有关编程相关主题的课程。他的兴趣领域是代码探险、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车骑行者和旅行者，自 1990 年以来将旧金山作为自己的家。
最初发表于 Queue 第 5 卷，第 6 期—
在 数字图书馆 中评论本文
© 保留所有权利。