符号作为思考的工具--我们已经走了多远？

Question

最近，我比较了一个旧的Windows DOS删除目录中所有文件的命令和一个脚本上的等价物--我注意到“现代化”版本需要多敲50次键才能达到同样的效果。

这些额外的按键是否提高了工作效率？它们是否服务于量化的目的，例如降低编码错误率？

在我看来，问题是一种主要为适应冯·诺依曼体系结构而编写的计算机语言--而不是我们思考的方式--迫使我们通过在我们的头脑中同时处理三个问题域来解决问题：(a)原始问题(b)重新组织问题以适应冯诺依曼体系结构(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   

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

评论？

请具体说明您所批评的语言所采用的符号方法的优点，并从一个合理的高层次进行-最好是具有直接的项目经验。

Answer 1

那些抓住“击键作为效率的衡量标准--被认为是有害的”的人没有抓住这篇讨论的标题所指出的要点。

像APL或J这样设计良好、符号密集的语言为我们提供了嵌入到简单、一致的框架中的高级计算概念，使我们能够更容易地思考复杂问题。击键次数少是这一点的副作用。

Answer 2

您是否真的将del /s *.*与其实现进行比较？我敢打赌，脚本的作者可以让shell输出并执行内置的del命令。很难说他为什么不这样做，但他可能有一个很好的理由。

我是all for less ceremony，cyclomatic complexity很低，但击键似乎是衡量代码易读性的一个非常糟糕的指标(Perl -你为什么那样看着我？)或者它如何很好地映射到问题域。只需将所有变量名改为一个字符，您就可以节省大量的击键操作！或者让一些高级的code golfing把代码变得完全可怕。效率不是很高。

Answer 3

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

我认为在一定程度上是这样的。即使我打字快10倍，一个项目最终也不会快1%。但是看看蝙蝠的档案，它们看起来像意大利面。不，更像拉面。

大多数时候，我编写了一些“快速和肮脏”的脚本，我必须运行它来检查它是否真的可以工作。但在现代语言中，我几乎不会在运行时遇到愚蠢的意外(比如删除错误的文件，因为脚本是从网络驱动器或快捷方式调用的)。