vw microbus ¶
Today's headline comes from a video game my younger son told me about yesterday. He saw an old VW microbus on the road and laughed; he explained, "You only see those in movies or games." I asked, which games? He said Destroy All Humans has a segment featuring 1969 VW microbuses, when roleplaying an alien recruiting humans for a cult to worship a god named Arkboodle. (I'm not making this up.)
Apparently one hippie / potential convert asks for proof he's an alien, demanding as demonstration that ten (10) VW microbuses be put atop near buildings. And it really takes all ten: he's totally unpersuaded after only seven or eight.
What are chances this reminds me of a common software writing social experience? Hmm, let me see. Has anyone ever bet you couldn't do that (whatever you did) again?
touch base ¶
Sometimes I'll notice activity and link accordingly, especially if I know names from the past; I prefer to link tech people. It's not that I dislike journalists per se. (Usually.) I just haven't appreciated my experience with any lately. Besides, I'd rather hear what programmers have to say, since they have basis to form opinions meaning more to me.
slow going ¶
Coding progress lately has been slow, giving me a trend suggesting it may be months before I have enough to teach my sons. Next summer looks likely as a timeframe to expect enough done to really interest other folks too. And I can see two or three years to reach stuff I find most interesting. But things might accelerate after current careful foundation work.
number formats ¶
I was still parsing numbers this last weekend. After collecting non delimiter characters in a contiguous sequence, this defaults to a symbol if I can't convert it to a number. I'd rather this than more error tokens. (I favor a style of error handling that aims to make error states unreachable by design.) So you either get a symbol or a number, but not a parse error.
I'm supporting Scheme numbers, some MIT extensions, Smalltalk style radix prefixes, and C style number constants too. Why not? Yes, I know C and Smalltalk style hex constants (eg, 0x00FF and 16r00FF in addition to #x00FF) won't be portable to other Scheme implementations, but converting to other kinds of syntax is still in the plan. And telling folks "don't do that" seems unnecessary.
I wasted some time fussing over edge conditions like leading commas and trailing periods. For example, commas are not defined as delimiters, so they can appear in the middle of symbols. But clearly a leading comma cannot be the start of a symbol without ruining read macros turning comma into an unquote for quasiquotation.
After an integer, a trailing period does not make the number floating point, unless either a single digit of mantissa follows, or an exponent. So an int followed by period is still exact. Somehow I don't like this. I was tempted to save a trailing period as a separate token, but that seemed sure to make docs longer. (Shorter is better.)
bucky bits ¶
Before I started char constant parsing, I decided to hack the immediate representation of characters to accomodate MIT Scheme style bucky bits. I was already providing 24-bits for the 21-bit range of Unicode, but adding four more bit flags needed an adjustment. Now I can support the same syntax and semantics for characters in the MIT Scheme spec.
illegal chars ¶
Continuing avoidance of parse errors, I thought I might handle unrecognized character names by mapping them to a well-defined "illegal" Unicode codepoint like #\U+FFFF. So if source contained #\nonsense, instead of a parse error, it could map to codepoint #\U+FFFF. Then you could check at runtime. Later, for static compilation purposes, I can add a warning or error for this.
midnight hour ¶
Generally I start writing around midnight when I see my deadline is up. Otherwise I'd never write because I don't really have anyone to write for. A few years ago I thought I was advising younger folks (I was thinking of my sons), so they might avoid making mistakes I'd made. Now I think it's impossible. It's hard to grasp all the mistakes you can make; it's hard to make a dent in just categorizing mistakes caused by letting yourself be steered socially by folks around you.
Realistically, I can't tell you how to avoid it. So I don't know how to follow through on my basically altruistic motives. Instead I might offer you a line from one of my favorite movies from the old days — the original Alien (1979) with Ian Holm playing the android named Ash, whose last words before deactivation were, "You have my sympathies." He was commiserating over expected difficulty dealing with the alien, voted most likely to eat all the humans on board. Do you feel like food today?
zombies eat brains film at eleven ¶
A slashdot article yesterday named Firstborn Gets the Brains contained several posts making a zombie joke like one I wanted to make recently. Now I can just quote them without coining new humorous zombie metaphors myself (which as a spontaneous act of creativity makes one suspect to average people). The first post with a score of 5 ends:
by illeism (953119): I wonder if I will get those extra IQ points if I eat his brains...
Many subsequent posts make similar jokes about zombies and eating brains, and taking possession of intelligence by simply eating it. Kinda makes you wonder why Americans like movies about zombies eating brains. It's like a modern day Dracula story updated to concerns we have today: whether keeping up with the Jones's involves a brain race, and whether stopping your competitors from eating your lunch also involves stopping the munchies in other venues.
Obviously I should follow this up with a long funny piece on the topic. But I'll have to come back to it later, even though it pertains to themes I expect to revisit often on briarpig, on topics of eating and being eaten in a dog eat dog world. (Or a wolf eat pig world, if you aren't a predator yourself.) The image of average Americans as zombies is such an apt one, as they scour the landscape seeking bread and circuses, and fertile brains.
lisp and compilers ¶
I followed a link Patrick Logan posted in God I love Lisp, but the blog post by Joe Gregorio is about the classic Dragon Book on compilers, and I can't see the direct Lisp connection except by following his link to Steve Yegge on the importance of compilers (both writing them and understanding them). But here Lisp is not mentioned either. It's only when I find Steve's old Drunken Blog Rants from his Amazon days that I see a big pile of interesting Lisp mentions. For example, I just read through The Emacs Problem and I know I'm going to enjoy reading the rest soon. And I'll probably be quoting from pieces here so I can write about Lisp.
I know, you think I'm using basic link-whore tactics above with all these links. Nope, I just want to set the stage for discussion of compilers and Lisp, because that's near the heart of what I enjoy thinking and talking about. And I can't imagine why I'd get any links back, since my tone and material won't work well for many folks. (And getting links back to here will just get me attention causing folks to bother me. Is it time to say "Get off my lawn!" yet? Hey, I just remembered I was going to put that in today's headline.) The sections immediately below try to paint a picture of myself as an old fart.
dumb jock ¶
I don't look like an old fart. What I look like is a big dumb jock, the same as I looked in high school, in the 70's, thirty years ago. I look about ten years younger than I am. (I know, you'll believe it when you see it.) Only wrinkles in my face give me away — otherwise I look like an athletic 37, with 17-inch biceps the same size as my neck from gym workouts. But with these wrinkles, I couldn't possibly be as young as I look. As you get closer my apparent age goes up — to about 39 or 41, which is still years too low.
[Update: Recent estimates folks make of my age come close to the mark: so I may be kidding myself about looking younger. And if you meet me years after I write this, I'll look older still, right? And I'll put on a few more pounds, and suddenly have a gut, and start looking like an aging gym teacher who denies the facts.]
I've had several conversations with guys in their early 40's — coworkers typically — who are dead certain I'm several years younger than them, who try to complain about being old, explaining they're older than they look. They start angling to surprise me with the news they're older than me, that they're not in their late 30's like me. It's fun to disabuse them, asking if they want to bet who's older. But most of the time, like in interviews, it's convenient to be seen as a peer with 30 somethings. (Yes, age-ism is rampant.) But I'm really not; I'm an old fart who wants the kids to get off my lawn.
I'm joking of course. All this is merely preparation for the story of how I taught myself to program 32 years ago in high school, and about how it took me ten years to get very good at it, and ten more years to get great at programming. And this was still a dozen years ago. I don't think I'll stop getting better at it, unless my brain dries up someday. Seems okay so far.
dartmouth basic ¶
My first programming language was Basic, around 1975 or so — I think Nixon was still in office. I was the brainy math whiz in my high school, where I graduated without ever having gotten a grade less than an A in any subject, and never had a classmate who escaped the shadow of my performance. (A girl once went berserk when she finally got a test score higher than mine; other than events like that, I never noticed I was in competition with anyone.) So naturally the math teacher invited me to try his pilot programming class, using a line terminal connected over phone lines to a local college.
It seems I taught myself how to program in Basic from the online tutorials, as quickly as I could go through them, which was rather fast. The teacher taught us Fortran later in the class (and I had Fortran again later in college) so we could write punched cards to submit to college data centers. Coding Basic with an interactive session was more fun. Instead of the couple required assignments, I completed many dozens — approximately fifty completed programs to the thirty or so done by all the rest of the class combined.
It's not like I felt I had a calling. I just did everything like that. It was fun, and I was used to over-performing. So I forgot about it until college a couple years later. Of course, since I didn't have access to a computer (and neither did anyone else), I couldn't have kept up my interest even if I had wanted.
cs in college ¶
I started out in EE, and after getting straight A's in calculus and physics, etc, I had my first circuit theory class the same quarter I had another programming class. The circuit stuff was boring as hell, and programming was fun, so I realized I should change majors, and I did. But I still wasn't really any good at it, even though my IQ tested 160 at that time. (I was curious then, but I haven't been curious since; standardized tests are basically a crock anyway. Don't invest energy in them.)
I had classes in Fortran and Pascal and assembler, with most of the teaching in Pascal, which I didn't like all that much. Pascal had arbitrary restrictions in how things were done which were supposed to be good for you. I think having all class work submitted as punched cards detracted a lot from immediacy I'd felt when coding Basic interactively. Even though I wrote a couple programs that worked perfectly the first time, it wasn't fun being that careful up front.
drop out ¶
I dropped out of school for a few years because I was financially distressed, and didn't know how to work the scholarship mill. My parents never contributed a dime toward my college education, and probably for good reason since — like my father — I was a colossal prick, and didn't inspire filial devotion. Putting myself through school was an incredibly grueling and complex process, which I found physically taxing while working part-time, commuting by bicycle, and never getting enough to eat, which was why I only weighed 170 pounds. (I've an absurd story about a forced swimming gym class in college, which greatly aggravated physical exhaustion, but I haven't time to tell the tale here.)
But while I wasn't in school, I never stopped studying. I was always a library rat, and soon thereafter I turned into a computing lab rat, despite not being enrolled in a program.
berkeley ¶
I landed in Berkeley in 1983, and discovered no one minded my using the facilities even though I was never registered as a student. (I know what you're thinking; I never tried to pass myself off as a student. It's just no one ever asked.)
I taught myself C and started writing on Unix, using an account at Berkeley I paid for myself out of pocket. Any member of the public was welcome to sign up and use an account if they paid their bills. So I did. I liked C a lot more than Pascal, because every expression had a value, and things made sense. I still wasn't any good at programming, but I was getting better.
At the suggestion of a professor, I started writing a preprocessor for troff, in order to turn an interface like the Scribe word processing system (from CMU) into the commands used by the troff backend. This involves a lot of symbol tables and defining re-usable components, and about half way through I started to realize I knew how to write a compiler, if I wanted to write one.
But first I wanted to write a 3D modeling framework for generating 3D graphics, and I spent a long time working on that. I didn't start working on languages until after I went back to school to finish my degree. Not surprisingly, I already knew more than graduates from my school at the very beginning.
state college ¶
Lest you get confused, please keep in mind I never attended any prestigious schools. I did finish my BS in computer science. But I didn't attend school anywhere that would impress you. Can you remember this? Even though I said I studied at Berkeley — which is true — I never attended Berkeley as a student, so if I ever catch you making a mistake on this, I shall have to beat you about the head and shoulders. My pedigree sucks.
However, by the time I finished college (the second time around) I was very good at programming, or so I thought, just because I could code in circles around my peers. While that's a good starting point, there's a long way to go after that.
I think that's my call to hit the sack now. So I might resume the story here later, though it gets less interesting. During my last year of school I wrote my first Lisp interpreter, and over the next few years I was writing interpreters and compilers all the time. (I was hooked.)
humor sandbox ¶
During my couple year writing hiatus, I thought of many funny things to write. But I knew I shouldn't commit them to virtual paper, because almost all of it was poisoned by what motivated my humor. It was so far beyond black humor, it smelled like carping even when it struggled to be funny, so it stank. All the funny stories were trashed.
Also, writing funny material no longer seems a good idea, though it's often still nice mental exercise. It makes a great puppet theater outlet to lampoon irritants in the one truly safe context: your own mind. But the real world isn't a safe place. Nothing can be lampooned in safety — not if your name is attached. The price of self expression can go up.
Part of the problem is that most people are dumb as dirt, and tend to view creativity in a most unfavorable light, because they're bound to see all evidence as favorable to themselves, no matter how they must bend perception of you to make it so. Therefore, talent is often a sign of madness in the eyes of others, because it's easy to impute, thus a cheap ego boost.
Yes, as I was closing I drifted up against an age-old cliche, that genius and madness are close allied. (Yes, citations here would be great, but you can find them easily yourself.) Stumbling across cliches is a fine way to make a point lose punch. But my point was really the reason why great unwashed masses need such cliches to be true: for their own self esteem.
If you're smart enough, the common ruck really need you to be at least a little loopy, because otherwise they'll feel bad. So any excuse will do for such a finding. God forbid you should do anything interesting that could mean you're unhinged. If you tell jokes, they'd best be safely boring jokes, so people groan at your awful geek humor. You may be smart, but you're so dull. You might prefer that to other choices. You need a failing; you'll be assigned one if you don't have one. Of course, you really do have a failing; you underestimate how scary others can be.
father's day ¶
My younger son gave me a father's day present today that startled me, because to date I haven't yet told either son about this site, other than a site exists. They haven't heard a word about briarpig, or any mythology about pigs or wolves. (I'm not sure why I haven't told them; I guess I expect them to have little interest.)
So imagine my surprise when my son hands me a 14 inch high paper maché figure — of a wolf — that he made himself at school. He apologized immediately for the wolf looking a little crazed, with big staring eyes and big white sharp zigzag sawtooth teeth painted on for his choppers. He stands on his hind legs like a man, but with knees bent, and arms akimbo like he might be about to lunge. Or maybe that's just what you get with paper maché. The ears are done with splendid precision, conveying much wolfness.
Of course I said I liked it a lot, and it's true. I asked what other kids made — all wolves? Or everything different? All different, he shrugged, explaining other kids tended to go for, um, greek gods and stuff. For me he unknowingly makes an image of briarpig's nemesis, hungry for another meal, not too far from the picture in my mind's eye, but lacking the intelligence I've come to know so well over the years.
There's little point in naming the wolf, since more than one wolf comes calling at the briar patch. Briar Pig won't come out when one uses the intercom at the front gate, but BP's happy to have a remote conversation, usually about the wolf's prospects should he take his chances and ignore the warning signs about traps. Bon appétit.
parsing numbers ¶
I've been coding this weekend, and I'd be doing that now except I see my self-imposed three day deadline is here. I like writing entirely too much, which is why I've tried giving it up in recent years, because writing's a diversion that seduces you into wishing your ideas have influence, when your audience may be mostly well-spoken, opportunistic wolves.
I'm rewriting my Lisp parser for the Nth time to accomodate several different new things at once. I have several parsers on hand written over the last fourteen years. Actually some of the tokenizing code is from Smalltalk implementations, but I try to keep number tokenizing the same. My later parsers do a better job of perfectly tracking stream offsets associated with tokens, and not just line numbers, but for this to be helpful I might need to hack someone's text editor for use as an IDE with perfect offset range selection for debugging.
A parser I wrote a few years ago uses a token class to parse tokens, and it delegates integer parsing to yet another class, which copes with just sequences of integer digits in an arbitrary base. It automatically upgrades the storage format to big integer when a small integer can no longer fit into immediate encodings, or smaller boxed integer formats.
(My big integer format is a sequence of bytes, one byte per digit in base 256, in little endian order so significance increases going rightward in bytes. Sign is stored separately as a boolean value. This format is relatively easy for doing arithmetic. Most likely using bigger digits would be more efficient — say 16-bits at once, instead of eight.)
But the integer parser assumed single pass only, and now I plan to tolerate more exotic tokens, so I'll need more than one pass over input that can be a number or just a symbol that's close to being a number, but isn't. (I'm going to use the MIT Scheme's definition of delimitors to decide what goes into tokens, so I won't be able to commit very early to parsing a number in lexical analysis.)
This means I need to accumulate a token into a buffer before I parse that buffer again to see if it succeeds in converting to a number. But my integer parser wants to read from the stream type specific to tracking line numbers and stream offsets. So it needs to be tweaked to use a fully general input stream, so I can use a subclass that reads from a contiguous byte sequence.
Except I saw I hadn't actually written the yvi class yet, which subclasses the yi input stream API to read from a fixed sized yv octet sequence. It's less than half a page of code for all methods (given how I eschew whitespace), and I have several versions on hand, but it still had to be written again for the þ library. Except while I was at it, I globally changed the method signatures for yi::iread() and yi::ipread() so they more exactly match standard arguments for ::read() and ::pread(). And then I did the same for outstream methods yo::owrite() and yo::opwrite(). So I stopped to hack the class hierarchy while porting the integer reader.
What else might you find interesting? Oh yeah, I replaced the old fixed token buffer with an entire page, which although bigger than before, is still going to be too small for big string tokens. So I found myself spinning my wheels thinking one more time about paged scatter/gather strings in the parser, which I know I don't want to do first thing, since I can get around to it.
If the new parser has performance in line with my old ones, which did several megabytes a second a few years ago, I'd expect the new one to parse all the source code I expect to write in a single second, if it doesn't have to waste time opening files in the file system. Of course, this one will be in C++, and not terribly flexible, nor friendly toward continuations and other things that would slow it down. So a later parser in Scheme and other syntaxes will likely be written, to be run in contexts when a server wanted to do the right thing with async network i/o in the mix.
Now there's a first draft of each top level page in the sidebar, so you can expect the pace to slack off a little as I resume a focus on coding. Most likely I'll generate a trickle of subpages under the thorn page, at the slowest rate I can pretend is respectable. ;-)
They want to improve Javascript garbage collector, so I was tempted to write about how I'm structuring the þ gc, in case that helps. But I should just keep working on the code and worry about that later. I actually started writing code again, instead of writing more drivel for this site.
I think I'll look into WebKit for a while, and get my hands dirty while thinking about how to use it as a host environment for running languages. It looks like a nice platform for developing clients for servers.
I was reminded of these macros I wrote in 1993 at Taligent, when Chris Rathman discussed EOPL macros in the and LtU discussion thread (about ECMAScript Edition 4 Reference Implementation).
