Some fluff, some info

topics covered:

In which the author bitches, and then gives practical advice that will save (segments of) the reader's life.

OK, so here's some quick math that I worked out on a little spreadsheet. Say there's some little routine that takes you five minutes a day, and you could do some tedious work and eliminate that through an hour of research into correctly automating the thing or something. Then over the course of a work-year, you'd save 2 and a half days of time. In the words of the great Margaret Cho, you could take a pottery class. So some research up front can pay for itself many times over; this is nothing your momma didn't already tell you.

But when people sit in front of a computer---the paragon of automatability---people instead want something they can use immediately. A good program, we read, does exactly what the users thinks it should from the start (i.e., is intuitive). It should require no learning of new methods, and should instead analogize to real-world actions like pointing to things (i.e., clicking on pictures).

So if I've set up this essay correctly, it should be completely obvious that the first and second paragraphs there are in direct contradiction. From the perspective of efficiency, intuitive design is not helpful. On occasion we're lucky and the most intuitive and most effective method match, but in most cases we need to learn some new little method to implement the most effective route.

I am flabbergasted, horrified, and in despair over the resistance people have to learning how to use software. People will read the entire frigging Chicago Manual of Style rather than learn to use new software (see below). They're using this one program because in 1997, when they were afraid of computers, they could pick up that program and use it in the first hour---but it's been six years and they've used that program for a thousand hours a year, and they're no more efficient at clicking the little icons, and they spend more and more time trying to do increasingly complex tasks until they realize that there's no intuitive way to efficiently do the complex things they have to do.

Oh, the mortal cost of that first hour! What a seductive compact with the devil were those icons! The little sound effects were so pleasing, yet the software proved to be a siren which drains away all life, one pleasing mouse-click at a time.

We should face facts: we're in front of computers, all day, every day. That doesn't mean we like them, but if we like what they do for us, then it's really worth an initial effort to work out what's good software---not in terms of what matches your immediate intuitition, but what you can learn to use efficiently as you use it every frigging day until you finally reach the ever-growing retirement age and can finally just stay home and surf the Web.

Why I care One: I have to give tech support to people all day long. The fewer people using cute but annoying software, the less tense I'll be. Two: I want better software that I can use. All that effort that goes into making better eye candy for Word is wasted for me. Three: ``No [person] is an island,'' wrote John Donne, and it truly, physically pains me to hear the travails of somebody who wrote their dissertation in Word, which you'll recall the New Yorker describing as a terrible program.

Things you can do Here are some things that are not intuitive, require reading the manual, and will save you huge tracts of time. Listed in order of commitment. You don't have to read the whole manual for any of this; you don't have to memorize anything (just leave the manual open for reference somewhere and you'll remember the important stuff soon enough); you just have to learn enough to understand the basic framework and to know where to look for more info. Geeks will notice a thematic relation between this and the essay of 10 November, q.v.

Stop using the mouse. Most of what you can do with the mouse you can do with the keyboard, such as switching applications ( +), or dealing with the menus (+underlined letter). Not taking your hands off the keyboard is the sort of thing that will save you 1.2 seconds two hundred times a day, for a total of one free coffee break. People used to stand behind me when I was working with multiple applications, amazed at how quickly I could do stuff without using the mouse. They seemed to think it was magic. I thought it was funny.

[And you have learned to touch-type, no? Me, I learned by putting a t-shirt over my hands so I couldn't subconsciously peek.]

Use style sheets. Witin your word processor (e.g., Open Office), there's a feature that gives you a list of header types. Instead of specifying `boldface, larger, new font' for every header, you can instead select `header 3' and the rest is set up for you. This requires initial setup and some cognitive effort, but once you've set up your headers the way you like them, you never have to do it again. When your advisor/boss tells you to change all your italicized headers to underlines, you only have to change it in the style sheet, instead of hunting through a hundred pages looking for all the italicized headers. [In Open Office, this is `the stylist'; no idea what it's called in Word. RTFM.]

Never, ever, write a bibliography by hand. Intuitive, direct method: read the Chicago Manual of Style and learn the rules for italics, punctuation, and ordering. Efficient and effective method: use a bibliography database. LaTeX has bibtex; Open Office has a built-in bibliography manager; for about a hundred dollars, you can purchase EndNote for Word. [The lack of a bib DB is reason enough to dump Word. Thinking about the pain my mother sufferred writing her bibliographies in Word makes me well up.] You have to set up your bibliographic info in a database, then insert formatting codes into your document, and then you're guaranteed that every last comma and period will be in the right place, and that when you refer in text to Schweitzer[15], that Schweitzer is not number sixteen or fourteen in the bib.

Stop using your spreadsheet as a database. Spreadsheets make it easy to instantly create a list of things. The same guy I linked above (Joel on software) worked on the MSFT Excel team. There they were at MSFT, designing amortization wizards (because amortization should be intuitively obvious), and one day they watched some users actually use their stuff, and found that most users just used their software for writing lists; so they added lots of list-making and list-handling features. However, there's actually an entire field of program built from the abstract algebra up for making and organizing lists: databases. As with everything else I'm talking about, databases are conceptually unintuitive, require setting up before you can start writing lists, and will save you hours and hours of your life in the long run. You may have a copy of MSFT Access on your hard drive right now.

[Data geeks: instead of using SAS or whatever, check out SQLite; between that and the GNU Scientific Library, I have the data analysis package I'd always dreamed of. Since 10 November, I really did switch all my models and statistical analyses to C, and the effort has already paid dividends.]

As a matter of fact, dump Word entirely. Even ditch Open Office, which is nicer but still the same ballpark. LaTeX is the best document preparation system in existence, by far. Many authors typeset their books in it. Same as above: initial learning curve, new paradigm, won't get anything done the first few hours, but will save you weeks of pain in the long run.

[There are graphic shells for LaTeX, like Scientific Word. They unabashedly suck. I have pals who write their complex equations in SciWord and then cut and paste the resultant LaTeX codes into their main text-edited document, which seems like the optimal use of these things. People who LaTeX from Windows are fans of WinEdt, which has some nice LaTeX-specific features.]

No, better still, dump Windows entirely. Do I need to say it by now? Windows is aimed at being intuitive from the get-go, while the Unix-type systems are aimed at automating and simplifying your work and then getting the f*ck out of the way. If you have a life sentence with one paradigm or the other, forced to spend a thousand hours a year chained to a keyboard, which would you choose?

Windows people: try Cygwin, which installs a Linux box within Windows, so you can use LaTeX there, and produce beatiful PDFs that you can pretend you wrote in Word. [That's how I'm writing this now, so if a Windows fascist comes by, I can minimize Cygwin and pretend I'm using Windows. In my experience on this machine, Windows & Cygwin coexist nicely.] MacPeople: if you're running OS X, you've already got a Unix box; get to know it and the non-Mac software which will help you do the above.

The commitment here, by the way, is not in installing the OS, since Unix will coexist with Windows or OS X, but in learning the myriad or two of programs which Unix facilitates. If you're still avoiding work, have a look at my essay on Unix and its users, linked at right.

[link][no comments]

OK, this was going to be a lament about any of a number of things, with a general discussion of how to design things to be useful but not annoying. However, I fear that it's going to turn in to a rant about MSFT. Sorry, guys.

It's about designing things for dumb people. This is, by itself not a bad thing. After all, designing for less cognitive effort benefits us all, just as features designed for the handicapped are often embraced by able people who just want it easier. [I've been using the twiddler lately; it would be most useful for people who only have one functioning hand, but I like it because it lets me drink tea and type at the same time.] Or, at the other extreme, here is an article about how an unintuitive interface killed John Denver.

The two prime examples of this would be advertising and MSFT products. I think the whole thing about idiot-proofing Windows has been discussed to death, and needs no elaboration here. I've already talked about how advertising has gone from a long textual evocation of the product (with bold headlines for those who are just skimming) to a picture of the product being held against a pair of breasts.

Don't get me wrong, intuitive interfaces and things that dumb or inattentive people can readily digest are not necessarily bad. But what makes them horrible is when the design makes it impossible or too difficult for not-dumb people to go beyond the dumb level.

For example, when waiting for a subway train, I am confronted with a number of large, backlit ads right in front of me, and I typically have about ten minutes to kill. This is the perfect opportunity for the vendor to tell me all about the product, in great, backlit detail. And yet all settle for a picture. and a tag line. with inappropriately placed periods. where a comma or hyphen will do.

This is true for both SBUX, which will just show you a picture of a cup (which we presume contains coffee) or Boeing/McDonnell-Douglas, which outbid SBUX for ad placement at the Pentagon Metro station, and advertises bombers and helicopters. Surely there's more information that we need to know about the latest bomber than about a cup of coffee?

But the advertising won't tell me. If I care, there's nothing for me to do for ten minutes but to stare at the picture some more. Oh, I could look elsewhere, but I'm not elsewhere. I'm on a subway platform, waiting. I want to see the information that got thrown away in a desperate attempt to get the point across with a minimum of cognitive effort, and am frustrated that I can't.

The other prime example of this is of course anything written for MSFT Windows. It's easy to sit down and use, which I would be an arse to be annoyed by, but it's supremely difficult to go beyond the easy stuff. Spent an hour yesterday trying to get the cute little browser thing to hide files beginning with a dot. I even wrote Dell tech support, who blew me off. As you can plainly see, if I want something that seems possible, but isn't, I will be frustrated and unable to continue to function as a normal human being. My favorite foil whom I've linked to before, Joel, goes on and on about how frustration comes from having things that don't work the way you expect them to, adding little bits of cognitive effort and annoyance to your day. Joel probably describes many people, but I am most frustrated by tools that just plain don't work. Screwdrivers are truly counterintuitive, if you ask me (to make screw go out, turn counterclockwise?), but I learned the righty-tighty/lefty-loosy thing. When even that doesn't help, (like the screw is upside-down or with the few reversed-thread nuts on a bike) I am indeed frustrated. But I am infinitely more frustrated when the screwdriver is made from cheap metal and bends when the screw is too hard to undo.

Implicit to all of these things is a promise: I will tell you about my product; I will help you make your document look just right; I will unscrew your screws. Sometimes getting that promise to work takes some compromise from both sides, which is how life is. It's not the compromises but the broken promises that really hurt.

Somewhere, I read about how temperature gauges are less common on cars now, since somebody worked out that most people interact with the gauge by just looking to see if it's in the red, and panicking if it is. So why bother with a gauge? Instead, you just get a little light that tells you when the temperature is in what would have been the gauge's red part. I told Mr. DRC of Santa Monica, CA---a car expert if ever there was one---about this, and he had a hissy fit, listing three dozen things you can learn from a temperature gauge beyond whether it's in the red. So in following Joel's advice about minimizing cognitive effort for 95% of drivers, the other 5% are frustrated and dejected.

It doesn't have to be that way. Design that includes the lazy doesn't have to exclude those who care, and if it does, it's as bad a design as one that only makes sense if you study it for an hour.

I tried to come up with more examples of where things have been redesigned for the lowest common denominator and thus shut out those who care, but couldn't think of anything really good and pervasive. Television has always been written for dumb people, and since there's a time constraint, you have to pick your level of information and stick with it---unlike a print ad, it's physically impossible to say more. There are thousands of books with `for Dummies' in the title, but there have always been such how-to books, and for every such book, there's another that goes into all the detail you could want. This is even true of management books, which are typically the most supremely oversimplified books in existence, since businessmen often have a pompously overinflated idea of what their time is worth. Perhaps you, dear reader, can leave some suggestions in the box below.

Meanwhile, I have nothing but a lament about the two realms where withholding from the consumer is vehemently defended as a good thing: working with PCs, and advertising. One particular item stands out as the intersectionof the two: MSFT PowerPoint, a computer program for creating advertising presentations. Its design makes summarization and mimimization of cognitive efffort easy and information dissemination difficult. E.g., as a counter to the too-difficult design interface which caused a disaster above, PowerPoint's design is partly responsible for the destruction of a Space Shuttle.
[link][2 comments]

So I've added an RSS feed, at left. With an RSS reader, such as amphetadesk or RSSowl, you'll get notified whenever I update this little web site. The idea is that you just check in to your RSS reader instead of clicking through to the dozen web sites you dutifully check every morning. Like all the other crap I endorse, it's not revolutionary: you spend half an hour setting it up and reading the manual, and then it saves you four minutes of clicking per day = a full day of clicking per year. I have to admit I've only had my own RSS reader for a day, and only have vicarious raves from people who say that having one of these little news tickers open has entirely changed the way they get information and has made them finally feel that enlightenment is attainable in this lifetime. I wonder what I'll do to kill time if I can't waste it checking to see if anything new has turned up on Plastic in the last six minutes.

Asst links But there's always more (not-regularly-updated) junk to be had. In addition to the usual list of links, I offer the following, for my fellow distraction-seeker.

I'm at the World Bank today, copying data sets to my own portable hard drive. Instead of a bar crossing the screen, the little application opts for a ball that grows in size. Very cute. Almost beats the status bar from Halo.

On the desk here is a copy of Bank Swirled, the in-house humor magazine. It's filled with in-jokes and standard office humor. Representative sample: ``hello. I'm a constipated water buffallo. Is there a World Bank program to help me?''

Pocket calculator show is about 80s technology, back when things still had buttons, instead of a screen with pictures of buttons. An interesting idea, though I wonder why they don't just go all out and talk about 20s technology, when adding machines were made from brass and wood.

Equally retro but more hands on, here is a set of Infocom text games for you to download and play. These games are a paragon of good computing and bad humor, and can be run on pretty much any modern hardware (including a lot of phones).

This photographer took some wonderful photos of Thailand. Interspersed with the photos is an extensive discussion of how he went about backing up the digital photos onto both a CD and portable hard drive. The contrast is stunning.

Oh, but it gets geekier. Here is a list of numbers.

I've been very interested in alternative keyboards. I mean, you can have the most efficient software on the planet, but if you have to wave your hands around in painful ways to use it, then it's still not efficient. When I have any say in the matter, I use a split keyboard with built-in touchpad, in my lap. But I sometimes fantasize about what life would be like with these more innovative designs.

OK, time to take a stretch break.

And, of course, if all else fails, there's always cartoons, TV, or naked people.

[link][no comments]

So back in April, I'd written about the joy and delight of the RSS feed. The summary: whereas the web had once been an endless pit of time-consumingness, RSS made it manageable and easy. Whereas I'd spend all day in glassy-eyed clicking before, I could now spend a little under an hour reading everything I could possibly read, and could then move on to do things involving the real world.

Oh, how times have changed. I now have so many RSS feeds that it is a truly Sissyphean task to read them all. Whereas before I could have a set, fixed endpoint (`stop when I've read all the feed updates'), this is now impossible. Meerkat, O'Reilly's wire service, will feed me a thousand links a day. Seriously reading two percent of that is already an hour. And I haven't even gotten to the newspaper yet: the New York Times will feed me a hundred articles a day, of which I'll want to read a whole lot more than two percent.

In other news, I've entirely stopped reading anything that doesn't have an RSS feed. I paid some guy to write up an RSS feed for Toothpaste for Dinner because it's funny in a severly embittered kind of way, but with no RSS feed pushing it upon me, I never looked at it. So I'm more lazy, but not actually saving more time.

The other thing that amazes me about all of these RSS feeds is the immense repetition. First, there's direct copying: Meerkat aggregates other RSS feeds, without editing, and puts them out for you in one feed instead of several. [And so, given that feed readers are now a dime a download, I'm not sure what its point is anymore.] And of course, other blogs frequently have entries among the original content in the way of `so over at this blog, they say...' without really adding much of anything.

But beyond that is the original generation of the same idea that ten other people also originally came up with. As some of you may know, I'm writing a book on software patents, so many of my feeds are about intellectual property, and frankly, the news is almost exactly the same on all ten of `em. Even the stories themselves tend to repeat; I've simply stopped reading DMCA cases, they're all so alike (as is the outrage they inspire again). This form of repetition feels even sillier than the blatant copying above---at least there was no effort expended in copying. Here, there are extensive write-ups which boil down to the same facts and the same emotions; if these guys all teamed up, they'd have one feed with the same content and a tenth of the effort.

In my own head, this turns into a constant pressure to not repeat myself or others. The `others' part is frankly kind of easy: since all ten of our IP authors look at IP in the same way, I really only have to distinguish myself from one mindset. The `self' part is getting harder and harder. This is my 75th blog entry, and I simply don't have 75 actual real live ideas. This blog has been up for almost a year, but others have been up for the better part of a decade---how do they do it? It constantly worries me, and is the reason I've been posting less lately: when am I going to hit that age when everything I say is just repetition, and have I already hit it?

[link][a comment]

[A dump of a large number of small pieces of advice from years of shunting data. File under `boring but useful'.]

Problem statement: You work on multiple computers: home and away, or a desktop PC and a laptop, and you want to use both to work on the same projects, so you need some way to reliably shunt data back and forth. Me, I have three home laptops in various states of brokenness, a PC at (name of think tank) and a PC at (name of university), and a few accounts in the ether somewhere which I log in to from time to time, and all that has to keep reasonably synced up.

Buried into all of this are a few regimes for backing up data. Not to be mean or anything, but to those of you who aren't backing up their data regularly: what are you, fuck*ng stupid? If your work is worth doing once, it's worth making sure you don't have to do again. [Personal to Ms. JATMM of Mount Vernon, VA: my continuing condolences. I don't mean you.]

Step one: have a home dir: Unix geeks, you already have a home directory. But you Windows users probably have data spewed all over your hard drive. Many programs like to make their own little directories for storing data, so your MP3s are in c:\Program Files\Brand Name\Program Name\Data, while your great unfinished novel is in c:\Another Brand Name\Word Processor\user Xp458yjz\documents\. Get them all in one place, which I suggest you name c:\home. [If you have multiple partitions, use the one that the operating system isn't on, which will probably be d:\home. If you don't know what a disk partition is, don't worry about it.]

MacPeople, you also have a home directory, but OS X tries to hide it from you. You have a Unix command line (the Terminal, in the Utilities folder); get to know it. Since I don't have an iAnything at hand, maybe somebody else can offer more suggestions in the comment boxes below.

Put all your data in the home directory. Make yourself c:\home\novel, c:\home\music, et cetera, and stick with the plan, even when your programs try to distract you. Linking (aka shortcuts) can help with this: e.g., set a shortcut from the Desktop directory (wherever it is; Microsoft keeps moving it) to c:\home\desktop.

The idea here is that if your computer falls to pieces, all you have to do is reinstall the software and then copy back your home directory, and it will be as good as new. You probably have reinstall disks for the software somewhere; you're basically making yourself a reinstall disk for your work.

Further, the costs of hard drives will hopefully be in sync with the amount of crap that you increasingly collect over the course of your life---and so you'll never have to throw anything out, ever. Instead of putting your projects on floppies in the closet, you can keep everything you've ever done in your home directory, perhaps archiving from time to time into an archive subdirectory. Me, my /home/b/arch directory includes everything I've done on a computer since 1999. This comes in handy more often than you'd expect.

Also, dear Windows people, you may want to get a copy of Cygwin, which will let you execute the Unix commands below. You want this to be as easy as possible, and writing a batch file to run the command will, in the long run, be a lot easier than clicking lots of little boxes in WinZip every time, despite the initial setup. Also, children and animals will like you more.

option one: Directory replication We have two options here: the first is to find a place online, and the second is to carry around a physical object.

suboption one: Online: this web site is hosted by Spiderhosts.com. I pay fifteen dollars a year and get thirty MB of storage. [Tell `em I sent you and I'll get a discount on my renewal.] That's enough for a lot of the important stuff. There's also gmail.com, which will give you a frigging GB, and if you need more, I guess you can just get two accounts. Depending on the status of your connections, the internets may or may not always be available; this obviously won't work if you're not ubiquitously networked. [Personal to Mr. PH of Seattle, WA: now that Presidential decree has pluralized internets, I think it should be lower case.]

subsuboption one: with compression One line:
tar cvz --exclude /home/b/mp3s /home/b > my_home.tgz
Then email my_home.tgz to your gmail account, or what have you. When you get to the other computer, you can decompress by going just above your home directory (like c:\) and typing tar xvzf my_home.tgz
WinZip or StuffIt or what-have-you will work OK, but there's no easy way to tell it to exclude c:\home\mp3s. Maybe you can make it work.

subsuboption two: without compression Use rsync, which will only transfer the changed part of files which have changed, making for a very quick transfer:
rsync -avPe ssh --delete --exclude /home/b/MP3s /home/b/ b@fluff.info:home_bkup/
This is especially nice if your home or work PC is always on, in which case you can just transfer directly. Check your router to see your home IP address (which is not reliable because most DSL/cable companies will change on you to keep you from doing this sort of thing. If your ISP uses PPPoE instead of DHCP, complain.), then turn on sshd on your PC (easy if you're unixy; I'm told cygwin will also let you just type sshd at the command prompt but never tried it myself). All you need is one of your two PCs to be identifiable by an IP address and have sshd running and you're good to go.

The --delete option gives me a rush of fear and adrenaline every time I use it. But even without that, this is dangerous because if you reverse the from and to directories, then you'll overwrite your new stuff with old stuff, thus losing all the work you just did. Nothing sucks more. With compressed files, you can of course have the same problem.

More advice: think of one and only one drive (your home hard drive, work hard drive, your portable drive) as your primary home directory. In others, set up an xfer_me directory of things that need filing back to the primary drive. The assumption is that if any of the non-primary computers go up in flames, you won't care. Day to day, you just need to transfer the xfer_me directory back to the main from time to time, and then overwrite the non-primary home directories with fresh copies of the primary now and then.

Another useful tidbit: if your computer is a laptop, and you have a home network, then both of your computers are sharing a subnetwork. Your desktop probably has an address like 192.168.2.101 and your laptop something like 192.168.2.103. If one of these can run sshd, then you can directly rsync directories, and it'll be rather zippy.

suboption two: physical device: This would be something you carry around with you. Pretty much anything will work: those little USB keychains, your MP3 player, even your digital camera can probably store files for you. Portable storage is frigging everywhere. The obvious problem is that if you forget it at home, you're screwed, but it will of course work if you have no Net connection. Also, don't forget the cable, which I've done embarrassingly often. [Spare tip for buying a spare cable: A bit of poking around online should find you the formal name of your cable---more and more are A-mini B---and you'll find that you pay a lot less for an `A-whatever cable' than a `cable for brand name device'.]

Devices that your operating system recognizes as just another drive are the best; some devices (Kodak cameras, Apple iPods, Creative MP3 players) require additional software, which will require installation everywhere you want to use it---annoying. On such devices you may have to archive your home directory into one file (see subsuboption one, above) and then copy that single file over.

The world of devices falls into two categories: flash memory based and hard drive based. With a hard drive based device, you may as well make _that_ your home directory, since you should have enough space to do so. The only problem is that there's a slowdown with external hard drives; unless you've got really good equipment, it's noticeable.

[Me, I have an Archos Jukebox, which mounts normally and has the imprescindible feature of rubber bumpers. [That's Spanish for `can't-pass-up-able'.] I partitioned it into a vfat partition for the music (`cause the firmware demands it), and a reiserfs partition so I can have the pleasant features of real-live links, permissions, and a journal.]

Flash-based devices tend to give you much less storage---you'll have to leave the MP3s at home, and just back up the important stuff. That's OK with the above methods, since both give you options to exclude directories (which is why you want to do this from a batch file, where you can specify what to exclude once and for all). Not a problem, but don't forget to back up the data you're not carrying with you some other way.

Since you're not networked, you don't need the `e ssh' clause:
rsync -avP /home/b /mnt/cygdrive/e/home_bkup/

The biggest practical problem with both of these methods is that you have to remember to transfer every single time. If you work on the project at home, rush to work without transferring, and then work at the office, then reconciling the two versions will be a nightmare. You'll almost certainly lose data, which may make you cry.

option two: versioning systems The idea of a version system is that you have a repository somewhere which holds the project. When you want to work on it, you check it out, and then check it back in when you're done. Once checked in, your copy is entirely disposable.

Using a versioning system changes your mindset. You can screw with your copy of the project all you want, since it's just a copy; you don't have to save lots of revisions, since the system is doing that for you; you'll find your work will be more structured around work sessions which have a specific goal. It's fun.

Finally, it solves the problem of forgetting to bring to work changes you made at home, since it will do its best to merge two modified versions without losing anything. This sometimes requires human assistance (it'll tell you when), but you never lose work.

The standard revision control system is CVS, which (if you're using Cygwin or anything unixy) is on your hard drive now. CVS has been replaced by subversion, but subversion isn't yet common, in the sense of any given computer basically being guaranteed to have it. If you're reading this more than a year from now, try that first.

Once you set it up (RTFM), the only commands you'll ever need are
cvs get my_project
cvs ci (aka cvs commit)
cvs update
Oh, and when you add a new file to your project, don't forget
cvs add new_file ;
forgetting that is basically the only way to lose data with CVS. If you ever need an old copy, or to do weird things to your data, RTFM, but it's very easy. There are also graphical shells like tk_cvs, which I have on one or two machines but never really bother with, since 97% of the work is the above four commands.

Oh, and don't forget to back up your CVS directory from time to time. Mine crashed once. I managed to not cry but I was grinding my teeth in my sleep a lot after that. You'll also have to decide where to put the repository. If you're a student at a university or a not-Microsoft-dominated office, then you probably have a shell account where you can put it. It's surprisingly small, so a spiderhosts account will do just fine for the rest of you. Unless you're doing something screwy, your CVS repository will be under a few dozen MB, so a keychain drive will also work.

[Tip on keychain USB drives: avoid puffy ones. I saw a girl almost weep when the only copy of her presentation was on a USB drive which didn't work because the plastic casing got in the way on the laptop she was trying to plug in to. She was also silly for not having backup: when traveling to do the Big Presentation, leave a copy online, on your keychain, and on a burned CD; chances are that one of them will work, but you won't know which until you get there]

CVS will work great for that part of your life which is project based, but you'll have to go back to option one to handle your MP3s and family photos. I think you're getting the picture here: the project you're working on these days should probably be in CVS, and then you can carry around a hard drive with all of the not-so-frequently-changing stuff that makes your home directory a home.

[link][a comment]

The basic principle behind Apophenia is that data should be kept in a database until it's needed, and then just enough pulled out for analysis. There are some things that are much easier to do in SQL, and there are some things that are much easier in a matrix-oriented programming language, and knowing what to do in which context can save hours.

Figure One: Just meant for each other.

Things which are easier in a database

Things which are easier in a matrix-oriented program

You're sitting there thinking, `gee, I could use a program to do a certain nifty trick.' You go online, ask your favorite search engine for nifty-trick programs, and get a list of two hundred. You click on a few, watch them fill your hard drive with crap that you can't identify, and click a variety of setup programs which spew garbage all over a still wider range of hard drive. You find one you like, but then it starts popping up `buy my shareware' reminders. Eventually, the whole system crashes, and then you have to dig up lots of CDs to reinstall your office package, your stats package, your graphics package, &c. Six months later, all the cool kids have switched to new software, and you have to start all over to upgrade.

I think we can all agree that finding and installing software sucks, which is where the package managers come in.

Here's an oft-overlooked detail about free and open source software: it's free, in the sense that it doesn't cost anything. Not only are there no access restrictions keeping you from getting a program, but people veritably _push_ the stuff on you. I only partially understand the motivations, but the result has been a host of ways to get free software, all of which are extremely easy, because somebody went through great trouble to facilitate your free-riding.

Thanks, guys.

The idea behind all of the below is the package: a single unit of program with a self-executing installation program. There's a repository somewhere, run by the e-philanthropists of the world (usually universities like UNC) which has the packages; you have on your computer a package manager which queries the server for what's available and gives you a list. You search for nifty-trick program, click on it, it installs. Six months later, the package manager works out that nifty-trick has a new version out; you click update and suddenly you have more features.

No need to involve Google and sift and sift some more; no need to go through yet another installation program which requires endless clicking of the OK button only to find out that it's not quite what you wanted. Getting a new program takes about a minute of your attention and zero dollars, instead of hours of your life and who knows how much of your cash.

The systems

Windows people

McPeople

Linux

[The GNU autoconf system, by the way, is an absolute revolution in how the world of free computing works. The likelihood that you download something and it compiles and works the first time is exponentially higher if it's built using the autoconf system, and that's what allows everybody to just set a few switches and distribute different versions of the same program for so many systems.]

Why they work

[Notice that stats packages don't follow this library-and-front-end standard. There are a hundred out there, and most of them write their own computational routines, and all of them write their own stats routines. Which is why the world needs apophenia.]

las quejas

[And autoconf is a pain to work with on the developer side. Having attempted to autoconfiscate my own stuff, the documentation is hard to work through, and if your program worked with autoconf 1.7, you may have to rewrite all of your scripts to get them to work with autoconf 1.9. The price we pay for magic.]

The pointers

The workflow

The libraries

Syntactic sugar

Learning C

Here are notes on object-oriented programming (OOP) in C, aimed at people who are OK with C but are primarily versed in other fancier languages.

It is to some extent a response to those who write C off as obsolete because it lacks the cute syntax of more recently-written languages. Without the cute syntax—with just 21 keywords and a lot of stars—you can still get as much interesting structure as other languages that impose the structure via more keywords or punctuation, and you can often do it in an easier-to-maintain way. So, here's how.


Before I start, I need to give the same caveat I always give when I write about C: I work in what used to be called computing and is now called scientific computing, mostly in statistical analyses and agent-based modeling (which the more ignorant insist is impossible in C. Haha, people pay me to do the impossible). If you're writing end-user programs with glossy GUIs, you're not gonna write the GUI in C. If you need a shell script, write it in Python. But the computations at the core of it can still be in C, and the methods below may help your C code play nice with your GUI wrappers.

What is this object-orientation?

How does C do it?

Inheritance and overloading

typedef struct apop_data{
    gsl_matrix  *data;
    apop_name   *names;
    char        ***categories;
    int         catsize[2];
} apop_data; 

the void, templates

 typedef struct apop_model{
    char    name[101];
    apop_estimate * (*estimate)(apop_data * data, 
           apop_inventory *uses, void *parameters);
    ...
} apop_model; 

 void move(void *in, char type){
    if (type == 'a'){
        a_type a_in = in;
        a_move(a_in);
    }
    if (type == 'b'){
        b_type b_in = in;
        b_move(b_in);
    }
}

This self

Refs

I was writing a blog entry about proselytizing, which I dislike and may not post, but one point that came up is that the only thing that I actively proselytize, the only thing that I really want other people to do differently, is to use a semantically-oriented document preparation system.

Yes, I realize this makes me a geek, and that maybe world peace should be higher on the list. But I've spent so much time watching people do horribly inefficient things for hours on end, and it pains me. It does.

So, I've written an article about it. Here it is: Why Word is a terible program, and the PDF version. It's the aggregation of a number of past entries, and is in no way about the politics of software. And why was it so easy to splice together such a volume of text? Because I didn't use Word to do it.

Oh, how cathartic. Now I can get back to writing grant proposals with a clearer conscience that I've done something to help the world.

[link][no comments]

[PDF version]

Those of you who actually read my posts about efficient computing, rather than just going to read the comics at the first sight of the word `computing', may by now have noticed a few patterns.

The most basic is that standards are important. I know this sounds obvious to you, but if it's so obvious, why do people get it wrong so darn often. Why are people constantly modifying and violating standards that work just fine?

I know many of you have suspected this for a while, but let me state it loud and clear: I am conservative. Rabidly conservative. I think that people need to have a really good reason for not conforming to technical standards, and I think most people don't--they just use the shiniest thing available. A large amount of my writing on technical matters is simply pointing out that well-thought-out technical standards tend to work better than the newest and shiniest, and that the value of stability often more than makes up for any flaws in the standards. Even my work on patents is aimed at making sure that open standards remain open and free to implement.

I originally tried to make this into an essay about both computing standards and general customs, but over the course of writing it, I came to realize that the two are fundamentally different. If somebody doesn't quite conform to your human customs--if they use the wrong fork or speak non-native English or wear ratty t-shirts to the office--then the person will be funny or diverse or annoying or just normal. Meanwhile, if computing standards aren't followed--if somebody gets sick of C's array notation, array[i][j], and decides it looks nicer as array[i, j]--then their writing is 100% gibberish and they might as well be speaking Hindu to an English-speaker. Standards-breaking in social settings can be fun; standards-breaking in computing is just breaking things.

So although I usually try to put something in the technical essays that will be interesting to those who could care less about machinery, I don't think any of the below is truly applicable to social norms. Or you can read on and decide for yourself.

Nor is this a comprehensive essay on standards drift and revolution, because that would take a volume or two. Just file this one as assorted notes on one question with an interesting proposed solution: what to do with all those people who keep trying to revise and update and modify the standards?

Schisms

But another approach is to let the whippersnappers fork. On the face of it, it may seem contradictory to think that splitting a standard in half would somehow make it purer, but under the right conditions, it can be the best approach.

For any technological realm, you've got one set of people who just want features--lots and lots of features, enough to wallow in like they're a bed of slightly moist hundred dollar bills--and you've got another team that wants fewer moving parts, and takes care to maintain discipline and stick to the existing norms. We can bind the two teams together, in which case they will constantly be fighting over little modifications to the system and neither team will be happy. That's what happens with English. Or you can have the schism.

Allow me to cut and paste from Amazon:

The C Programming Language by Brian W. Kernighan, Dennis M. Ritchie
274 pages
Publisher: Prentice Hall PTR; 2nd edition (March 22, 1988)
Amazon.com Sales Rank, paperback: #4,457
Amazon.com Sales Rank, hardcover: #445,546

First edition 228pp, 1978:
Amazon.com Sales Rank, paperback: #60,113

The C++ Programming Language by Bjarne Stroustrup
911 pages
Publisher: Addison-Wesley Professional; 3rd edition (February 15, 2000)
Amazon.com Sales Rank, paperback: #11,797
Amazon.com Sales Rank, hardcover: #6,215

First edition Amazon.com Sales Rank, paperback: #1,243,918

Things we conclude: C++ is much more complex than C--274pp v 911pp. C++ keeps evolving: from 1986 to 2000, the book has had three editions, over which it has tripled in size. People are still buying the 1978 edition of K&R C because it's still correct; the first edition of Stroustrup is so incompatible with current C++ that people can't give it away. Finally, Prentice-Hall really needs to lower the price on the hardcover edition of K&R. I mean, my book is selling better than their hardcover, which ain't right.

Meanwhile, C is as stable as can be. Cyndi Lauper has put out seven albums since K&R C came out. The changes from first to 2nd ed. of K&R are pretty small--literally, they're a fine print appendix. And, I contend here, it owes its immese stability to Bjarne Stroustrup. With Bjarne putting out a new version of C++ every few years that frolics along with still more features, Prentice-Hall is free to reprint the same version of the C book without people whinging about how it's missing discussion of mutable virtual object templates. The guys who want simplicity and stability buy K&R and the guys who want niftiness and fun features buy Stroustrup and everybody's happy.

The other technical standard I use heavily is TEX, and I'd been meaning, for the sake of full disclosure, to give a critique of TEXcomparable to this here critique of Word Fortunately, Mr. Nelson Beebe already did it for me, in this (PDF) essay entitled 25 Years of TeX and Metafont. The article alludes to exactly the sort of schism in typesetting as in general programming: you've got the people who are totally ignorant of standards and just want the shiniest new thing, and the people who built a standard system that has been stable for the better part of 25 years. Since he's on the standards-oriented team, he gives many examples of how such stability has led to large-scale projects that have significantly helped humanity.

His discussion of its limitations is interesting because there really are features that need to be added to TEX--notably, better support for non-European languages and easier extensibility. But "TEXis quite possibly the most stable and reliable software product of any substantial complexity that has every been written by a human programmer." (p 15) Changing a code base that hasn't seen a bug in fifteen years is not to be taken lightly, so the process raises interesting questions.

Evolution

So how do conservatives evolve? Are we trapped in using standards from the 70s forever more? Of course not. But the evolution is not from clean standards to floundering in pits of features, but revolutionary breaks from old clean standards to new clean standards. The feature pits are just distractions.

The process of evolution via incremental fixes to follow the trends has an unimpressive track record. Corporate-sponsored standards often suffer this failing (but not always), because setting standards that last for two decades and selling frequent updates are hard to reconcile. One company spent a while there naming its document standards with a year--standard '98, standard 2000, et cetera--which in my book means none of the formats are actually standard. The right way is to ride a system until it really doesn't do what you need anymore, and then revolt, building a new one that is clearly distinguished from the old, as we saw with DVD's overthrow of CD because CDs truly can not store movies, or Ω 's eventual overthrow of TEXbecause TEXtruly can not typeset Tamil.

The trick is to know when to revolt. When is a new trick so valuable that the old system should be abandoned? Many a dissertation has been written on this one, and I ain't gonna answer it here. But for well-thought-out technical standards, it's much later than you think, as demonstrated by the active 25-year old standards above.

[PDF version]

I can not stand how much debate there is about computing languages. I hate the fact that the Web is filled with it, I hate the fact that so many postings on Usenet in the way of `I need a Matlab routine to...' get replies like `Why aren't you using Algol!?', and I hate that my own work is so often evaluated based on choice of computing platform rather than actual output.

So, in my little effort for world peace, here are my notes on picking a language. I'll generalize this a bit next time, but the basic theme is that there is no One True Way. The process of picking a language is picking which is the least annoying trade-off, over the course of a series of many trade-offs.

The moral here is that, even though you will no doubt have a preference on one side or the other with all of the debates below, there is indeed a sensible other side, that other people prefer. That is, there are languages on both sides of any debate because there are valid reasons, both in terms of æsthetic preference and in terms of practical issues, for picking both options. Anybody who tells you otherwise, for example insisting that we must all use dynamically-typed languages from now on, is just being an ass. Pick the least annoying paradigm for yourself, and let your neighbors pick the least annoying paradigm for themselves. We'll all get our work done in the end.

Having ranted, here's a list of a dozen primary axes along which general-purpose computing languages differ. Work out which side you prefer, find a language that is on the same side as you, and go code.

1. Are the libraries what you need?

2. Does it assign types dynamically or statically?

If a system is