作为思想工具的符号 - 我们到底有多远？

Question

作为思想工具的符号 - 我们到底有多远？

最近我比较了一个旧的Windows DOS命令来删除目录中的所有文件与脚本等效 - 我注意到"现代化"版本需要输入50倍的击键来实现相同的结果.

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

我认为这个问题是,主要是为了适应冯·诺依曼架构的计算机语言 - 而不是我们的思维方式 - 迫使我们通过在头脑中处理三个问题域来解决问题(a)原始探测(b)问题重组以适应Von Neumann架构(c)在(a)和(b)之间来回转换所需的映射规则.

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

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

为了兴趣,我为Conway的生活游戏做了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

Run Code Online (Sandbox Code Playgroud)

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

评论？

请具体说明您所评判的语言所采用的符号方法的优点,并从相当高的水平进行 - 最好是具有直接的项目经验.