什么是“表达问题”？
我对这是什么有一个粗略的想法，但如果有人对“表达问题”有他们认为简洁直观的解释，我很想听听。
I have a rough idea about what this is but if someone has an explanation of the 'expression problem' that they think is succinct and intuitive I would love to hear it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
观看本次讲座。
这个想法是，您的程序是数据类型和对其进行操作的组合。该问题需要一种实现，允许添加新的类型和新的操作，而不需要重新编译旧模块并保持静态类型安全（无强制转换或运行时类型检查）。
有趣的是，在函数式编程语言中添加新操作很容易，但向数据类型添加案例却很困难。而在面向对象语言中则相反。这是两种编程范式之间最大的概念差异之一。
Watch this lecture.
The idea is that your program is a combination of a datatype and operations over it. The problem asks for an implementation that allows to add new cases of the type and new operations without the need for recompilation of the old modules and keeping static type safety (no casts or runtime type checks).
It's interesting to notice that in functional programming languages it's easy to add new operations, but hard to add cases to the datatype. While in an OO language it's the other way round. This is one of the big conceptual differences between the two programming paradigms.
问题背后的想法是文本是一维的。即使你有行和栏，你通常也会逐字逐行地阅读。编译器也是如此。
并且您尝试在其中表示某种二维或更多维数据。例如，按行市长顺序的表如下所示：
在这种表示形式中，很容易在末尾添加新行，而无需触及其余行：
但是添加列有点问题，您需要在 4 个不同的地方触及它：
在实践中，在处理抽象类时，通常会遇到这个问题：添加新的子类型作为新模块非常容易，但是当您添加新的抽象方法时，您需要接触所有模块并添加它;你需要在很多地方做同样的事情。通常你会进行抽象来防止这些重复的事情。
只要使用一维表示就无法解决这个问题。
这个问题的解决方案是使用一个编辑器，它可以让您像真正的表格一样编辑这些表格，而不是像文本一样（在类似 Excel 的视图中，您可以在其中方便地添加新的列和行）。
The idea behind the problem is that text is 1 dimensional. Even if you have lines and columns, you generally read it, word by word, line by line. So does the compiler.
And you try to represent some kind of 2 or more dimensional data in it. For example a table in row-mayor order looks like this:
In this representation, it's quite easy to add a new row at the end, without touching the rest:
But adding columns is problematic a bit, you need to touch it 4 different places:
You generally run into this problem in practice, when dealing with abstract classes: it's quite easy to add a new subtype as a new module, but when you add a new abstract method, you'll need to touch all the modules and add it; you need to do the same thing in many places. Normally you make abstractions to protect against these repetitive things.
There is no solution to this problem as long as you use 1D representation.
The solution to this problem would be an editor that can let you edit these table like things like a real table and not like text (in an Excel like view, where you can conveniently add new columns and rows).
不过，还有这篇关于使用 Clojure 解决问题的文章这个问题是用 Java 提出的，所以即使您不了解 Clojure，它也应该有意义，尤其是在小图表的帮助下。
其中说：
There is also this article about solving the problem with Clojure, however the problem is presented in Java so it should make sense even if you don't know Clojure, especially with the help of the little charts.
which says: