programming-languages - 符号作为思维工具 - 我们走了多远？

Question

最近，我正在比较一个旧的 Windows DOS 命令来删除目录中的所有文件，我注意到“现代化”版本需要键入 50 次以上的按键才能达到相同的结果。

这些额外的击键是否提高了生产力？它们是否服务于已量化的目的，例如降低编码错误率？

我所看到的问题是，主要为适应冯诺依曼架构而编写的计算机语言 - 而不是我们的思维方式 - 迫使我们通过在头脑中处理三个问题域来解决问题(a)原始问题(b)问题重组以适应冯诺依曼体系结构 (c) 在 (a) 和 (b) 之间来回转换所需的映射规则。

根据经验，计算机语言符号的效率越高 - 从某种意义上说，它使您能够直接处理手头的问题 - 编码开销越低。较低的编码开销使问题解决更容易处理，从而减少编码和出错的空间。绝对不应该增加工作量!

您认为哪种计算机语言是最有效的问题解决平台——因为它使您能够直接根据原始问题进行思考，而无需处理跨域问题？

出于兴趣，我对康威的人生游戏进行了 37 种不同解决方案的字节计数，并得出了以下统计数据:

J : 80, 
APL : 145, 
Mathematica : 182, 
Ursala : 374, 
JAMES II : 394, 
SETL : 559,
ZPL : 652, 
PicoLisp : 906, 
F# : 1029, 
Vedit macro language : 1239, 
AutoHotkey : 1344, 
E : 1365, 
Perl 6 : 1372, 
TI-89 BASIC : 1422, 
Perl : 1475, 
PureBasic : 1526, 
Ocaml : 1538,
Ruby : 1567, 
Forth : 1607, 
Python : 1638, 
Haskell : 1771, 
Clojure : 1837, 
Tcl : 1888, 
R : 2031, 
Common Lisp : 2185, 
OZ : 2320, 
Scheme : 2414, 
Fortran : 2485, 
C : 2717, 
ADA : 2734, 
D : 3040, 
C# : 3409, 
6502 Assembly : 3496, 
Delphi : 3742
ALGOL 68 : 3830, 
VB.NET : 4607, 
Java : 5138, 
Scala : 5427   

(参见例如 http://rosettacode.org/wiki/Conway's_Game_of_Life )

注释？

请具体说明您批评的语言所采用的符号方法的优点，并从相当高的层次上进行——最好有直接的项目经验。

Answer 1

您以 Conway 的游戏人生为例，没有任何语言可以比 APL 更优雅或有效地解决这个问题。原因是非常强大的单个或多个字符运算符中的完整数组/矩阵操作。

见:Whatever Happened to APL?以及我关于将 APL 与 PL/I 进行比较的组合数学作业的故事。

如果您在解决问题的击键方面谈论“高效”，那么 APL 将很难被击败。

您用于 APL 解决 Conway 游戏的 145 字节数是错误的。这是您正在寻找的一个非常低效的解决方案。

This is one solution :


(来源:catpad.net)

那是 68 个字节并且胜过 J 解决方案。我认为还有其他更好的 APL 解决方案。

另见 this video about it .