One example of the advantages of interactivity over batch mode are spreadsheets. All the data manipulating you do in a spreatsheet you can program in a scripting language like Perl, so why we use spreadsheets for them? My answer is that spreadsheets are just more interactive - after each manipulation you immediately see the output of it, if you miss you can reverse it or adjust. It's like in shooting: aim, shoot, adjust and repeat. While with programming you need to close the program to a more or less finished form untill you can run it and see the results. Then, of course, you can again adjust the program and repeat the process, but obviously the loop is much longer than in the case of spreadsheets.
Yet there is one advantage of the programming way of solving the data manipulation problem. Once you program it you can run it multiple times with a minimal work overhead. What can we do to have both the interactivity of manual manipulation and repeatibility of programming? All is needed is that the manual manipulation is saved as a script (program) that can be later executed or edited just like any other program (since the beginning created in an text editor). In fact many of us did that for a long time with shells where the history of commands is saved in a file in syntax ready for execution by the same shell. Onother great example of this modus operandi is HTTP::Recorder which lets you record your work sessions with a browser as a WWW::Mechanize session. Read the article at perl.com at Web Testing with HTTP::Recorder by Linda Julien if you want a good intro to it.
I believe what I've just described amounts to a whole paradigm shift in distinct programming method, and we shell see more and more systems like the mentioned HTTP::Recorder.
Update: I reposted this thought in my wiki at: SavedMacro.
In reply to Spreadsheets, HTTP::Recorder and interactivity by zby
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |