Automation Is Our Friend

If you do it once, great. If you do it twice, frown. If you do it three times, automate it. Three Strikes And You Automate.

Even Unix adherents recognize how ugly and ill tempered their favorite child can be at times. But no matter how ugly Unix gets, it has a philosophy that makes all that ugliness worthwhile: Automation Is Our Friend. Everyday tasks that you do over and over can be put into a script so that you can encapsulate the knowledge of how to do them, and invoke that knowledge with a single command.

Find is cryptic. Sed is amazingly cryptic. Awk is a world unto its own. Why put up with these and other Unix tools? Why do we want to live in a world where -s means something different from -S (and I have to remember which is which)? Because in this world I can automate routine tasks.

It would be nice if there were automatable tools that weren't quite so cryptic, though. If find, sed, and awk weren't so cumbersome, they probably would have made it into Wide Spread Use amongst the masses.

-- Happily, you can use nice friendly languages like Python or Ruby as a replacement for unix shells and weird cryptic commands

If configuration files are text, then you can use built-in text manipulation tools to automate repeated processes. If configuration files are binary, then I'm at the mercy of the configuration program that knows how to manipulate them (it seldom being practical to write a tool for that one type of file). What manipulation of configuration files might you automate? Well, how about being able to use diff to see what changed in the configuration file? How about using patch to automatically change the stock configuration file to your favorite settings?

Are you using a GUI development environment that turns into a half-hour click-fest when you need to deploy? If there were command-line tools, you could automate it. Just start the script and go have coffee. Better yet, have a cron job start the script at night and send you email when it's done.

I personally like it when I've got a nice slick GUI tool for doing things interactively, coupled with an automatable interface such as a CLI. Give me the best of both worlds any day.

Oh, absolutely, yes. But why do so few GUI tool makers provide CLI tools?

Here's why: There is one best way to do it, and the GUI is it. Providing a CLI tool to do the same things you can do in the GUI would be an admission of personal failure: because GUIs are inherently better, a failure of my GUI to be better for something must mean I didn't do it right. Better not to provide the tool so I don't have to see the evidence of my failure.

Providing a CLI tool for tasks that need to be automated doesn't make the GUI any worse at what it does, but it openly admits that the GUI isn't the best tool for all tasks. We'd rather not admit that, so let's not provide a CLI tool.

The other reason is more practical, but not as fun to rant about: The traditional breeding grounds of GUI development tools provide much a weaker command-line environment than Unix, making CLI tools harder to work with. And yet that practical reason comes from the same mindset: Why do we need to provide a strong command-line environment when we've given you this superior GUI environment?

I would argue that the DOS command-line environment was weak long before Windows came along. :) That said, the vast majority of users (not programmers) don't really care too much for system-wide automation. At most, they're quite happy with being able to run a "Record" feature in their favorite GUI app and just maybe tinker with the resulting macro. Mind you, with the number of times I've seen people doing a Mail Merge by hand, it looks like they don't bother learning the automation they've already got. If a larger subsection of the market wanted automation, then they'd probably get it. (Note: automation != CLI by default. It's just that it's easier to automate on the command line in many cases)

But of course. The problem is, you don't miss what you never use, so how make the masses understand that they're throwing their effort down the waste basket by not automating?

I rather think the problem is that we humans have pitiful utility functions, especially regarding activities that are incidental to our main goal. This is why we fail to Sharpen The Saw. People really do start using automation once the 'price' of setting it up becomes close to the 'price' of one instance of the repeated activity.

I rarely tell my email client to check for mail. It was as easy to tell it 'check for mail every x minutes' as it was to tell it to 'check for mail'. Actually, it was easier, as that was a default setting

I had a vcr, but I never ever taped shows, it was just too much effort. I got a dvr, now recording shows is as easy as channel surfing, I record often.

OK, Mr. Vendor, you're going to provide a GUI (and no CLI), for all the obvious reasons. Please, please, please also provide an object model, accessible from external programs. Then I can still automate things. ...not nearly as easy, but possible. [Note: This is the Micro Soft solution.]

As usual, Apple had this solution first

For Windows Users, if you've got a decent Component Object Model in your program, it's reasonably easy to automate it using javascript in the Windows Scripting Host. [Reasonably easy, in this context, meaning no harder than learning Perl or Bash Script to do something like this in a CLI] Of course, most Component Object Models suck, and so do most Apple Script interfaces for Mac Users.

A very simple example for applying the Automation Is Our Friend to "Wiki navigating and editing": if in browse-mode you see a typo for correction, then mark the text to be corrected and activate your command. The script reads window.location, isolates the part behind "?", inserts "edit=", browses to the corresponding Edit Text page and positions the cursor appropriately for editing. (Of course a Wysiwyg Wiki would be much more comfortable in this case ;-). -- Fridemar Pache

Is that simpler than just correcting the typo? Automation works best for things that can be done without much input from you. If the browser could find and correct typos automatically, that's great. But the bottleneck here is you noticing the typo, not the actual correction. If you make the correction easier then you are optimizing the non critical resource. -- Wayne Conrad

The most critical resource is our life-time, so each saved keystroke counts as long as there is no better automatic replacement. Count the keystrokes to correct the following typo and see how much time is wasted in a non-Wysiwyg Wiki. -- fp