The Supernatural

In Medieval natural philosophy, the supernatural made perfect sense: things had their own natures, that caused them to act as they do. But a force greater than their nature could intervene and cause them to act otherwise. So bread naturally (per its nature) nourishes us, but a supernatural act can cause it to become the body of Christ.

However the scientific revolution did away with these "natures." There was brute matter, whose only nature was occupy space, and then there were laws imposed on this brute matter by God: in a sense, all of nature only "worked" because of divine commandment. The fact that these were divine commands to nature was why they were called laws! Attempts to explain natural phenomena by "natures" were mocked; see Moliere's parody of medieval natural philosophy where the doctoral student explains that opium causes sleep because of its "dormitive powers."

But many later scientists, under the sway of 19th-century ideologies, forgot the supernatural nature of their own laws, and came to use "supernatural" as a term of derision. But in our modern context the term is what Rand would have called a "stolen concept": any coherent idea of the supernatural is going to catch the modern "laws of nature" in its nets, and that is definitely not something the people using the term derisively want to do!

Is there a test suite for your test suite?

In one of my coding projects, a young collaborator sent me some code for automated testing, and wrote, "If this looks OK, I'll put it into production."

I looked at the code, and it quite clearly would never pass anything, since one of the tests sought to verify the working of a feature that hadn't yet been implemented. The programmer writing the testing code had never tested it.

We could try to write a meta-test suite to test our test suite, but then what about the meta-suite? How can we be sure it is correct?

The point here is not to pick on our novice programmer, who is quite smart, merely lacking experience, but to point out that while mechanical schemes of program verification can be a great aid to producing good software, but they can never be a substitute for sound engineering judgment.

I'm feeling loopy!

Tonight, Emu86 has grown up to where it can loop:

         mov eax, 10
loop: cmp eax, ebx
         je done
         inc ebx
         jne loop
done: mov ecx, 1

Yes, that jne could have been an unconditional jump... but I wanted to test jne!

Not every conspiracy is a theory

I rented a copy of Money Monster. On the box, it proclaims that "Not every consipracy is a theory."

Well, no, conspiracies aren't theories: they are consipracies. Some people have theories that event X or Y came about due to as conspiracy. Some of those theories are false, but some are true! (There was a conspiracy to kill Hitler, a conspiracy to blow up Parliament, etc.) But somehow "conspiracy theory" has come to mean "false consipracy theory" in many people's minds. I saw this recently with the charges of Russian election interference, where people on Twitter were saying, "It's not a conspiracy theory: the CIA is saying it!"

Oh, and the movie: it's in the running for one of the worst films I have ever seen. Pretty much every single thing in the movie is bogus. The characters have completely unbelievable personality transformations, they unravel a conspiracy based on the most ridiculous "clues," the financial market talk is nonsense, the tech talk is nonsense, the mystery is hardly a mystery at all (surprise: the rich guy did it!), and as "social commentary" it is on the level of a sixth-grade civics paper.

There was no "The Making of Money Monster" extra on the DVD, but if they had interviewed director Jodi Foster and asked how she had made the film, an honest answer would have been, "Well, I just toook a big crap onto some celluloid... and then I released it to theaters!"

Assembler progress

This code now runs "properly":

         mov eax, 2
         mov ebx, 4
         jmp here
         mov eax, 90
         mov ebx, 100
here: add eax, ebx
         dec ecx
         inc edx
         jmp here

Properly is in quotes because I have taken some protective measures. The last four instructions, of course, create an infinite loop. Since this is an educational program, and infinite loops will take up lots of CPU time on my web server, I am limiting runs to 1000 instructions, and then warning of a possible infinite loop.

The idea here is that students can build tiny test problem programs, and not an operating system. So I think 1000 instructions is plenty: what do you think?

Why use strict parsing rules?

In x86 assembly language, you write a move instruction like this:


My emulator accepts that. But right now it also accepts:

MOV EAX,, 13
MOV EAX,,,,,,,,, 13

In other words, I only require that I can separate the tokens in the instruction somehow.

My question to you is: other than trying to be exactly like Intel's assembly language, why be more strict? So long as the interpreter / compiler can figure out what the programmer wants, why fuss over how many commas are used?

In other words, why not parse as leniently as possible, and only complain when a situaiton is ambiguous or otherwise unresolvable?

The country waiter and the city waiter

Toggling oneself back-and-forth between a country setting and a city setting makes one alert to the many small differences between lives in each place.

This morning for breakfast, my bill came to $14.87, and I paid with a twenty. In the city, there is a 99.9% chance that I would get five singles and $.13 back in change. Every city waiter seems to have learned with their mother's milk that you provide the customer with lots of singles, so that they have lots of options for tipping you.

But I was in the country, so I got back a five dollar bill and $.13, and had to go to the register and ask for singles. This seems to be the default behavior of country waiters.

Essential vim

1) Don’t touch the arrow keys! (You have to drop the habit of using them hard, since your muscles are trained to reach for them.)

2) Most vi commands can take a number in front. xCmd will do Cmd x times.

3) Instead of arrow keys:
h: left-arrow
j: down-arrow
k: up-arrow
l: right-arrow

First of all, your fingers are still in ‘home position.’

But also, to go up 10 lines:

Back 8 characters:

4) But even better:

xG: jump to line x.
w: move forward a word at a time.
12w: go forward 12 words.
b: move backward a word at a time.
/xxx: find and go to pattern xxx in file.

5) And editing:
cw: change the word the cursor is on.
10cw: change the next ten words
dw: delete current word.
10dw: delete next 10 words.
dd: delete current line
10dd: delete next 10 lines.

Learn this set right away. Force yourself off of the arrow keys. More to come.

Adjective order in English

I was making a "funny" Facebook post about how, in action movies, what looks to me like simple chiropractic neck adjustments always manage to kill the adjustee.

And that made me think about the correct ordering of English adjectives: "a simple chiropractic neck adjustment" is the right order. A native speaker will not say, "a chiropractic simple neck adjustment," or "a neck simple chiropractic adjustment."

Similarly, we walk into "large, green room", and not a "green, large room."

These "rules" are ust about automatic for native speakers. But there not very easy to make explicit, and I have never seen them taught.

Was Obama really the first?

I have seen claims that Obama was the first two-term president to be at war for all 8 years he was in office.

The claim seems problematic to me from two sides:

1) The United States does not declare war anymore; we engage in "police actions" and so on. So in a strict sense, one could say Obama has never "been at war."

2) In another sense, the United States is perpetually at war: we are always bombing or subverting the government or supporting rebels in some nation: so haven't most of our recent presidents been continuously at war in this broader sense?

So (sincere question, I really don't know), is there some sense that this claim of "eight years at war" is true of Obama but not, say, Bush?

"The only way to have confidence in a Python program is to write tests"

I saw this asserted (hee-hee) in a Python book I am reading.

The author apparently doesn't know that, while testing is great, in the old days, we used to actually logically analyze our programs and gain great confidence in them from that exercise.

Memory may be beautiful and yet

What's too painful to store in RAM
We simply choose to forget...

In any case, Emu86 now has (limited) memory support.

Coming next: branching instructions.