TempleOS and HolyC

You are about to learn HolyC the way a host teaches a craft: slowly enough to stick, precisely enough to quiz, with a still you can match by hand.

HolyC is not a hobby dialect floating free of an OS. It was the language of TempleOS — a public-domain operating system built by Terry A. Davis as a single, radical vision of what a personal computer could be. You are studying a language that lived inside its own cathedral: editor, documents, JIT compiler, and kernel ideas woven together. Treat that context as part of the grammar, not as trivia.

Terry A. Davis designed TempleOS and HolyC as one system. The language is C-like — types, braces, pointers — but the ergonomics are TempleOS ergonomics: a string used as a statement can print; empty-argument calls can omit parentheses; documents (DolDoc) can carry executable HolyC. Those twists are not bugs. They are the point of the design.

Compare mentally with ordinary C. In C, a lone string literal as a statement does nothing useful. In HolyC on TempleOS, that same shape can speak to the console. That single difference teaches you to read HolyC as a language of immediate feedback, not only as a batch compiler. You will see more of this intimacy later: interactive feel, documents that run, adjacency to the system.

Why study it now? Unusual systems clarify ordinary ones. If you know C, HolyC is a controlled distortion that shows which parts of C are convention and which are necessity. If you are newer, HolyC still teaches typed variables, functions, branches, and loops — with a memorable historical frame that sticks better than abstract posters.

This course is historical and technical. We honor the craft without turning biography into spectacle. Focus on shapes you can type, trace, and quiz: string statements, I64, U0 functions, if/for, pointers, classes, DolDoc notes, and a small composed program. Emulators and archives exist; dialect details vary. We teach classic shapes from TempleOS/HolyC material.

TempleOS aimed for a 640×480 16-color world with a single-address-space feel and a JIT HolyC compiler in the loop. You do not need every kernel detail today. You need the stance: code is close to the system, feedback is fast, and documents can be programs.

Vocabulary for the course: I64 (64-bit integer), F64 (float), U0 (void-like return), U8 (byte/character), DolDoc (document format), RedSea (filesystem — expert later). Names are case-sensitive. Semicolons end statements. Braces group bodies.

Open-book quizzes test HolyC itself — not product chrome. Read the teaching and the still before you answer. Match the exercise honestly. Clever shortcuts that skip the concept leave holes the next lesson falls into.

Hold TempleOS and HolyC as a behavior, not a vocabulary flashcard. Ask: what inputs matter, what action runs, what is visible afterward? If you cannot fill those three slots, you are skimming. Write them in a margin before the quizzes.

When something fails around TempleOS and HolyC, change one thing. Read the error or the wrong output. Return to the still. Do not rewrite the whole example when one token is wrong. Calm retries beat dramatic rewrites.

Compare TempleOS and HolyC with the nearest habit you know from C, Python, or plain English — and name the difference out loud. HolyC's teaching value is often the delta: familiar family, different ergonomics.

Open-book checks for TempleOS and HolyC reward careful reading of this page, not trivia about the website chrome. The right answer is a claim we actually made. Near-miss choices sound technical; they fail because they invert the lesson.

Before the still, predict. After the still, compare. That predict-compare loop is how TempleOS and HolyC becomes muscle memory. Passive rereading without prediction is how you forget by tomorrow.

Say a one-sentence teaching version of TempleOS and HolyC you could give a friend. If the sentence needs five caveats, your mental model is still foggy — tighten it. Precision in speech precedes precision in code.

As you continue, TempleOS and HolyC will reappear inside larger programs. Functions wrap it. Branches choose it. Loops repeat it. Learning it cold now prevents cargo-cult pasting later.

Keep a scratch note for TempleOS and HolyC: one worked example, one failure you fixed, one sentence of definition. That tiny notebook beats highlighting the same paragraph five times.

If you are tired, stop at the still for TempleOS and HolyC and trace tokens with a finger: type, keyword, operator, semicolon. Rushing past tokens is how mysteries are born. Slow eyes make fast programmers.

Wrong answers on TempleOS and HolyC quizzes are teachers too. Read the explain line. Relate it back to the still. A corrected misconception sticks harder than a lucky first guess.

Emulators, archives, and dialect notes may disagree on edges around TempleOS and HolyC. We teach the classic shape on this page. When you port elsewhere, read that environment's docs and adjust — without abandoning the core idea.

Finally for TempleOS and HolyC: write the still from memory on paper, then uncover the page and diff. Memory retrieval is the study method that survives the weekend.

Worked example mindset for TempleOS and HolyC: shrink the idea until you can execute it on a napkin. If the napkin proof fails, the full program will not save you. Enlarge only after the tiny case is honest.

Common confusion near TempleOS and HolyC: mixing the name of the idea with a neighboring idea from C or Python. Write one contrast sentence — "this is X, not Y" — and keep it beside the still. Contrast sentences prevent weeks of soft bugs.

Practice drill for TempleOS and HolyC: change one literal in the still by a small delta, recompute the expected result by hand, then confirm. Single-delta drills expose off-by-ones and wrong-type assumptions faster than rereading the same paragraph.

Teaching standard for TempleOS and HolyC: you should be able to explain precondition, action, and postcondition without looking. If any of those three is fuzzy, that fuzzy slot is the real lesson hiding inside the lesson.

// HolyC on TempleOS
"hello\n";

Walk the still top to bottom. The first line is a comment naming the world. The second is a string literal used as a statement, ending with a semicolon. In HolyC style, that statement prints hello and a newline. The quotes belong to the language; they do not appear on the screen. The \n is an escape for newline — same idea as C. Recite: comment, string statement, output hello.

Pitfalls: treating HolyC as identical to desktop C; forgetting the semicolon; curly smart quotes from chat apps; expecting a full install guide; confusing historical study with endorsement of every claim about the system. Stay with the code shapes. Retype straight quotes if a messenger curled them.

That is the frame: TempleOS, HolyC, a string that speaks. Next lesson isolates that print shape without the history preamble.