|
From: | Gregg Reynolds |
Subject: | Re: [Axiom-developer] Heidegger, literate programming, and communication |
Date: | Thu, 22 May 2014 04:21:37 -0500 |
Gregg and Gary,
I understand where you are coming from. Indeed, Maturana [0] is on your
side of the debate. Since even the philosophers can't agree, I doubt we
will find a common ground.
Unfortunately, I've decided to take on the task of documenting the
Clojure internals because, yaknow, *I* don't feel I understand something
until I know what the hardware does; consider this a flaw in my
personality :-)
Hmmm. Common Lisp is about 25 years old. Assume Clojure lives that long.
What are the odds that the original authors will be maintaining the
code? Will the code still be "an audience of one"? Are you sure that's
a worthwhile goal?
Sophisticated Lisp programmers use macros A LOT.
expanding into macros expanding into macros. Quick, what does the
spadcall macro do?
>Exactly. Conclusion: it's hard, maybe impossible, to generalize about whatYes, it is hard to generalize about what all code should look like. But
>all code should look like. Maybe it's essentially pluralistic.
it is not hard to generalize that reading natural language explanations
is faster, more accurate, and a lot easier than reverse-engineering
code.
It is MUCH easier to understand Greg Humphrey's rendering code
than it is to understand the Clojure internals.
Consider a randomly chosen paragraph from Physically Based Rendering
(p356):
To do the permutation, this function loops over the samples, randomly
permuting the sample points in one dimension at a time. Note that this
is a different permutation than the earlier Shuffle() routine: that
routine does one permutation, keeping all nDim sample points in each
sample together, while here nDim separate permutations of a single
dimension at a time are done. (Figure 7.21)
for (uint32_t i = 0; i < nDim; ++1) {
for (uint32_t j = 0; j < nSamples; ++j) {
uint32_t other = j + (rng.RandomUInt() % (nSamples - j));
swap(samples[nDim + j + i], samples[nDim * other + i]);
}
}
Footnote: While it's not necessary to permute the first dimension of
the LHS pattern, the implementation here does so anyway since making
the elements of the first dimension be randomly ordered means that LHS
patterns can be used in conjunction with sampling patterns from other
sources without danger of correlation between their sample points.
So we learned what the code does. We also learned not to "optimize the
code" by replacing it with Shuffle(). Further, we learned that we
shouldn't "optimize the code" by removing the apparently useless
shuffle of the first dimension. And, as a bonus, we get a figure.
NONE OF THIS INFORMATION IS IN THE CODE ITSELF.
In addition, this code lives in an organizing structure. It is
in Chapter 7: Sampling and Reconstruction
Section 7.3: Stratified Samples
Heck, it is only 4 lines of C++. Why bother? *I* can read C++. I can
even reverse engineer it (probably by inventing the diagram in Figure
2.7 on a napkin). Maybe it lives in the src/SamRecon/StratSam, which is
all the organization necessary. :-) But I can't reverse engineer the
important information in either paragraph of text.
For comparison, refer back to the multi-page Java code I posted
from the Clojure core. As a maintenance programmer, which would you
rather maintain?
Languages come into fashion all the time. Almost all of them disappear.
Axiom and Clojure are worthwhile efforts. We really need a mindset that
extends into the future, communicating with the maintainers.
[Prev in Thread] | Current Thread | [Next in Thread] |