I don't know.

When I got my first serious job, I observed people logging into machines with rlogin instead of telnet despite (as I knew) the latter's being the newer protocol. "It's faster that way", they said, and at the time I couldn't make any sense why. It took me a while, but I finally figured it out: they were invoking it as rlogin -l theiruser, thus saving themselves from the interactive prompt for a username. (Many of them had also rigged up .rhosts files, so they didn't need a password, either.)

Unix folks tend to prefer batch operations for things they are already familiar with. It's not just repeatability. There's something to say for the "don't bother me" attitude against computers (and not, of course, against humans). Well-designed computer systems *shouldn't* bother us.

It becomes complicated when the same system serves both newcomers and power users. The web, unfortunately, is not a very programmatic environment, despite its success. Modules like HTTP::Recorder and WWW::Mechanize are indeed a great improvement over manual screen-scraping, but they're no match against a good API.

Don't forget that spreadsheets and word processors have been around for over twenty years now. They certainly have their markets, but ask yourself this: how popular are the (recording and) macro facilities in, say, Word? How many people do you know who can record or write a macro to... say, enbolden the first word in each list item? Consider that this is easy to do in Perl — once you know how. Not that I think it's hard to do with macros, but the scantiness of people who *can* do it is telling.

Only if you discount at least a decade of testing methodologies. Recording scripts is the primary way of testing GUIs.

The reason why spreadsheets are more popular than Perl isn't the interactivity - it's the simplicity. This is the reason why I haven't finished my simplified version of Quicken and gotten my family's books off of a spreadsheet. It just takes too damn long to write the infrastructure a spreadsheet gives you. Once you do that, adding new features is a lot easier. But, getting to that point requires more tuits than I have right now.

That said, spreadsheets don't have the same raw power as a well-written infrastructure, in any language. Plus, you can't run your spreadsheet in a batch mode. Remember - 99.999999% of all data manipulations are handled in a batch mode because they need to be. (Credit card transactions, for instance.) That's the entire point of computers - to do the repeatable tasks so that humans don't have to. They are tools - nothing more.

Meditate a little more on the topic, focusing on where your impetus comes from and how that relates to the general tasks of computing. Remember that the largest consumer of computing power for a very long time was the financial industry.

The reason why spreadsheets are more popular than Perl isn't the interactivity - it's the simplicity

I argue that it is the interactivity that makes spreadsheet manipulations simple. With a program you need to understand the whole, with interactive manipulation you need to understand only the atomic actions.

I don't say that the technique I described was not used before - I made an example with the shell history myself, another one I was aware of was Emacs macros, and neniro mentnioned Exel macrocs can be saved as VB as well. I just believe it is very powerfull and is underused, and we will see it applied everywhere and perhaps the words 'paradigm shift' were a bit grandiose, but I think it is new as a general approach to automation.

Two comments immediately come to mind.

First, this programming technique is indeed a fast way to solve certain kinds of repeated interaction problems, but leads to fragile systems. They tend to be poorly laid out, hard to understand, have lots of things that can go wrong that aren't handled, and so on. You should recognize this description if you've ever dealt with critical business processes that got started as a glorified spreadsheet from a non-programmer. Those drawbacks aren't a big problem for testing suites. But they are if you're maintaining production systems.

Second, my personal reaction to anyone who is excitedly talks about the next big paradigm shift is to label them as someone who likely doesn't know what they are talking about, and almost certainly doesn't understand Kuhn. Put simply, a paradigm worth discarding at the drop of a hat wasn't worth owning, and the paradigm that you discarded the first one for probably isn't either. Paradigm shifts are not good things, they're very expensive messes that sometimes become unavoidable. The value that is perceived in them could not arise but for the far less visible effects of people working within good paradigms before and after the shift.

If the second comment puzzles you, read The Structure of Scientific Revolutions by Thomas Kuhn. Again if necessary.

You're not meditating on the topic. You're blasting a response as quick as you can type.

Excel is just a application, written in some language. That language could even be Perl, for all you know! It is simple to use and simple to extend. It was designed to be simple in the simple case and powerful in the complex case.

Perl is a language. IT IS NOT AN APPLICATION. People use programming languages when the existing applications are either too simple, too heavy, or otherwise unsuited for their needs.

Please meditate on why you are insisting on comparing apples and Porsches.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Plus, you can't run your spreadsheet in a batch mode.

Correction. You actually can run a spreadsheet in batch mode by driving it using ActiveX. You can do this from Perl using Win32::OLE. There are limitations to the approach, but it can be a useful approach.

Absolutely true. However, I will still maintain that a spreadsheet wasn't meant to be batched. If it was, then they are nothing more than extremely simplistic versions of Access.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

OK, so take the case of the same task with different data, what I propose is that instead of coding the whole script you save your interactive Excel session with the first set of data, do some cleaning on it and voila you have your script that you can run later for other inputs.

That's a macro. You can record your "session" as VBA-macro. I can't see the difference between your suggestion and a macro. Of course, Perl integrated in Excel would be quite cool.