Raul wrote:
> If explicit code is simpler than tacit, why use tacit for that case?
First, tacit is an end in itself. Constrained writing can be a source of
great beauty. Have you ever enjoyed a haiku?
Second, for an example of the practical benefits of the tacit style, you
might be interested in a recent post where I demonstrated that the syntax
of tacit code is subject to algebraic manipulation [1]. Such manipulation
allows us to reason about our programs, which is certainly a benefit, and
can lead to insights, and even simplifications. All this can be done on a
surface level, without necessarily having to "read" the program; by
implication, it means such simplifications can be automated.
As an analogy, think of the contrast between ancient, prose (rhetorical)
problems:
A necklace was broken during an amorous struggle. One-third of the
pearls fell to the ground,
one-fifth stayed on the couch, one -sixth were found by the girl,
and one- tenth were recovered
by her lover; six pearls remained on the string. Say of how many
pearls the necklace was composed.
and modern algebraic notation:
6 = x-(x%3)-(x%5)-(x%6)-(x%10)
6 = x-(24*x)%30
6 = (6*x)%30
x = (30*6)%6
x = 30
Consider how _hard_ that problem would have been if you didn't have these
notational tools to solve it (or even approach it! At the time this problem
was proposed, it was considered a serious problem among professional
mathematicians). Consider also that the normalization granted by the
notation allowed us to notice repeated patterns, which in turn allowed us
to **solve all problems of this form, regardless of the details**!
> {: p. _6 6r30
30
In other words, systemization permits automation. We generalized our
insight.
If you want more examples, compare the utility of the Roman numerals, such
as MCMLXXIX (which are "programs to compute numbers"), versus Arabic
positional notation (with its computational infrastructure hidden in the
background), that allows us to instantly recognize 1979. Both "do the same
thing", produce the same value. But are they equal?
In short, notation can be used as a tool of thought.
Third, regarding the particular case in question: I don't believe we can
say ]^:(1:`(<'@.')) is particularly complex. Per the Dictionary, x
f^:(g`h) y ↔ x f^:(x g y) x h y, so x ]^:(g`h) y ↔ x ]^:(x g y) x h y ↔
x h y (independent of g), so:
x ]^:(1:`<'@.')) y ↔ [email protected] .
Necessity surely is the mother of invention. This has given us an insight:
]^:(1:`(<'@.')) is what @. would look like if it were a verb.
-Dan
[1] Deriving j./&i:/@+. from ([: i: 9 o. ]) j./ ([: i: 11 o. ]) :
http://www.jsoftware.com/pipermail/programming/2013-January/031131.html
This post has examples of both mechanical reduction and conscious
simplification. The final reduction required human reason: we had to
recognize that 9 11&o. ↔ +. . But all the previous simplifications
were based only on the form of the verb, not its content.
That is, tacit verbs can be treated as values. Therefore tacit code is
subject to the kind of automatic manipulations for which we favor algebra
(& the positional numerical system, etc). Explicit code doesn't lend
itself to this kind of automation (because rather than "discrete values",
it is more akin to Roman numerals, or "programs for computing values"). To
reduce an explicit verb, then many, if not most, of the transformations
would be of the conscious type needed to replace 9 11&o. with +. .
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
