Macros are like "programs".
I think the primary difference between a macro  and a program is
that a program is normally written in a sofware language that
is then "compiled" which is a process that turns english-language
commands into machine-language commands.
That's why you can't open the msword.exe file and read all of the
commands that make Word do what it does.
A macro, on the other hand, stays english-language, and
executes in a line-by-line format.

In the case of excel, "macro" is a brought term that includes
the "Sub" (subroutines) and "function"(s) that you write in
the VBA editor.

The official definition is:



A macro  in computer  science
<http://en.wikipedia.org/wiki/Computer_science> is a rule or pattern
<http://en.wikipedia.org/wiki/Pattern> that specifies how a certain
input sequence (often a sequence of characters
<http://en.wikipedia.org/wiki/Character_%28computing%29> ) should be
mapped to an output sequence (also often a sequence of characters)
according to a defined procedure. The mapping process which instantiates
a macro into a specific output sequence is known as macro expansion.



In short, a macro is a sequence of instructions carried out by the
computer. Within Excel a macro is more of a recorded sequence of
actions. You can record a macro from the front end and the computer
creates the sequence of code for you. This however is quite limited in
comparison to what a fully written program is capable of consisting, but
is sufficient for basic front end Excel tasks, especially those that are
done repeatedly within the environment.



A basic example is you can record a macro for every time you highlight
and bold the first row of any Excel sheet where you use headers, once
recorded you only need execute the macro to repeat the process.

My two penneth....

IMHO I think for VB/A, "macro" is a misnomer. What you actually create are
subroutines and functions both of which could possibly refered to as
"procedures". It could be that "Macro" is a hang over from earlier Excel
macro sheets.

Yes, quite correct. I think 95 was the first version to have VBA. Prior to
that, a macro  was stored as a collection of keystrokes and only had limited
functionality.

Microsoft have perpetuated this confusion by still referring to them as
"macros" from the worksheet side of Excel.

Using the "macro recorder" creates a single VBA subroutine that has the
Visual Basic equivalent of everything you do while the recorder is
recording. It's very useful for beginners, but also very useful for
experienced people, because it stops you needing to do a search to refresh
your memory on the VBA needed to do something obscure to the worksheet.

Also... On some of the early mainframes I worked on, some pieces of code
were refered to "Macros", particularly for editor routines. It's not beyond
the realms of possibility that the name was coined by someone who worked on
those mainframes as well...

Forgive my interruption, but I was thinking that a 'non-computer'
person wouldn't know what you all have been saying. I was thinking
more like, from the user's standpoint that a "macro" was very much
like a remote control, or an automatic control that we use for
Excel, Access, Word, etc. . .. that is . . . it's simply a way to
control what the program does on the computer, and the advantage is
that if one learns how it does that, then one can "make it" do the
things that one wants it to do.

So, if I wanted it to type "hello" . . . I could make it do
that "automatically" with a "macro". And, if I wanted it to ask the
person to respond, I could make it pop up a form to request them to
respond, as well.

Or literally millions of other things, if I wanted it to do any
of those things.

Here's a vote to a great group of very brilliant people, too.