From <http://www.catb.org/~esr//jargon/html/koans.html>:

A novice was trying to fix a broken Lisp machine by turning the
power off and on.

Knight, seeing what the student was doing, spoke sternly: “You
cannot fix a machine by just power-cycling it with no
understanding of what is going wrong.”

Knight turned the machine off and on.

The machine worked.

Commentary:

Rule 1 of power-cycling hardware: watch out for residuals. It takes
time for residual charge to drain out of the circuitry when you turn
it off. If you switch it on too quickly, the circuits are liable to
get into an inconsistent state.

For simpler circuitry, count five seconds after switching off before
switching on again. More complex components might take longer.

----

One day a student came to Moon and said: “I understand how to make
a better garbage collector. We must keep a reference count of the
pointers to each cons.”

Moon patiently told the student the following story:

“One day a student came to Moon and said: ‘I understand how to
make a better garbage collector...

[Ed. note: Pure reference-count garbage collectors have problems
with circular structures that point to themselves.]

Commentary:

Pure garbage collectors will easily consume all of RAM if you let
them. Reference-counting is a well-known technique for keeping RAM
usage within reasonable bounds in many common scenarios. The best
scheme is a combination of both. Languages like Perl and Python are
exemplars of this. Maybe the Lisps could learn from them?

----

In the days when Sussman was a novice, Minsky once came to him as
he sat hacking at the PDP-6.

“What are you doing?”, asked Minsky.

“I am training a randomly wired neural net to play Tic-Tac-Toe”
Sussman replied.

“Why is the net wired randomly?”, asked Minsky.

“I do not want it to have any preconceptions of how to play”,
Sussman said.

Minsky then shut his eyes.

“Why do you close your eyes?”, Sussman asked his teacher.

“So that the room will be empty.”

At that moment, Sussman was enlightened.

Commentary:

I wonder if either of them had heard of genetic algorithms?

----

A disciple of another sect once came to Drescher as he was eating
his morning meal.

“I would like to give you this personality test”, said the
outsider, “because I want you to be happy.”

Drescher took the paper that was offered him and put it into the
toaster, saying: “I wish the toaster to be happy, too.”

Commentary:

What can I say, but be careful what you wish for?
<https://www.youtube.com/watch?v=LRq_SAuQDec>

On 2024-04-21, Lawrence D'Oliveiro wrote:

>
> In the days when Sussman was a novice, Minsky once came to him as
> he sat hacking at the PDP-6.
>
> “What are you doing?”, asked Minsky.
>
> “I am training a randomly wired neural net to play Tic-Tac-Toe”
> Sussman replied.
>
> “Why is the net wired randomly?”, asked Minsky.
>
> “I do not want it to have any preconceptions of how to play”,
> Sussman said.
>
> Minsky then shut his eyes.
>
> “Why do you close your eyes?”, Sussman asked his teacher.
>
> “So that the room will be empty.”
>
> At that moment, Sussman was enlightened.
>
> Commentary:
>
> I wonder if either of them had heard of genetic algorithms?

The same would still apply, wouldn't it? If I'm interpreting the example
correctly, the matter here is mistaking randomness for lack of bias or
influence. It still exists, but is made less "visible" by the
randomness.

--
Nuno Silva

On Sun, 21 Apr 2024 09:35:01 +0100, Nuno Silva wrote:

> On 2024-04-21, Lawrence D'Oliveiro wrote:
>
>> I wonder if either of them had heard of genetic algorithms?
>
> The same would still apply, wouldn't it? If I'm interpreting the example
> correctly, the matter here is mistaking randomness for lack of bias or
> influence.

Genetic algorithms take a bit of randomness and apply filtering to it.
This is supposed to mimic the mechanism of biological evolution, where you
have the randomness of mutation (the inevitable errors in the gene-copying
process) filtered through natural selection.

Randomness is necessary, but not sufficient; the original koan assumes
that’s all there is. Kind of like the creationists, really.

On 2024-04-21, Lawrence D'Oliveiro <ldo@nz.invalid> trolled again:
> Rule 1 of power-cycling hardware: watch out for residuals. It takes
> time for residual charge to drain out of the circuitry when you turn
> it off. If you switch it on too quickly, the circuits are liable to
> get into an inconsistent state.

This is because of power filtering capacitors, which are the largest.

When you cut power to a device, it doesn't instantly lose power. Its
internal voltage begins to drop, as the filter caps drain.

If you restore power too quickly, the device may effectively experience
only a brownout; not enough of a drop to initiate a reset.

(There is also a risk that some designs have a badly designed brownout
circuit: that the voltage at which they become unreliable yet above the
voltage that initiates a reset. But let's assume sane design.)

> For simpler circuitry, count five seconds after switching off before
> switching on again. More complex components might take longer.

No, complexity doesn't extend this period. What extends the period
is having larger capacitors in relation to the current drain.

Complexity, however, means that there can be subsystems in the
machine which tolerate brownouts of different durations.

If you quickly toggle the power, some components in the system may reset
themselves while others recover from the brownout. If you want
everything reset, you have to wait for the slowest component.

> Pure garbage collectors will easily consume all of RAM if you let
> them.

Yes, garbage collection could easily consume all of RAM, even though the
actual application needs only a fixed, much smaller amount of RAM.

"If you let it" is the key operative phrase.

Well, if it hurts, don't do that?

Garbage collection can easily confine itself to carving out small heaps
of memory at a time, and only claim an additional heaps form the
underlying host system only when certain conditions occur, like when a
full GC cycle is not able to recover more memory than a certain fraction
of a heap.

In other words, dynamically scale the footprint to the application.

Additionally, production garbage collectors have tunable GC parameters.

> Reference-counting is a well-known technique for keeping RAM
> usage within reasonable bounds in many common scenarios.

No, reference counting is not primarily technique for minimizing RAM
usage. It is primarily a technique for timely reclamation, ensuring that
objects are finalized and reclaimed as soon as they are not required.

Storage reclaimed by reference counting is not always returned to the
system. Reference counting still has unused memory claimed by
application heaps, that is not available to other applications.
It also doesn't eliminate fragmentation.

All we can say is that, under no imaginable circumstances, would
reference counting (in a correct program that has no "semantic leaks")
consume, say, a gigabyte of RAM, while the program only needs a peak
usage of hundreds of kilobytes. Whereas, garbage collection could be
configured such that such a thing happens.

So ... bleepity-do ... what?

> scheme is a combination of both. Languages like Perl and Python are
> exemplars of this. Maybe the Lisps could learn from them?

In the Lisp culture, memory management has been beat up from more angles
than anywhere else.

You're not proposing that no Lisp in existence has ever used reference
counting for anything, even objects that don't have pointers to
other objects that could get into a cycle.

But you're welcome to pitch in your contribution if you think you're
smarter than everyone else.

> At that moment, Sussman was enlightened.
>
> Commentary:
>
> I wonder if either of them had heard of genetic algorithms?

Yeah, Sussman and Perl are waiting for none other than you to pull their
ignorant heads out of their asses! Maybe while you are at it, you can
get them to study Perl and Python, so they can fix Lisp.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> Knight turned the machine off and on.
> The machine worked.
> Commentary:
>
> Rule 1 of power-cycling hardware: watch out for residuals.

I think the joke here is that (Tom) Knight was a hardware wizard. So
when he power cycled the machine, he knew what was happening inside it,
unlike the student.

On 2024-04-21, Paul Rubin wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> Knight turned the machine off and on.
>> The machine worked.
>> Commentary:
>>
>> Rule 1 of power-cycling hardware: watch out for residuals.
>
> I think the joke here is that (Tom) Knight was a hardware wizard. So
> when he power cycled the machine, he knew what was happening inside it,
> unlike the student.

The wording too might fit the residuals explanation quite well (or
perhaps any other explanation similarly related to what happens
inside). The student turned off and on the *power*, Knight turned off
and on the *machine*.

--
Nuno Silva

On 4/24/2024 12:19 AM, Nuno Silva wrote:
> On 2024-04-21, Paul Rubin wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> Knight turned the machine off and on.
>>> The machine worked.
>>> Commentary:
>>>
>>> Rule 1 of power-cycling hardware: watch out for residuals.
>>
>> I think the joke here is that (Tom) Knight was a hardware wizard. So
>> when he power cycled the machine, he knew what was happening inside it,
>> unlike the student.
>
> The wording too might fit the residuals explanation quite well (or
> perhaps any other explanation similarly related to what happens
> inside). The student turned off and on the *power*, Knight turned off
> and on the *machine*.
>

interesting.... i'll look for other "Koans" and anecdotes.