Lately I write demos under thorn with a todo list using C++ under a BriarPig mu-babel license. The run and hex demos were done on 13apr2008; crc on 14apr2008; buf on 20apr2008; in on 27apr2008; ctype on 04may2008; out on 18may2008; slice on 25may2008; quote on 31may2008; escape on 31may2008; mutex on 14jun2008; rand on 16jun2008; stat on 17jun2008; primes on 19jun2008; list on 23jun2008; heap on 29jun2008; iter on 02jul2008 and 04jul2008; atomic on 06jul2008; node on 13jul2008; page on 23jul2008; hash on 27jul2008; book on 27jul2008; pile on 03aug2008; stack on 07aug2008; mu on 12aug2008; toy on 16aug2008; weight on 23aug2008; symbol on 02sep2008; imm on 04sep2008; gc on 06sep2008; map on 14sep2008; meter on 16sep2008; thread on 22oct2008; arc on 05nov2008; this menu links all demos:
mu: toy, peg, imm, tag, box, symbol, token, number, bigint, class, method, reader, writer, eval, env, vm, gc, world, pcode, compiler, asm, lathe, lisp, smalltalk, design, weight, jar, card, harp, debug, profile
thorn: todo, names, iovec, assert, log, run, hex, crc, buf, in, out, quote, escape, compare, file, deck, cow, arc, blob, tree, slice, rand, time, stat, heap, node, primes, page, book, pile, stack, atomic, lock, mutex, thread, map, list, iter, ctype
first qi dialog ¶
Here's a taste of new material on the qi page.
requirements ¶
"Uh, Wil," Eli broke gently. "I hate to correct you, but 2009 is not a leap year. There's no 29th of February this year. You should fix that."
Surprisingly, Wil looked very gratified. "You fell for my ruse. Consider for a moment: What if Zé someday learns to travel in time? He might get folks to reform the calendar. For all you know, 2009 might become a leap year. Today is the 29th of February by fiat, because I say so."
"Wil, that's deeply eccentric," Eli inched away.
"I'm joking," Wil sighed. "But I do have a point: don't argue with me. Whatever I say about Lathe goes. I'm not interested in arbitrary rules other folks like. When it's arbitrary, I get to pick when it comes to Lathe. So do we have a deal?"
"I have to agree, or I can't play?" Eli restated.
"Yeah," Wil nodded. "I don't really have a lot of time. And unlike sixteen years ago, I find I don't care much anymore about trivial programming language details. They're all the same in big ways. So I'll let you banter with me over bootstrapping Lathe, provided we don't sweat endless alternatives. I need a yes or no here."
"Fine!" Eli snapped. "I accept. But you don't have to be a prick about it. Don't have a cow, man."
"That's my cue to say 'Bite me!' — Yes I do have to be a prick about it," Wil insisted. "Otherwise, in your enthusiasm, you'll stonewall my progress through simple denial of service attack. So when I make this gesture, you shut up."
"I thought you were a nice guy," Eli said crossly.
"Sadly, it's human nature to never stop asking for more, no matter how much you're given," Wil claimed.
"Oh, so now it's about me," Eli rolled his eyes.
"Enough self pity," Wil commanded. "Let's start with requirements. You'll hate the first one."
"By the way, qi is a stupid name, " Eli sniped.
non-blocking ¶
"Lathe must be non-blocking," Wil announced.
"Non-blocking?" Eli screwed up his face. "Does that mean async? No blocking at all?"
(Continued at qi#non-blocking.)
async ¶
"Can you define 'async' for me?" Eli asked.
(Continued at qi#async.)
queuing ¶
"Ultimately it means requests queue inward and replies queue outward," Wil said. "Or it works roughly like that. Replies might be function callbacks instead of queued responses. But Lathe also queues requests to a client env — for stuff needed to satisfy client requests."
(Continued at qi#queuing.)
yielding ¶
"Lathe must return to the calling env in a fairly short time after any request," Wil said. "Even if Lathe could run indefinitely — an infinite loop is a pathological case — Lathe must return often to a calling client env, to avoid hogging cycles. Otherwise a calling env might miss handling new events in a timely fashion."
(Continued at qi#yielding.)
back pressure ¶
"What if Lathe doesn't make progress fast enough?" Eli asked. "I mean, suppose a client env keeps queuing inbound requests, and Lathe replies slower than new requests arrive? Won't something get wedged?"
"Oh, yes," Wil agreed. "If nothing else, latency between request and later reply might get too big. So a client env must track use of resources in Lathe — total memory used or memory remaining, as well as queue lengths — and decide whether to throttle incoming requests."
(Continued at qi#back-pressure.)
new site focus ¶
A new top level page explains a new focus for this website: qi. The name is sorta arbitrary; it just needed to be shorter than all the other page names, so the sidebar looks good.
Something will appear there this weekend. I expect to write starting api docs about instantiating and running an interpreter for a Lisp variant. The format will be dialogs between Wil and Eli (and perhaps others) about small steps in picking api taking small steps in a forward direction.
The rest of the way I run this site will remain the same. More fiction will appear soon. The rate at which fiction appears will depend on what I enjoy, and not much else. Right now I'm enjoying it. The next scenes seem worth doing soon; I'm trying to brake a headlong rush into action pieces. However, Finch is teaching Wil to quickdraw a small paintball pistol of remarkably elegant design, unlike anything he's seen.
work designs ¶
Seems like I'm designing something for work all the time. Lately I write api docs every day, all day long. This includes deciding what should happen, drafting one or more possible code apis, then describing what it means in great detail. For example, today I wrote all about three basically different async api design styles we might use. There's a lot of api, both internal and external, partly because I'm doing both top-down and bottom-up views, with layers in multiple places.
The scope of what I'm doing so far seems to have no bounds. If I'm willing to define an all-singing, all-dancing design that does everything, they're okay with that. So far I guess this means when I put a stake in the ground, it makes it easier to define something similar but different, after I clear away a lot of the haze. As near as I can tell, folks like the way I write problem definitions. On a related note, they don't like what happens to parts I don't define in past efforts.
It's been several weeks since any bug was reported against my last engine. My bug list and enhancement list are both zero length. That's why I can focus on a next über rev: my last dev effort seems perfectly done. The components that are hard to grasp are the ones I didn't do. I suspect my current task to define everything under the sun in a future rev is an attempt to make all future mechanisms easier to understand. There's something to this: I tend to eliminate unnecessary parts when I fit things together. When someone else fits A to B, we get extra pieces C, D, and E addressing edge cases.
Anyway, lately when I have conversations about interface boundaries, everything is on my side of the line. This mushiness makes it slightly hard to play off constraints, since I don't seem to have any except "as good as possible." Normally I like to define api for resources given to me which I must repackage. Now I seem responsible for the resources too — except I know that can't always be true. This is apparently one of my interface boundaries: the same api whether I do it or whether someone else gives me a plugin.
(On weekends I can't seem to think long about programming language runtimes without finding myself back in the work maze, sorting out flows between compartments in controlled ways. However, when I do manage to think about language runtimes, it's normally about granularity of copy-on-write in modules and namespaces.)
ipod ¶
I bought myself an iPod Nano a few days ago, then proceeded to stock up on all the tunes I've been missing for years. Tonight I must have sat frozen for fifteen minutes watching an action sequence with Wil and Finch, in my mind's eye, while playing Abacab by Genesis over and over. Every once in a while, I imagine scenes in a story engaging me as much as any movie I've ever seen. A good sound track helps.
I've written most of the establishing story context now, so it's easier to indulge in writing new scenes without any backstory debt getting in the way. I still have a piece of old content to write eating at me from my last birthday: Finch shows Wil a thing — after he hits his head — which she'd otherwise be unable to let him know. A chance Wil might have hallucinated it all makes it an acceptable risk.
The big action sequence comes after that. If I write it, Wil's experience will give him post traumatic stress.
(Now playing: Rapture by Blondie. Now if I can only get a copy of a remix with Riders on the Storm by The Doors.)
random keys ¶
A couple weeks ago on Hacker News, someone noticed it would be useful if Ruby had a way to choose random hashmap keys. The intended application was in caches — removing a random key when a cache becomes too full.
Yes, that's a very useful operation. You can do it with constant time cost if you fold it into hashmap code acting as a cache. I currently use caches I wrote working in this way (removing randomly chosen elements once too full).
My last rev works as follows. After adding or searching a map, if it's too full, try to remove an element. My "random key" is the one's complement of the key I just added or tried to find. If this hits a used slot, I whack the item I find there. If that slot is already empty, I jump ahead seven slots; and if that one is empty, I jump thirteen more slots. After three tries, if I haven't removed anything, I give up.
Up to three tries is constant time. With uniform distribution and occupancy up around two thirds, this algorithm almost always removes an element. (I never see the stats go over the limit.) There's a nice side effect, too.
The side effect is exponential decay. It becomes unnecessary to age out old content: the longer something is in a map, the higher the odds it eventually gets whacked by random removal. And yet, really old stuff remains very sparsely represented. (This can be very useful, depending on your app.) Exponential decay avoids several pathological replacement effects. For example, you can't clear your cache the way LRU would by cycling through a bit more content than your cache can hold. In fact, a cache using exponential decay can manage to usefully sample much bigger populations than fit.
long time no see ¶
(Moved to fiction.)
armed tourists ¶
(Moved to fiction.)
compression ¶
Ulf studied Wil (typing away like usual) for a full minute before approaching to test his latest pet theory, which hit him when reading Hacker News a few minutes ago. That item today about compression sounded familiar. Sometimes Wil talks about it — is that the same thing as dedup? Wil says he does dedup, whatever that means.
"I can hear you thinking from over here, Ulf," Wil complained. "Can you turn down the bass?"
"Ah, that metaphor stings, Wil," Ulf laughed. "Are you saying my mind has lowrider specs?"
"I'm still typing," Wil warned. "See, I'm not taking a break to see what it is you want to BS about."
"There's an item on Hacker News about compression," Ulf said. "Have you seen it yet? It's interesting."
Wil abruptly ceased typing and put his face (gently) on his keyboard as an exaggerated full stop. "Remember you told me to tell you when you were acting rudely and insensitively?" Wil quoted.
"I'll show you on my laptop," Ulf said. "You don't even have to bring your browser to the foreground."
Wil gave up and skimmed a few posts, then looked up at Ulf before shrugging. "So?" Wil challenged.
Ulf raised his hands and struggled to formulate his opening remark, so Wil cut him off to speed things up. "Okay look," Wil explained quickly. "The easy way to do compression is always dictionary based compression. When possible, instead of sending data, you send a smaller reference to earlier defined data."
"This guy suggests you can customize compression with shared knowledge," Ulf pointed at a first post.
"Yeah: dictionary means the same thing as shared knowledge," Wil said.
"Is that what you do in your day job?" Ulf asked.
"I don't like talking to you about my day job," Wil summarized. "Besides, if I told you anything, you'd tell someone else. No, don't evade that one."
"What about this part," Ulf pointed. "He suggests using parts of files on his client that the server also has, as a source of pieces for transfer."
"That's interesting," Wil said with a poker face.
"Come on, Wil, spill it!" Ulf begged.
"Nope, I'm not telling you how I do things," Wil shook his head. "But obviously, any time you do dictionary based compression, it's hard to tell the difference between that and what BigZaphod here just said."
"And look, this jerf guy says it's been done before in WAN optimzation," Ulf pointed at the next post.
"Well, yeah, I do WAN optimization," Wil nodded. "I've been doing dedup along those lines around 30 months now. And I used to do proxying, and I still do caching, but I'm not going to expand on their discussion."
"But, but," Ulf clenched his fists and pointed. "BigZaphod here mentions hashes and chunks of files."
"Ulf, those are the usual suspects," Wil waved casually. "It's the first place to look. There's good stuff there. And no, I'm not going to tell you what it is. Everyone working in dedup already knows this much."
"Can I find the good stuff if I search here really well?" Ulf asked. "Or if someone good searches here?"
Wil shook his head. "To get anywhere, you have to ask yourself several hard questions first, just to frame the problem. And even then, it's not going to occur to you; it hasn't to anyone else yet. I'm not getting you started. So buzz off, okay?"
"What hasn't occurred to anyone yet?" Ulf asked.
Wil picked up his headphones, put them on, turned up the volume, and resumed typing. When Ulf touched his elbow, Wil reached for a flyswatter.
recommended: flu shots ¶
The last 72 hours were pretty miserable. The only thing that could have made it worse was traditional flu nausea. (I have no idea why this flu caused no stomach upset; I just count it a blessing.) My temperature only stayed within a degree of normal about one hour a day, rising to 102 F at least once a day. Until about four hours ago, I didn't know if I'd be well enough for work tomorrow.
I plan flu shots every year henceforth: I don't want a repeat. My chest hurts from coughing my lungs clear; the muscles involved all ache. You've been warned.
namespaces vs modules ¶
Consistent with past flu experiences, I did interesting design work while languishing in hell. This time I was able to analyze it some while it happened. Essentially, I was too wrecked by illness to enjoy normal distractions.
For example, you try to read a web page, eyes burning because they're open, while your body says, "You must sleep: Now. Stop everything." But after lying down and succumbing to the sleep ritual, sleep never arrives for some godforsaken reason. Instead you drift in a liminal space of imagination. You can imagine how much mucus you coughed up last time, or guess how soon it will be necessary once again. Or, you can fit jigsaw puzzle pieces in the last incomplete problem you've been studying.
What was my incomplete problem? Namespaces in a Lisp dialect, plus interaction with module semantics. Oh, and while I was at it, I was determined to think of a lightweight process model allowing me to run normal and sandbox lightweight processes, all inside one heavyweight process, with efficient representation I could use with native threads when appropriate. In effect, I wanted a design for syntax: namespace-scoped variables, dovetailing perfectly with a view of language values as a virtual file system, except replacing files with arbitrary language values. (Directories are maps, of course, except keeping them out of gc space has advantages I like so far.)
I read a lot of web pages found in searches for "namespaces vs modules," "chroot jails," and "proc file system," as well as many other pages suggested by new searches related to what I saw there.
I also spent some time — just a mental exercise while zonked out and unable to sleep — mocking up graphical figures, programming language examples (in C++), and file system file and directory diagrams, all laced together with a draft dialog between Wil and Eli about how conventional name lookup differs between file system path visibility and programming language variable visibility.
Between that stuff, working through dozens of practical examples and gotchas, plus straining over syntax choices problems conflicting with everyone somewhere (periods, slashes, colons), I figured out enough definitions to suit me — but it would take several thousand words to write down. Some parts are still weirdly unsettled: I haven't figured out namespace variables for parsing and loading; or rather, I haven't figured out how they bind consistently.
And I guess at one point I started planning a small re-org in this site — mainly affecting the top page and a few other pages contradicting a new message — to explain a new focus on the toy language I'm calling Lathe (for lambda thorn: a Lisp one atop thorn C++ utilities).
My original idea was to make a toy Scheme and a toy Smalltalk, with Lathe being the toy Scheme plus an arbitrary number of extensions, including a Smalltalk style object model. But since I started focusing on an idea to make Lathe do whatever I need to simulate systems implementing async, multi-node, peer-to-peer distributed effects, this has dragged the language off a feasible path of compatibility with another language.
While I still want to run Scheme code in a suitable namespace inside Lathe, it's pretty hard to deny what I'm planning is more a new language than an old one, despite being composed completely of old features in old languages, plus a few process control kinks imitating an operating system and/or file system.
Recipe: simple Lisp-one somewhat like Scheme; add Smalltalk style object system minus almost all Smalltalk standard classes; add C++ style namespace system, with first class namespace objects at runtime in architecture that can — for sandboxes — mock chroot path behavior; add some Python style module support, but so different a mapping must be explained; add a little Erlang style message passing; add some Linux (or Plan9) style proc file system behavior in namespaces to reveal stats, reflection, and lightweight process control in a sandbox-safe way; add some Unix style pipe and process i/o letting lightweight processes stack as tools.
In short it's a lot of "do whatever I want" stuff in a long laundry list, starting with namespaces first since otherwise I can't define what expressions using them are intended to mean. I prefer clear definitions without a lot of weird edge cases. But I'm not sure I want to write all this down in advance of doing it. At most I'll write only some, as a docs tax ensuring it eventually gets done.
lucid windows ¶
With my fever running up and down, over a cycle of several hours from good to bad, I wrote the following piece of fiction during a good window. In retrospect, I probably should have done something else instead. But the whole weekend is going to be shot by the flu anyway.
(I am working on something I like in the programming language space, which I can do even when I feel very sick — I need to do something besides feel miserable. But describing it fully would be very involved. So when I cover this topic soon, I'll treat it so lightly at first, you might not see any point to where I'm going.)
three card monte ¶
(Moved to fiction.)
granite const ¶
I'm recovering from a bad case of influenza: the sort with hours of high fever. (My temp hovered around 104 F last night for four hours.) Today I feel so much better — merely being moderately sick seems a real treat in comparison. Now my symptoms are ordinary.
While driving myself home from work last night with a fever, I saw a pickup truck in front of me with the words "granite const" written on the back of the cab. I said to myself, wow that must be really, really const — adamantly const. Totally immutable. Then I realized const was short for construction. It was a company name.
distractions ¶
The last piece of fiction was really fun to write. (I don't know if it's good, but it was fun.) I'm trying to hold off writing a couple more pieces following that one soon in (story) time. Ultimately it's a kind of distraction: writing fiction doesn't get me anywhere; it's just fun.
When I started that scene, I didn't have a clear plan for Finch, except I knew she had been writing some column no one knew was hers. And I knew Eli was wearing a t-shirt saying "save the eloi," but I wasn't sure how that tied into anything. Sometimes writing fiction is just a process of constraint solving and detail elaboration. It's always strange when the net effect at the end implies some overall theme I hope to pursue, when it's mainly thinking of funny turns consistent with character motivations.
About 80% of each story is ad libbed: I don't think of most bits until a preceding paragraph. I'm always surprised when I like the result. I begin many paragraphs only with a vague goal: write something about X, for some X.
By the time I was done, I started thinking: oh great, now I have to write one of Morlock's columns. But that sounds really hard; I set too high a bar for the notional quality of Finch's writing if she was popular.
I guess it would not be too hard to write a Dear Abby style column in which a columnist rips every supplicant. Then folks might start sending letters inviting such a response. The artistic thing to do would involve pursuit of Finch's agenda, which you'd have to infer.
The last fiction fragment omitted a point I wanted to reach, but could not work into the mix. Eli tells Wil and Zé about one of Morlock's early columns — answering a guy asking Morlock what lottery numbers to play; Morlock's reply had next week's correct winning lottery numbers, giving the column a lot of publicity.
When I started designing the characters, I only had a good idea who Finch was. Wil, Zé, and Ulf were just names for a while, without any personality. Wil was the most blank of all: ordinary guy with a non-conformist streak.
ask miss morlock ¶
(Moved to fiction.)
financial aid ¶
My folks paid for none of my schooling, because they considered my desire to go to school my problem and not theirs. But they made too much for me to get financial aid. The first three years of college were living hell because on minimum wage at the end of the 70's, I covered all living and school expenses, just barely, by not eating enough, without any help from another living soul.
I had perfect grades in high school. But I neglected to study for the SATs, so I only got 770 in math and 670 in verbal. (If you understood what my memory was like then, you'd understand I'd have gotten closer to 800 in verbal after some studying.) Anyway, I didn't get any appreciable support for school; I only picked up an extra thousand dollars in a freshman engineering grant. So it's completely a myth that having a very high IQ and good grades will automatically put you in good shape for college.
It's also a myth that good people only go to really good schools. I didn't go to a good school, for example.
My folks often give signs they hope I'll one day forgive them. But it's been thirty years: I don't see it happening. I'm not abrasive about it. But to this day, all they care about is how they look — my distance looks bad. Well, tough. I'm still trying to get shut of my ex, who I only got saddled with because my folks abandoned me after high school. There's no way in hell I'll help my folks in their old age. I haven't been able to start saving for my own retirement yet.
When I was a teenager, my dad was fond of stories making it clear he admired mean sons of bitches. So maybe he now admires my acting like one too. If he doesn't, maybe someone will enjoy the irony.
modules ¶
Instead of coding my interpreter, I'm thinking about the global namespace, modules, and a plan for threads. I decided I wasn't very interested in a normal top level global namespace, even for a first toy version of a language.
Anyway, my point here is simple: I'm working out how memory is named and managed by a running system. That's also one of my day job functions — figuring out a global view of system state. It looks like something fun to think about before coding another programming language revision. At least I'll get to target something slightly new when I start coding again.
I wasn't planning to include a thread model, but now I find it hard to ignore when I plan to use a language to drive async components. At minimum I'll need green threads and my own scheduler to simulate multi-process async system models. And as long as I do that, I might also support native threads via shared nothing memory models in one process. Not that I'm especially interested in threads per se — I just want to get memory state to change when and where I need it too, and sometimes a thread model makes simpler code. However, I need to run embedded in some processes where native threads will be forbidden; so green threads are necessary in the most strict context.
A plan for namespaces, modules, and global state must include a scheme to spawn threads, green and native, with a smooth transition copying whatever needs it.
back story ¶
The following piece of fiction is vaguely interesting, but not very cohesive; mostly it's just strange. The idea was to put a little meat on back story, incidentally, while telling another story. While amusing to write, it's not very successful in terms of enjoyable results.
the shine ¶
(Moved to fiction.)
idling ¶
I'd forgotten writing here has an extra function for me late at night — waiting to become tired, without working on something too interesting to become sleepy. If I try to write code right before sleep, it wakes me up too much. No, honest.
I guess if I had something to read, I'd do that instead. I wonder if I could have imagined when I was younger the idea of writing as a substitute for reading before bed. It seems as farfetched as thinking I'll one day prefer a bed of nails at night.
documentation ¶
This week in my day job I started writing designs in html format, using a clone of the format I use here: same css and basic page layout, etc. I prefer double column format to get narrow columns, and to put things side by side for idea locality.
The wiki we use tends to spread things out too much, both horizontally and vertically, with an effect of making me seem even more verbose than I am. My chronic writing problem is finding a way to mention enough relevant detail all in one spot, so readers can get an idea without remembering twice as much off screen content as in view right now.
I find myself in the same ironic situation all the time: folks want me to explain how things work, in writing, and yet they don't want to read what I write. I suspect everyone dreams I can achieve a magically effective way to draw diagrams explaining everything in visual images, without ever needing prose for explanation. (Now that I think about it, I once I hoped I could do that too, when I was twenty years old.)
Since I'm a rare person who writes design descriptions, I often get requests for "old" docs on things that were never described by anyone. Today one of my colleagues asked for my old docs that explain an interesting emergent pathological result of an older generation's code algorithm. While wracking my memory, I poked around in the wiki until I was sure I never wrote about that one; no, that one was only whiteboard explanations, leaning heavily on diagrams. In fact, that particular emergent effect is hard to describe in words — it sure makes folks screw up their faces when I say it in words instead of drawing figures. (Which then makes them wish it was in writing, because they don't want to say it to the next person in line asking questions.)
The odd emergent effect — which I'm not going to explain here — causes a dedup algorithm not to do exactly what an original design intended. Something similar happens instead, with some flaky fringe side effects causing too much i/o where one might naively hope that would not happen. My most recent design makes that particular effect go away, finally, among other things.
The original design wasn't mine — I just inherited the dedup core and redesigned it end to end over a period of time, after which I had all the odd behaviors characterized. Eventually folks identified the dedup core with me so thoroughly, they have trouble noting historical quirks aren't my fault. Only the next rev will be so totally redone all the parts are mine.
The html docs I'm now writing at work spell out the entire new design, end to end, with a focus on touching each wrinkle and connecting each piece to the next. The biggest remaining open question, which I must convince folks I have answered, occurs in the middle, explaining how we get there from here in content indexing. But the middle doesn't make sense without the ends defined, so I'm forced to define the ends just to clarify the middle.
The argument is going to be over whether we have enough resources. I do most of our analyses involving math and probability — arithmetic of resource consumption and expected benefits — and sometimes the scaling problems get tight. Some old designs get away with exponential decay for graceful degradation, but new stuff is more literal, exact, and size sensitive.
Can you tell I like doing this?
commercials ¶
Okay, this is slightly funny. My older son had a delayed reaction when I pulled his leg tonight. We saw several great commercials during House re-runs; best was a Hulu ad featuring Alec Baldwin, apparently shown during the Super Bowl. The tagline was, "An evil plot to destroy the world. Enjoy." But that's not the commercial during which I joked.
(This year, as usual, I made it through the Super Bowl without noticing which teams were playing. In fact, this year I didn't notice the game even existed, until my neighbors started screaming in crowd-sized parties. I thought, hey, isn't there some popular game played around this time each year?)
Remember a commercial where a kid captures wind in a glass jar, taking it home to some birthday party where a gust from the jar blows out birthday cake candles? That's the one. It's an old one, so my older son stared blankly.
I put on a tone of voice adults use to tell boring stories about childhood. I said, "That's what I did as a kid," gesturing to the kid capturing wind in a jar. This is a standard joke: I claim I once did whatever is shown on the tube when I was young — been there, done that. No reaction from Tyr.
"I made a lot of money that way," I added like I was reminiscing. Still nothing from Tyr. So I kept rambling, "Some kids deliver newspapers, others collect wind in a jar for home delivery." I made it sound really boring.
In the ad, a whirlwind gust of wind from the kid's jar blows out candles and stirs the clothing of folks in the room. Tyr suddenly turned to look at me, his eyes getting big.
"Whaaaat?!" Tyr asked in surprise, playing back what he'd just accepted as fact while I was talking. He gave me a wild look and giggled as he reheard my remarks.
groundhog day ¶
I plan to focus on coding a while simply because it interests me more than writing prose here. This is good: wanting to code purely because of interest is perfect.
So my current target is a really simplistic version of lathe as a toy language — little more than a AST interpreter for starters, driven by a read-eval-print loop.
I plan infrequent updates here unless I get an urge. (Suppressing urges is seldom productive.) However, just so activity shows signs of life, something will appear here at least once a week. When I get enough of a toy lathe implementation done, I'll start putting code in appropriate web pages here with dialogs. For example, the compiler page gets a lot of hits: too bad that page is still just a stub. Okay, I'll put up both a C++ and a lathe compiler emitting VM pcode someday.
Welcome to worse is better blogging.
perspective ¶
I'm no longer puzzled by people. Now when I look back on things I recall, I say, "Of course that happened." Everything makes sense. And I don't see other paths I could have taken that might have turned out differently. (For example, I made bad choices in who I trusted — but I'd have made equally bad choices regardless. All roads lead to getting burned; you can only choose to figure it out faster. It's not as grating when you realize choosing well was a hopeless task.)
Incidentally, my insight into thought processes of others is so much better now, compared to ten years ago that, that it would seem magical to my older self. There's a fairly simple set of rules that, run as a simulation, predict exactly the sort of crazy belief structure that's typical.
(Most folks have a self-aggrandizing view of the world; this view and all evidence perceived — especially priors in no way relevant — get tuned to optimize self flattery: everything confirms self view. Yes, it's madness, but since it's normal there's no stigma unfortunately.)
fiction: backburner ¶
After fleshing out another piece of fiction, it felt too weak to post: it said too much instead of showing. The conversation between Zé and Eli about email with Flywheel lacked flavor because it was largely back story manifested as content without any plot tension. If I pursue it again later, I'll recast good parts so they occur in the middle of some side plot.
calm ¶
Lately I've been very calm, like I'm on schedule. This is true at work, of course, since things are in good shape there. But I also feel this way at home, too. For example, I went for a hour's hike up in the hills this afternoon, then for a 90 minute workout in the gym this evening with 30 minutes on a bike. I figure I won't ever lose a few pounds unless my aerobic balance goes up; losing ten or fifteen pounds wouldn't hurt.
However, I have no anxiety at all about this site; I don't feel any pressure to produce here, because I feel like I'm done. I could stop writing here tomorrow with no regrets. Whatever I wanted to work out seems worked out: it's not eating at me any more, whatever it was.
But giving up further work on this site isn't useful. It's a useful asset, albeit an extremely illiquid one. The value is strategic only — almost not at all tactical. More than anything else it acts like advertising in the yellow pages, showing a bit of detail about things I know how to do, going into far more detail than folks ever have time to learn interviews, for example. (I'm not looking for a job; I like the one I have, so please don't ping me unless you just want to touch bases.)
So I lack motivation to write much about programming languages right now; but that's what I'm going to do anyway — but only in a shallow manner missing depth and breadth you might prefer. In other words, I might only make a token effort for a while. I'm more in the mood to visualize all the state in systems I'm thinking about (which is one of the things I aimed to foster when I started writing here: a new abiding interest in seeing systems I want to finish building).
simple interpreter ¶
I'm back to dialogs between Wil and Eli about interpreters, but actually coding something very simple appeals to me more than writing about it — partly because I'm in a bit of a hurry to use it sometime in the next few months as a test harness.
This will include more interpreter context, continuing what I started recently. While I could just wing it now (and I wing all my dialogs anyway) it seems better to visualize more territory I want to cover first, before making myself treat it lightly here.
