来自 Java 和 Python 的程序员，优雅而强大的 APL 问题解决方案的语法常常令人困惑地冗长。我编写的代码可能看起来同样强大，但为了我的理解，我更喜欢具有良好变量名称的变量块。哪个是更被接受的发展过程？即使计算相同（尽管由于变量而使用更多的内存），拥有更多代码行是否有不利之处。
问问题
678 次
4 回答
6
不。不是我，如果您重视可维护性、清晰度甚至效率（实际上，一条线可能效率很低），我也不会。拥有更多线和更少冗长的单线没有任何缺点。
问题当然取决于什么是单线？在 APL 中，很多事情可以在一个简短的单行中完成，而这可能需要使用传统语言的许多行。在一行代码中表达一个概念并没有错。例如，将用于从字符串中删除前导空格的表达式拆分为其组成部分（可能在介绍性课堂中除外）几乎没有什么收获：
(∨\' '≠a)/a
但是就像英语一样，一个句子可能会变得太长，即使它在语法上是正确的，也可以通过将其分成更小的部分来改进。
换句话说，短的单线是好的。长单行是坏的。显然，两者之间的区别更多的是艺术而不是科学，也是品味问题。
我认为表现出适当平衡的一个非常好的代码示例是来自 Dyalog APL的dfns 集合。
于 2013-07-26T16:15:24.317 回答
3
密集的单行 APL 解决方案的趋势可能来自这样一个事实，即在早期（1970 年代），电传打印机终端上的旧版功能编辑非常乏味。即使与早期 IBM PC-DOS 的 EDLIN 相比，APL\360 提供的默认编辑器也非常原始。此外，APL 的早期版本（例如 APL/1130）在速度较慢的硬件上运行，据说每行代码都需要读取磁盘。直到 1980 年代，才终于出现了像样的全屏编辑器，这使得编写看起来像样的代码变得容易得多。
那是那时，这是现在。
今天，除了娱乐之外，没有理由在一条线上打包太多。趋势是追求可读性，因为它比任何微小的 CPU 或节省空间（现代硬件上的非问题）更重要，人们可以通过这种方式实现编码。
可接受的是您和您的同事可以在您编写后的几天、几个月或几年内阅读的代码。
于 2013-10-23T14:09:54.293 回答
1
我是一名专业的 APL 应用程序开发人员已有 20 多年了。我想我大概可以数出那段时间我在手指和脚趾上写下的单行字的数量。对于小型实用程序函数，1 行实现可能有用且合适，否则不是。一些 APLers 确实编写了过于密集且难以维护的代码（尽管意大利面条 C 可能同样糟糕或更糟）。他们在我有任何发言权的任何商店都没有。这是将业余和缺乏经验的编码人员与经验丰富的专业开发人员分开的原因之一。APL 至少与任何其他编码工具一样需要注释、有意义的变量名以及清晰、文档化或自文档化代码的其他方面，并且优秀的 APL 人员会使用它。单行词可以成为理解语言的有用练习，
于 2014-08-15T15:20:41.287 回答
0
我已经做了大约三年的 APL 开发人员，我发现我喜欢把问题排成一行，然后再细化。当它是一个长行时，（对我来说）很容易查看是否有类似的代码“块”可以抽象为简单的单行代码，例如命名为 lambdas。
于 2015-01-15T00:57:24.843 回答