The Perl Journal March, 2004
Automation is one of those futuristic promises, like personal jet packs and TV wristwatches, that never quite seems to be fulfilled. The personal computer has had more than two decades to deliver us from drudgery, and while it has undeniably made some tasks far easier, there's still a lot of drudgery going on out there, much of it done, ironically, on the computer.
Part of the problem is that computers don't solve every problem. And even for the problems they do solve, we have often underestimated the difficulty of devising algorithms to describe our tasks. It's a fundamental human/machine incompatibility, and those of us who are the most adept at resolving that incompatibility become programmers (ideally, that is).
But there's a more subtle problem that holds back our potential to automate those tasks we really would rather that our machines did for us. The problem is that those who most need the automation are often those least able to provide it for themselves. The best person to devise an automatic process is the person who normally does the process manually and knows that process in agonizing detail. If it solves their own problem, they are highly motivated to make it work properly.
This is the whole idea behind scripting languages: Give the power of the for() loop and the if/else statement to mere mortals. Let the person who toils in a word processor or spreadsheet program write the code to take away their own burdens. That's the theory, anyway. The reality is that, even with simple scripting languages, the realm of the accomplished scripter is a rarified one. Tasks go unscripted because few people gain the skills to translate their detailed knowledge of a process into an algorithm for executing that process. Why the majority of people don't gain these skills is a whole separate matter that, even if I thought I fully understood, there wouldn't be enough room to discuss here.
Most people aren't programmers and aren't going to be anytime soon. What's interesting is the effect this has on little languages. They get used not by the general public, who need a really simple solution that they can tailor to their own needs, but by those of us who are already programmers. And what do we want? More features. So over time, complexity creeps in and puts these languages even further out of the perceived reach of novices. This also explains why some of the cleverest, best-designed software out there tends to solve problems that programmers have, not problems the general user population has.
Bottom line: The tasks that need automating either don't get automated at all or they get automated not by the people performing the task, but by white-coated laboratory wizards for whom the requirements of the project must be specified precisely. It's a fragile arrangement that often yields either brittle processes that can't change over time or too-general solutions that the end user has no idea how to implement.
The solution to this problem lies with perceptions. Some people are never going to like programming and will continue to do repetitive tasks just to avoid learning a programming tool. But, many others are kept from coding their own modest, yet effective, solutions simply by the perception that it's too hard or too boring. Or it just doesn't occur to them that there's a better way. Maybe it's just foolish optimism on my part, but I like to think they just haven't been introduced to the power and beauty of a simple foreach() loop.
Kevin Carlson
Executive Editor
The Perl Journal