implicit - J 中默认编程的优缺点

Question

作为 J 的初学者，我经常遇到隐式程序，与更熟悉的显式形式相比，这些程序看起来相当拜占庭式。

现在仅仅因为我发现解释困难并不意味着默认形式不正确或错误。默会形式通常比显式形式要短得多，因此更容易一次直观地看到。

向专家提问:这些默认形式是否传达了更好的结构感，并且可能提炼出潜在的计算机制？还有其他好处吗？

我希望答案是肯定的，对于一些非平凡的例子来说也是如此......

Answer 1

隐式编程通常更快更高效 ，因为你可以准确地告诉 J 你想做什么，而不是让它在你的句子中发现。但作为一个热爱默认编程的人，我也可以说 隐性编程鼓励您以 J 方式思考问题 .

破坏结局并回答您的问题:是的，默认编程可以并且确实传达了有关结构的信息。从技术上讲，它强调意义高于一切，但许多在您将遇到的不太平凡的表达式(@: & &. ^: 仅举几例)中突出显示的许多运算符都具有与结构相关的含义。

为什么要编写默认代码的典型示例是用于模幂的特殊代码，以及存在 many more shortcuts like it 的保证。 :

   ts =: 6!:2, 7!:2@]  NB. time and space
   100 ts '2 (1e6&| @ ^) 8888x'
2.3356e_5 16640
   100 ts '1e6 | 2 ^ 8888x'
0.00787232 8.496e6

你会听到的另一件事是，当 J 看到一个显式定义时，它必须在每次应用它时解析和评估它:

   NB. use rank 0 to apply the verb a large number of times
   100 ts 'i (4 : ''x + y + x * y'')"0 i=.i.100 100'  NB. naive
0.0136254 404096
   100 ts 'i (+ + *)"0 i=.i.100 100'                  NB. tacit
0.00271868 265728
   NB. J is spending the time difference reinterpreting the definition each time
   100 ts 'i (4 : ''x (+ + *) y'')"0 i=.i.100 100'
0.0136336 273024

但是这两个原因都让位于 的想法之后。 J 解决问题的风格非常独特 .没有如果，有 ^: .没有循环，有等级。同样， Ken saw beauty事实上，在微积分中，f+g 是函数的逐点和——实际上，人们将 f+g 定义为函数，其中 (f+g)(x) = f(x) + g(x)——并且由于J 已经很擅长逐点数组加法了，为什么要止步于此呢？

正如 Haskell 之类的语言喜欢将高阶函数组合在一起而不是“手动”端到端同步它们的乐趣一样，J. 在语义上也是如此，请看以下示例:

h =: 3 : '(f y) + g y' – h是一个获取参数的函数 y ，将其插入 f和 g ，并将结果汇​​集到一个总和中。

h =: f + g – h是函数的总和 f和 g .

(A < B) +. (A = B) – “A 小于 B 或 A 等于 B。”

A (< +. =) B – “A 小于或等于 B。”

这是一个更多的代数。到目前为止我只谈过火车；关于 ^: 等工具的便利性，有很多话要说。或 &. .不过，教训相当清楚:J 希望可以轻松地用代数方式讨论您的函数。如果您必须将所有操作包装在 3 :'' 中或 4 :'' — 或者更糟的是，在单独的一行中命名它们!— 每次您想有趣地应用它们时(例如通过 / 或 ^: 或 ;. )，您可能会非常排斥 J。

当然，我承认你会很难找到像这些优雅的例子，因为你的表达变得越来越复杂。默契风格只是需要一些时间来适应。你必须熟悉这个词汇(如果不是第二天性的话)，即使这样，有时你也会很高兴地浏览代码，这简直是不可原谅的。任何语言都可能发生这种情况。