Some applications let you save a sequence of your actions into some textual representation that later can be replayed. Examples of them: Excel with saving into Visual Basic scripts, Emacs with saving into emacs lisp, unix shells with editable history files. This page is devoted to analysis of many advantages of this functionality. == Saved Macros for Learning of Programming Advantages for learners of the art of programming: * the user does not need to learn programming before it can use it, she can use it for automation of some mundane tasks with zero knowlege of the programming language used * it induces natural curiosity in the user who would like to peek into the saved programs * the user can herself generate the most relevant examples from his own work with the application * the language can be learned on an 'as needed' basis with very fine grained steps (the first point is really only a conclusion of this) == Saved Macros as a Method of Programming 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 better InterActivity of the spreadsheets - 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? The answer is SavedMacro. You can grow your program by just saving your interactive sessions with the system/application. === Disadvantages There is one quite severe disadvantage of this modus operandi - saving the seqence of operations does not save the whole context of those operations (the state of the application). The readers of the saved code will not see what really was the reason for the saved commands and will have much difficulty of understanding them, so the communication capabillities of this method are much worse than the traditional approach of handwriting the whole code (from [http://www.perlmonks.org/index.pl?node_id=371153 Re^5: Spreadsheets, HTTP::Recorder and interactivity by tilly]). It seems to be suited only for creating relatively small programs. Of course when we allready know that we can start to think about ways of relinguishing this constraint. == Saved Macros and the Future of Programming (some speculations) People use computers for more and more daily tasks and to use computer with the maximum power one needs to learn programming. We can expect that more and more people will learn how to program and SavedMacro seems to be the easiest way to do it: even if it remains constrained to creating only the most basic programs, that is what most of the users will ever need. And here is what I predict - the sheer number of its practitioners will eventually make it more important than the traditional ways of creating software. I guess this scenario is exactly what http://hbswk.hbs.edu/item.jhtml?id=4300&t=innovation&nl=y referes to as New Market disruptive innovation. The prediction above calls for designing programming languages specificially for 'Recorded Macro' scripting and particulary for putting some effort for relinquishing the communication inefficiency of them (as described two paragraphs above). == Contra Saving a sequence of user action can generate only linear paths of execution. Loops, branches and recursion would have to be added manually anyway. ---- Interesting point about the insufficient context for larger programs. Why should this be? (And what can be done about it?) Is it actually a failing with how we currently capture information about wider context. For example, I waste more time with, and give up more projects due to, the problems I have with administrating the system (installing the right libraries, setting pathnames for libraries in environment variables, errors in XML config files) than with actual problems in my program. I always wish this stuff was under the control of my program itself. So if there was a way to capture / copy / package OS-wide context it would probably boost productivity more than anything else. And would allow macro-recording to scale too. Also, I suppose the saved macro needs to be edited. So there has to be an EditableRepresentation. I wonder what that's like? Does it revert to being a normal programming language? Or could it look like something else? -- PhilJones The answer to the question about EditableRepresentation is in the first paragraph where I list examples of applications where sequences of user actions can be saved as macros - every is based on some existing programming language. But eventually the 'simplified' facet should lead to something like Templating Languages used currently for generating HTML and other documents, with simplified control structures and with a convenient mechanisms for changing constants into variables. -- ZbigniewLukasiak Yes, but it might not need to be text. Perhaps it could look like HistoryFlow (http://www.nooranch.com/synaesmedia/wiki/wiki.cgi?HistoryFlow) with the ability to edit it like video. For a long time, I've dreamed of being able to "drive" through the execution of one of my programs with a game-controller. I'd like to be able to accelerate through familiar working parts, then slow down (adding verbose diagnostics) for parts I'm unsure of, and then go into reverse when I hit a bug, to trace back to how it happened. The same kind of interface might be even more appropriate to sequence of recorded actions made by someone who can't ''read'' a language-like script. -- PhilJones This is a very interesting thought, but I think you misunderstood the argument. The problem is that the readers of the saved code don't see the context of it and the context is what really drives the saved commands. That means that readers of the saved code will have much difficulty understanding it. -- ZbigniewLukasiak ---- == Related * [http://www.perlmonks.org/index.pl?node_id=371051 Spreadsheets, HTTP::Recorder and interactivity] my post at Perl Monks and discussion. * [http://www.dreamsongs.com/Feyerabend/Feyerabend.html] Nice quotes about programming languages. * http://www.martinfowler.com/articles/languageWorkbench.html * This conversation has gone in a shared macro direction : http://discuss.joelonsoftware.com/default.asp?best04.8.21079.4 -- PhilJones * [http://www.apple.com/macosx/features/automator/ Apple automator]