Pawprints of the Mind

This past weekend, I joined Julie and many, many others in celebrating Grandma Ritchey's 100th birthday, July 14th. As part of the celebration, we joined the family for church on Sunday morning. It was quite the experience for me, raised Episcopalian and turned sorta Wiccan-mystic, to be at a free-form Protestant service. It was mostly prayer and sermon, relative to the scripted ritual of the Episcopal Church.

Not only is this my first visit to a radically different church, it's a visit made while old enough to pay attention at both regular and meta-levels. Throughout the praying for healing and other concerns, I let myself become a channel for the energy, directing it from its source into the prayer, driven outwards by the force of the pastor and congregation. I let myself become part of them, while storing off in memory the experience of the pastor's rhythmic, impassioned pleas, amid the background of the murmurs of the congregation.

I realized that the repetition of the rhythm and inflection and the murmurs were all very trance-like, and a very brief vision of the parallels between that service, Buddhist and Jehovah's Witness meditations, drumming circles with Open Heart, and yoga and Gregorian chanting presented itself to me. (Trance music was notably absent from the list, but that's because the average consumer of it is not using it to seek God.) To sum it up inadequately in language, trance is one of the fundamental tools in the search for god, and the example before me there was glorious.

Like Julie said to me afterwards, even if we don't agree with the regular congregation on the place and meaning of Jesus and God in religion and our lives, they're founded on good morals—and that is where the real meaning in religion lies. God probably couldn't care less about how we personify him, or where we place Jesus in the theological framework, if we are living for him in willing service to others.

I have a feeling I'll be back there again, even though I really don't know yet whether I truly liked it or not.

One obvious, major question arises when considering whether any ancient civilizations reached great technological heights: if they existed, where is the evidence of them? What legacy have they left behind, and how could we find it?

The first possibility is that we simply don't recognize the evidence before us. For instance, Christopher Dunn has written extensively (caution: blink effect in use) about the fact that the ancient Egyptians appear to have done all their advanced machining and workings in granite instead of steel, and are thus invisible to modern culture which only recognizes metal alloys as technological achievement.

Another interesting possibility is that an old, large civilization could easily vanish with few traces if its inhabitants lived in a culture which emphasized recycling and simple lives. If most of the stuff they had was designed to decay easily and they didn't accumulate huge landfills, then virtually all signs of their civilization would rapidly disappear. Even remains would be scarce in a civilization which practiced cremation instead of ritual burial.

The last possibility is that the location of that civilization is now inaccessible to us, due to changes in the Earth's surface. The obvious example would be of legendary Atlantis sinking beneath the waves, but uplift or climate change would have a similar effect. Desert tends to preserve things well, but it seems like only enormous stone structures have much longevity in most other climates. As for uplift, if inaccessible mountains carried a city upwards, it would disappear into memory as it decayed.

I have discovered that I want to budget my time differently. Being a world-class software developer is just one of the things I need to do, and focusing on it to the exclusion of all else is probably a mistake. As such, I'm going to be spending a lot less (free) time in front of the computer.

Since nobody comments anyway, it's not like anything is lost.

I was looking at the lone picture in my DeviantART gallery, and specifically the Creative Commons license on it. BY-NC-SA? They don't offer non-attribution licenses these days, so that's a given. But non-commercial share-alike?

It's a decision made on auto-pilot, but I see it today with fresh eyes. It's an anti-commercial message cleverly disguised as "serving the public good". It's more of a quiet rage wasted against the vastness of the world. Something that could be a battle cry, if I actually wanted to fight.

My art is a hobby. It's going nowhere, commercially speaking. And I'm fine with that—I'm striving to be a world-class programmer (if I'm not already), so my art can be a hobby. It's not something that has to be fully under my control or I'll starve. So, in acknowledgment and celebration, I've relicensed the fin critter as BY (attribution only).

CSS is a losing prospect. I hate to say it, because it's taken 10 years for browsers to get close to finishing their implementations of the last version of the specification, but it's true.

The core problem, as far as I can see it, is that CSS was designed by programmers who had gotten into the XML just a little too much. They didn't consider any real-world design scenarios in building their language, such as runarounds, rounded corners, baseline grids, or columns. They just threw some stuff together that seemed nice, and told us not to use tables anymore.

Actually using CSS anymore is one hack on top of another, just to get the CSS to do what you want in the first place. And once you've gotten that far, you have to hack it again to get it to work in the browsers, due to bugs and the occasional vague part of the spec whose interpretation hasn't been agreed on yet.

Why are all the hacks so necessary? Why is it so hard to use CSS to replace tables? Didn't the designers see that everyone was using tables for layout, so CSS would need to be able to support table-like layout?

Obviously not.

As I said before, the designers were filled with the Way of XML, and they saw the document as a tree. The tree was defined by nesting elements, such that every element has exactly one parent, and any number of children. CSS graciously lets us style elements relative to their single parent—and that's all.

And therein lies the rub. If one paragraph follows another, there's no way for either of them to take any style information from the other. Without shared ancestry, all is for naught. If one column follows another, if one block of any sort follows another, there is no way to make them aware of each other.

Whereas in the glory days of tables, all the cells in a row were related, and took on the height of the tallest element, with absolutely no hacking. You wanted columns? Three-cell, one-row table. Header and footer? Two more rows, each with colspan="3" attached to their respective cell. Rounded corners? A table with images in the four corner cells.

And then they told us not to use tables. We stupidly listened, and millions of hours were wasted trying to re-create tables without tables. And now those hours of raging at the quality of CSS, and the bugs of IE, are preventing us from letting go of this feeble, useless language.

You don't even get the benefit of cleaner markup, because it becomes a forest of divs and spans, ids and classes. And the declarative nature of the CSS tends to lead to mazes of twisty little rules, all the same, as color codes get copied all over to make this-and-that work. You end up having to walk all over your user to get any moderately complicated design working, because you can't find out if they've changed their default font size/color/style, so you have to set it all yourself unless you want your site to look broken to random people. (Not even touching Microsoft's bone-headed "Let's pretend our 72-dpi display is 96 dpi!" move that makes fonts render inconsistently between platforms...)

DO NOT WANT UR CSS.

Recently I took on a new job, working in an Ubuntu/RHEL world. Since the install CD they had was Ubuntu and not Kubuntu, I decided to give GNOME another spin. It's been a few years since the Featureless Rewrite. And seeing as how I like running a similar environment at home and work, I migrated my Kubuntu install over to Ubuntu at home.

Many applications have remained the same in the two worlds, including firefox, gimp, and (g)vim. It seems that the only KDE app I was using heavily was Akregator, the world's best feed reader. I started off looking for a GNOME-ish or GTK equivalent.

Liferea at first wouldn't update the feeds, so I moved on to Blam, which crashed when loading feeds. It's managed code, and it crashed. Unbelievable! Finding all other mentions of feed readers to be so hopelessly outdated that Ubuntu doesn't offer them anymore, I tried Sage and Google Reader. Although Reader had the "next unread item" magic link, it loads the target website instead of the article, and is therefore as slow as said target website. And it uses our bandwidth. Sage completely failed at this test, having no "next unread item" key.

I tried liferea again, which updated feeds and then proceeded to crash when I hit Ctrl. It looked promising, so I tried again, to have it crash when I released Ctrl+N. Clearly, this is not a random crash, but a showstopper.

This means my new feed reader is my old feed reader, snownews. It runs in a terminal, has the H key for unread items, and nowadays it can even launch a browser. I wrote a small shell script to background the browser (and nohup it so that exiting snownews doesn't kill Firefox), and I have an adequate reader.

<RANT VERSION="1.0">

I came across a rant by Erik Naggum via programming.reddit today, and I think I'm beginning to get a solid picture of why Lisp just doesn't fit into modern software development.

Lisp has been dying for 20 years or so, while young upstart languages like Perl, PHP, and Java have arisen to conquer the minds, if not the hearts, of millions. (And you could say, "of all things!" about any of those languages.) Why is it so? It is because Lisp is the old grandfather, who could produce amazingly solid pieces of furniture out of a twig and three blades of grass, ranting in the corner about how in the Old Days, we had versioned filesystems, and let's see your young whippersnapper code run on VMS by gum, there was never a better system made....

Perl just absently thumbs its nosering and says, "Whatever. man perlvms." and hits PLAY on its iPod and chills out to map { while (unlink $_); } readdir <DH>;. Pesky old versions, anyway.

Lisp was quite good, as a cross-platform language, back in 1970 when they had old versions (and all the young'uns like Ritchie said, "Dude, let's use our disk space for useful stuff instead of old stuff, and let RCS handle the stuff you really want versions of.") But now it's old, crufty, and moldering, while these younger languages actually do stuff you'd want to do today, like having sane socket, pathname, regex, and string-handling code. (Except maybe for PHP.)

So Java is this cross-platform language, with an adequate standard library (OMG! Collections!!) and a horribly verbose syntax. But it has won, because being cross-platform and having a library that isn't packed with horribly arcane names like NCONC is far more important to people than syntax and even dynamic-ness. In fact, Java manages to turn its suck into a win, because it takes so many lines of code to do anything. If you're grinding out volumes of code to emulate dynamic language features, then it looks to the boss like lots of "work" is getting done. w00t!

This is why so many people got excited about the promise of Arc. Paul Graham said he had the guts to build a useful Lisp, and this was all he needed to generate such massive expectations that the intertubes were practically on fire when he released something to play with, and it didn't cook dinner for you so you'd have extra time to hack on your webapp. Such is the power that Lisp-the-idea holds over those who have been repulsed by Lisp-the-reality.

And so now you get people upset that their language is getting the thumbs-down from most of the world, and so they go off and rant about how programmers sold out, and all of Lisp's problems could be solved, if only we all had the courage to use Lisp in its current depressing state.

Whatever. docs.python.org!

The experimentation with distributed version control continues, taking its first leap onto multiple machines. As such, the Mercurial repository for mail_rss is now available via http://www.sapphirepaw.org/hg/mail_rss/. I'm afraid it doesn't have much history because I was incredibly lazy at the beginning, and hard-coded my password into the script to get the first IMAP connection running.

The companion project, ziprunner, has its own Mercurial repository available under the suspiciously similar URL of http://www.sapphirepaw.org/hg/ziprunner/.

Oh yeah, and mail_rss is Python 2.3-compatible again. Generator expressions apparently didn't arrive until later. One item down, ∞ to go.


Update: There are now tar.bz2 and zip format downloads. And the ziprunner repository should actually work now... my bad.

As programmers, sometimes we like complexity for its own sake. What could be more fun than working on building a huge, world-changing system? We look at today's Apple, Inc. and think to ourselves, "If only we were such a visionary as Wozniak and Jobs." Or we see Google's dominance and place Brin and Page on a pedestal, and ask, "Who is like the beast? Who can fight against it?"

Yet those systems we see have grown over time, incrementally. It's a lot easier to add complexity bit by bit. Old parts of the system are refactored from logic to experience in the mind, and the latter doesn't seem to occupy space in working memory. It's just there. When we try to prove our own mettle by duplicating (or besting) these complicated systems from nothing, we are stacking the deck in favor of our failure.

It's also necessary to be careful when coming from a project that has grown complicated and starting something new. I've noticed that in a new project like that, I start seeing the complexity of the final goal instead of the complete lack of code before me. I'll start working out the backend interface in all the details it will have to handle, and I end up writing a lot of code that doesn't work because I've never had it complete enough to really test.

The only successful strategy to producing simplicity is to keep asking at every opportunity, "Is there a simpler way to do this?" If a system or component is never faces judgment on the basis of our goals, then those goals become meaningless. When simplicity is the forgotten goal, then complexity tends to arise in its place, constantly beckoning failure.

Simplicity isn't necessarily the ultimate design goal, but it's an important aim for a budding project. People like to work, but also to make progress. Getting something running soon is far more rewarding than a long march to a complex system. Each working version stands on its own as a visible indicator of the progress being made, feeding that psychological need for our labor to be useful. Thus, those who are able to fight the beast are the ones most unlike the beast.

PHP caches, inspectors, and debuggers can all be implemented as (zend_)extensions. This makes me wonder if there's enough access at those levels to be able to create an extension that would compile PHP code with lexical scope, without rewriting the whole parser/compiler. I would probably have a special lexical_include(filename) or something so that non-lexical code didn't bug out.

It would also be highly interesting if undeclared variables in a local scope, which were present as properties on $this, could be accessed via $this without requiring the use of the this-pointer. But my instinct tells me that down that path lies madness.