我对这是什么有一个粗略的了解，但如果有人对“表达问题”有他们认为简洁直观的解释，我很想听听。
观看本讲座。
这个想法是你的程序是数据类型和对其进行操作的组合。该问题要求实现一种允许添加新类型和新操作的情况，而不需要重新编译旧模块并保持静态类型安全（无强制转换或运行时类型检查）。
有趣的是，在函数式编程语言中，添加新操作很容易，但向数据类型添加案例却很困难。而在面向对象语言中则相反。这是两种编程范式之间最大的概念差异之一。
问题背后的想法是文本是一维的。即使你有行和栏，你通常也会逐字逐行地阅读。编译器也是如此。
并且您尝试在其中表示某种二维或更多维数据。例如，按行市长顺序排列的表格如下所示：
((A, B, C), (D, E, F), (G, H, I))
在此表示中，很容易在末尾添加新行，而无需触及其余行：
((A, B, C), (D, E, F), (G, H, I), (J, K, L))
但是添加列有点问题，你需要触摸它4个不同的地方：
((A, B, C, M), (D, E, F, N), (G, H, I, O), (J, K, L, P))
在实践中，在处理抽象类时，您通常会遇到这个问题：添加新的子类型作为新模块非常容易，但是当您添加新的抽象方法时，您需要接触所有模块并添加它;你需要在很多地方做同样的事情。通常你会进行抽象来防止这些重复的事情。
只要使用一维表示就无法解决这个问题。
这个问题的解决方案是一个编辑器，它可以让您像编辑真实表格一样编辑这些表格，而不是像文本一样（在类似 Excel 的视图中，您可以在其中方便地添加新列和行）。
还有这篇关于使用 Clojure 解决问题的文章，但是问题是用 Java 提出的，所以即使您不了解 Clojure，它也应该有意义，尤其是在小图表的帮助下。
上面写着：
贝尔实验室的 Philip Wadler 在 1998 年通过电子邮件传播的一篇“未发表的论文”中创造了术语“表达式问题”。正如他所说，“表达式问题是一个老问题的新名称。目标是定义一种数据类型按情况，可以向数据类型添加新情况，并在数据类型上添加新函数，而无需重新编译现有代码，同时保留静态类型安全性（例如，无强制转换）。”