Why is Excel VBA called "Macros"?

**Whizbang** · 09-06-2011, 11:38 AM

So, this has always bugged me. In the Access world, there is a difference between Macros and VBA. Macros, in Access, are a series of pre-defined functions or commands. They can do many things, and you can string them together to get automation of tedious tasks. You can convert a macro to VBA (but not the other way around). Maybe the Macro is even stored in the background of the file as VBA (although you cannot see it in the VBE until it has been converted, so I do not think this is the case).

So, anyway, I can kind of see how people who don’t know much about Access macros or VBA might think the terms are interchangeable. But why is it called a “Macro” in Excel? This isn’t just ignorant people using the wrong term. Microsoft has labeled the tool “Macros”. Now, granted that the only thing that comes up in the “Macros” is procedures in Modules, but it is still VBA.

Using the Recorder will yield you a “macro”, true, but it will have limited functionality and zero customizability without learning VBA. The Access Macros at least have a form-based “wizard” that will give you a list of possible actions to take, and then give you the parameters for those actions. Recording a “macro” in Excel will not give you any of that. To modify an existing “macro” you need to learn some VBA. So why not just call it VBA, or “Procedures”?

It seems to me that if they were to use the same word, it should at least be very similar between the two Office applications.

Is there something I am missing? Is there a valid reason to use the same term? Or is only so that developers can say “It uses macros” and then users will hear “It uses magic”?

**Domski** · 09-06-2011, 11:54 AM

Hi,

I think of a Macro as a generic term for an automated sequence created either by recording keystrokes and mouse clicks/movement or by telling the software to execute specific tasks in sequence without the user having to have any real programming knowledge. Excel records the macros that the user records in VBA but that's just it's way of doing it, as you say in Access they are different.

Dom

**Andrew-R** · 09-06-2011, 11:55 AM

Macro is just a generic term for a set of instructions, which is all VB code is, so there's nothing really wrong with calling it a macro-language.

I learned Excel macros in Excel v4.0, when macros were sets of instructions written into cells and, believe me, we're well off to be away from those bad old days

**ChemistB** · 09-06-2011, 12:04 PM

As per Webopedia
A symbol, name, or key that represents a list of commands, actions, or keystrokes. Many programs allow you to create macros so that you can enter a single character or word to perform a whole series of actions. In a way, macros are like simple programs or batch files. Some applications support sophisticated macros that even allow you to use variables and flow control structures such as loops.

By this definition, everything from Shortcuts to VBA programming would be considered a "Macro" if it represents a list of commands, actions or keystrokes. I think with Excel, it dates back to when there was a specific MACRO language (Excel 4?), later they developed the more versitile VBA for use with macros (and beyond).

**Andrew-R** · 09-06-2011, 12:19 PM

The idea of spreadsheet macros certainly pre-dates Excel - Lotus 1-2-3 had its own macro language back in the early 80s and, as far as I know, Excel used similar macro commands right from the start.

I started learning macros because I'd been given a week to spend comparing two huge spreadsheets and I figured it would be more interesting to spend the week learning macro programming and getting that to do the job for me. Given that this was the early 90s I didn't have a resource like this forum to help me (I don't think I even had external e-mail then), so I taught myself from the reference manuals that used to come with Office products in the old days.

Because I was pressed for time I did sort of skim the manuals and tried to work mainly from their example code, rather than read all of the wordy bits inbetween. Now, bear in mind that macros were written with one command per cell, so all of the examples were basically screen shots of a couple of columns from a sheet.

When the code needed to introduce and initialise a new variable the screen shot would basically show a numeric value (say) in column A, and then the variable name in column B.

I tried replicating this and it didn't work. Even example code I copied letter for letter from the manuals didn't work. I tore my hair out, screamed at the computer, found a quiet corner and had a good cry, etc., but I just couldn't get anything using variables to work - as you can imagine this cramps your programming style a little.

Eventually I gritted my teeth and sat down and read the manual properly. Where they were initialising a variable they were using a named range (which I'd never used before) the variable name in column B was just a comment to help those reading the manuals.

I can't remember anything else about old-fashioned Excel macros, but I still vividly recall the days of frustration spent trying to get those damn variables to work

**snb** · 09-06-2011, 12:22 PM

When I use Ctrl-F11, I get a new 'macro-sheet' in Excel.

**Bob Phillips** · 09-06-2011, 12:38 PM

Macros is a rubbish term and should be avoided by anyone that aspirate to think of themselves as developing code. I use the term procedures, for that is what sub(routine)s and functions are.

**Domski** · 09-06-2011, 12:42 PM

I aspirate quite a lot when writing code, I also swear and hit the keyboard

Dom

**Mordred** · 09-06-2011, 12:50 PM

Originally Posted by Domski

I aspirate quite a lot when writing code, I also swear and hit the keyboard

Dom

And here I thought that was just me that did that! Nothing like code raging

**Whizbang** · 09-06-2011, 01:36 PM

Ah. I see. It is a carry-over term from earlier versions. I don't know why I didn't Google "What is a macro?". Loads of information.

Dictionary.com says is is " an instruction that represents a sequence of instructions in abbreviated form. " - http://dictionary.reference.com/browse/macro

That is a very broad term. So much could be put under that umbrella. Hmm.. I guess it is a fairly apt term at that. I am glad I asked, although I am a little embarrased I didn't spend more time searching before I did.

**Colin Legg** · 09-06-2011, 05:06 PM

Calling Excel VBA code "Macros" is a pet hate of mine.

When I've been looking for developer work in the past, if the job spec said something like "must be an expert at writing Excel macros", it'd go straight in the bin.

**Whizbang** · 09-06-2011, 05:27 PM

I have been trying to classify the usage of the word "Macros" and redefine my opinion on the term after having actually read the definition. I have been trying to come up with an analogy that puts the term into, what I beleive, is an accurate description.

Would people aggree that to call a VBA solution in Excel a "Macro" is the same as calling a car an automobile? Macro is to VBA as Automobile is to Car.

Automobile/Macro. They both, technically, describe the object. But both are a little, in my opinion, outdated and give the wrong impression. Automobile could be used to describe just about anything on the road, and Macro could be used to describe any set of instructions. Whereas "car" implies a more specialized product, and VBA describes a complex programming language.

Obviously the analagy isn't perfect, but it seems to me that "Macro" gives the wrong impression. And now that I am doing more Access development, I find it frustrating when a user says "So is that the macros doing that?", and I say "Uh. No. The macro opens the Form and filters it, but the VBA procedure gets your username and enables/disables features based on your permissions." or whatever.

Like I said in my first post, Macros and Magic seem interchangeable as far as the average user is concerned, where you just wave your wand over the Macro Recorder and things happen. Whereas VBA implies, I would think, a little more time and effort on behalf of the developer.

**MarvinP** · 09-06-2011, 11:38 PM

Hey Wizbang,

I've been digging in Access 2010 and noticed they change the term Subroutine to Procedure for the VBA.
I thought that was just a more modern term.

Then I thought I read that in Access the Macros would run on the Web. The idea is that if you build your app using Macros it was a snap to move to the web and SharePoint. If you have VBA the conversion to Sharepoint was not guaranteed.

I also read http://www.databasedev.co.uk/macros-in-access.html another answer.

**protonLeah** · 09-07-2011, 12:32 AM

A macro is a small limited ability program that runs within a host application. Macros are not stand-alone programs; they cannot be run by the operating system. VBA is a macro language and programming environment that runs within a stand-alone application such as Excel which is run by the operating system (VB and VBA are not the same thing: VB produces stand alone .exe files. VBA does not. VB is a language and stand-alone programming environment run by the OS).

Macros got their name from the idea that they were like a giant, mega- or macro- key on the keyboard that, instead of outputting just one letter, would output a whole stream of data such as the beginning of a business letter, that's always the same, etc.

Therefore, gents, words such as code, procedure, subroutine miss the point entirely.

**romperstomper** · 09-07-2011, 03:21 AM

VBA is a language, not an environment. Ditto VB. Up until XL2003, there was a developer version of Office that did allow you to compile executables from your VBA projects, so that is also not technically accurate.

**Bob Phillips** · 09-07-2011, 03:36 AM

Originally Posted by protonLeah

Therefore, gents, words such as code, procedure, subroutine miss the point entirely.

Miss the point how? The vast majority of the code and procedures that I write are not limited ability programs. Procedures are not stand-alone, code is not stand-alone. You make a point and then draw a conclusion that is totally unrelated as far as I can see.

**Andrew-R** · 09-07-2011, 03:49 AM

I'm quite amazed that there seem to be strong feelings on this subject - I'd always considered, in the the context of Excel, the terms 'macro' and 'VBA' to be completely interchangeable.

**snb** · 09-07-2011, 03:51 AM

Look into any dictionary: labels ('words') can't be 'wrong' (check your assumptions if you think they can).
'Missing the point' seems to me to be a anthropomorphism.
The way people use words can be confusing, unclear, creative etc. They might be the 'culprit'.
Long live the homonyms and the poets !

**Whizbang** · 09-07-2011, 08:58 AM

Originally Posted by protonLeah

A macro is a small limited ability program that runs within a host application. Macros are not stand-alone programs; they cannot be run by the operating system. VBA is a macro language and programming environment that runs within a stand-alone application such as Excel which is run by the operating system (VB and VBA are not the same thing: VB produces stand alone .exe files. VBA does not. VB is a language and stand-alone programming environment run by the OS).

Macros got their name from the idea that they were like a giant, mega- or macro- key on the keyboard that, instead of outputting just one letter, would output a whole stream of data such as the beginning of a business letter, that's always the same, etc.

Put like this, I can understand how the term Macro has continued to be used. It still is technically appropriate, and why change the term and cause confusion for those who have used Excel through many versions? But I do think that VBA has grown past the definition of "... a small limited ability program that runs within a host application." What you can do within Excel is awesome, then you add in API's, and the ability certainly is not "limited". Yes, it still runs within the host application. That is unavoidable (although in Access 2010 you can create a compiled executable project that uses Runtime, so how is that different than creating an application entirely in VB?).

Up until I started this thread, I thought the difference was that a Macro was a sort of psuedo-code that allowed non-programmers the ability to automate their application somewhat. And VBA was a programming language, although obviously not on par with the .Net languages. I realize now, however, that the line is not so clear between the two terms, and in the case of Excel, that line does not appear to be there at all in the minds of Microsoft.

Anyway, I am learning loads about the history of Macros and Excel. Keep the debate lively.

***Edit***

Originally Posted by MarvinP

Then I thought I read that in Access the Macros would run on the Web. The idea is that if you build your app using Macros it was a snap to move to the web and SharePoint. If you have VBA the conversion to Sharepoint was not guaranteed.

I also read http://www.databasedev.co.uk/macros-in-access.html another answer.

Hmmm. That is intersting. Thanks for sharing.

**Bob Phillips** · 09-07-2011, 09:39 AM

Originally Posted by Whizbang

... VBA was a programming language, although obviously not on par with the .Net languages...

Of course VBA is on a par with the .Net languages. You can use VB in .Net, which is very similar to VB and VBA. Where .Net 'scores' in that is has a much richer set of libraries and classes that a developer can call upon, and so is more suited to It organisations developing enterprise applications in the modern world. But it still doesn't hold a candle to VBA for building real-world, business-centric solutions.

**davegugg** · 09-07-2011, 10:24 AM

I'd have to disagree with VBA being on par with .Net languages. VBA is not OOP, and as such has many disadvantages. VBA is great to use for simple projects in Excel and Access, but any OOP language-based solution is going to be much more robust, easier to change and maintain, and should be more user-friendly.

Just look at using a List in .Net vs having to use an array in VBA. Lists can hold any types, even class types, don't have to be "manually" resized, and you can insert items into the middle of a list without having to manually shift all items after that spot down one. Using the VBA IDE after using Visual Studio 10 with .Net 4.0 is like doing polynomial math without a calculator. Don't forget, no more need for Hungarian Notation!

**romperstomper** · 09-07-2011, 10:32 AM

Since you can create objects in VBA (though I grant you it's not full OOP) that's a pretty specious argument. The user-friendly part I don't see at all - how does that relate? Given that most businesses use Office, how is it not easier to use VBA, which is natively in Office, than trying to apply a .Net solution (if the IT department will even let you)?
Also, I would suggest a Collection is closer to a List than an array is, and VBA has those.

The IDE may be much better for .Net but that's not the language.

**Bob Phillips** · 09-07-2011, 10:37 AM

I wouldn't necessarily argue that VB.Net is not better than VBA (and C# is better again), you would darn well hope so with the lessons that have been (should have been, this is MS after all) learnt, and the money spent on it. But the things you mention are mainly around the edges. Being on a par is not saying it is a good as in every way. Critiquing VBA's ability regarding size of projects is critiquing the environment is exists within, not the language itself, so is irrelevant. And this statement ... any OOP language-based solution is going to be much more robust, easier to change and maintain, and should be more user-friendly ... is just ridiculous. Good code is usually down to good programmers, a poor programmer can create rubbish in the best of languages, a great programmer can create genius in the worst (how else could C++ have survived?).

**davegugg** · 09-07-2011, 11:04 AM

I certainly agree that good code comes down to good programmers. However, think about what happens when a project's requirements change. Let's say you have one variable type to change, and that variable is used throughout your entire project. In VBA, you will literally have to go through your entire code, line by line, to make any necessary changes. In .Net, you change the output of one object, and all other objects's code can stay the same. One change over possibly hundred of changes = easier to change and maintain.
Error handling is much better in .Net. Instead of On Error Goto, you get Try...Catch...Finally...End Try. Instead of setting up a bunch of error options based on generic error numbers at the end of each sub, you can set specific handlers in the code. I'd say that makes it more robust, though I'm sure you could set up a similar system in VBA, it'd just take a ton more lines of code and you'd never have the error numbers to give a correct message for all the possible errors.
For user-friendly, you .Net applications have access to more events that can make forms easier for the end users.

Creating objects isn't the only thing to OOP. In VBA, you lose polymorphism and class inheritance, which makes it SO much more work to program. VBA not being OOP is NOT a specious argument.

**romperstomper** · 09-07-2011, 11:22 AM

Still not seeing the connection between OOP and user-friendly to be honest.

**Bob Phillips** · 09-07-2011, 11:24 AM

Originally Posted by romperstomper

Still not seeing the connection between OOP and user-friendly to be honest.

You cannot see what doesn't exist.

**davegugg** · 09-07-2011, 11:27 AM

Well, did I at least convince you with my other arguments?

**Bob Phillips** · 09-07-2011, 11:30 AM

Originally Posted by davegugg

I certainly agree that good code comes down to good programmers. However, think about what happens when a project's requirements change. Let's say you have one variable type to change, and that variable is used throughout your entire project. In VBA, you will literally have to go through your entire code, line by line, to make any necessary changes. In .Net, you change the output of one object, and all other objects's code can stay the same. One change over possibly hundred of changes = easier to change and maintain.

Search and Replace!

Originally Posted by davegugg

Error handling is much better in .Net. Instead of On Error Goto, you get Try...Catch...Finally...End Try. Instead of setting up a bunch of error options based on generic error numbers at the end of each sub, you can set specific handlers in the code. I'd say that makes it more robust, though I'm sure you could set up a similar system in VBA, it'd just take a ton more lines of code and you'd never have the error numbers to give a correct message for all the possible errors.

You can and we do.

Originally Posted by davegugg

For user-friendly, you .Net applications have access to more events that can make forms easier for the end users.

What does something a user never sees have to do with user-friendliness?

Originally Posted by davegugg

Creating objects isn't the only thing to OOP. In VBA, you lose polymorphism and class inheritance, which makes it SO much more work to program. VBA not being OOP is NOT a specious argument.

Yeah, we have already acknowledged is has more than VBA, but VBA is on a par with VB.Net. Agreed, VBA not being OOP is not specious, it is stating the obvious, and says nothing. Guess what, a snake is not a lion.

**romperstomper** · 09-07-2011, 11:35 AM

Originally Posted by Bob Phillips

You cannot see what doesn't exist.

Depends how tired/drunk you are.

**Whizbang** · 09-07-2011, 11:39 AM

In the debate whether VBA is "on par" with the .Net languages, I have no opinion, since I only have experience in VBA. But in the debate over whether VBA should still be termed a "macro", or if it has grown past that term, things like "Try...Catch...Finally...End Try" and variable type changes don't address the fact that VBA is a complete programming language and not a simple list of instructions limited to the functionality of the application.

According to the link Marvin P gave earlier in this thread, in Access "macros incorporate generalized database functions using existing Microsoft Access capabilities". I translate that into Excel to mean a macro is a procedure that deals only with the Excel environment. As soon as you start working in other Office applications, or using API's, then it ceases to be a macro, IMO.

**romperstomper** · 09-07-2011, 11:41 AM

Like Bob, I agree with what you say largely, but I don't think it carries as much weight as you think it does, at least not in my environment. Hence, to me it is a specious argument (lacks real merit); however, I would freely admit that it is a matter of perspective.

(Having never really used OOP languages, I don't miss anything about them)

**davegugg** · 09-07-2011, 11:43 AM

I guess we'll have to agree to disagree, but I do wonder how much programming you've done in .Net? 4.0?
If you have to change an integer type variable to a string type variable, a find and replace isn't going to do you much good.
Another example of user-friendly would be multi-threading, which will allow the user to work while the program is also working; no more frozen app screens while the program executes.

**Bob Phillips** · 09-07-2011, 11:49 AM

Originally Posted by Whizbang

In the debate whether VBA is "on par" with the .Net languages, I have no opinion, since I only have experience in VBA. But in the debate over whether VBA should still be termed a "macro", or if it has grown past that term, things like "Try...Catch...Finally...End Try" and variable type changes don't address the fact that VBA is a complete programming language and not a simple list of instructions limited to the functionality of the application.

According to the link Marvin P gave earlier in this thread, in Access "macros incorporate generalized database functions using existing Microsoft Access capabilities". I translate that into Excel to mean a macro is a procedure that deals only with the Excel environment. As soon as you start working in other Office applications, or using API's, then it ceases to be a macro, IMO.

Surely, the question is now redundant. Macros is old terminology which has survived the passing of time. Access, at least prior to 2010, had a special construct that they called macros, everywhere else, macros, code, VBA, it is just a matter of choice.

The important thing to understand is that VBA, and any recorded code is still VBA, can only exist within a hosted environment, such as Excel, Word, Access, Visio, etc. You cannot write VBA outside of that environment, well you can write it, but you have to plug it back in to use it. This hosted situation is probably the reason why it has become so well used, so popular, it is very easy to create good applications using the host's object model, quickly and easily. Because of this ease of use, real users, business users, picked up on it and found real solutions to their problems. Excel is the first RAD tool as far as I am concerned, and that is because of VBA, its access to the Excel object model, and the lack of lock-down that the MS developers didn't apply.

**Bob Phillips** · 09-07-2011, 12:11 PM

Originally Posted by davegugg

I guess we'll have to agree to disagree, but I do wonder how much programming you've done in .Net? 4.0?

See, there you go again, arguing for a point that is not contested. I agree, developing code in .Net is a far richer experience than in the VBIDE, writing code can be a joy - I love it too. But that has little to do with the languages, much more to do with the tools provided. And I also know that .Net is still a pig to deploy for office based solutions, and is far from performant.

If MS had invested half the money in VBA as they have in .Net, VBA would be stonking and no-one would even talk about .Net. But they haven't, and they won't. Notice that despite repeated attempts, and an over-riding wish, by MS to kill-off VBA, it is still here, and it is still thriving. I am not arguing for that investment, although a little bit of upgrading would be nice. I think something new was required, but I personally doubt that .Net is the best they could have done. But again, that is not what this thread is about.

**davegugg** · 09-07-2011, 12:44 PM

.Net 4.0 is not an IDE, it is a programming language framework. It is a framework behind Visual Basic (not VBA), C++, and C#. The IDE for .Net is generally Visual Studio. I was asking if you had programmed using Visual Basic, C++, or C#, not if you had used Visual Studio. If you haven't built an application using an OOP language like Visual Basic or C# (or Java, etc.), I don't see how you can make a comparison.

I do agree that it is interesting that VBA is still around in the new versions of Office. As far as I know, they've made only very minor changes for the new versions of office.

**Andrew-R** · 09-07-2011, 01:25 PM

Originally Posted by Bob Phillips

Excel is the first RAD tool as far as I am concerned, and that is because of VBA, its access to the Excel object model, and the lack of lock-down that the MS developers didn't apply.

Add to that VBA is now pretty much the only development environment you can be pretty sure of finding on any PC in any office. I know that I do a lot of quick 'n' dirty code for one-off jobs in VBA that I might previously have done in something like QBasic (please don't spit on me).

Anyway, I think the important thing is that whether we call the coding behind Excel VBA or a macro it achieves its primary purpose - which is to allow us to look extremely clever on this forum, build up rep points and, therefore, slightly increase our slim chances of mating. I know that's why I'm here.

**Domski** · 09-08-2011, 05:54 AM

I made my name rise up the screen in BBC Basic once. That's about the limit of my programming experience outside of VBA.

Dom

**Andrew-R** · 09-08-2011, 06:09 AM

Originally Posted by Domski

I made my name rise up the screen in BBC Basic once.

Skillful coding, or dodgy vertical hold?

**Domski** · 09-08-2011, 06:14 AM

LOL I do remember some of the old tv's that had been donated by parents for the 'computer room' were pretty knackered and rising text wasn't always the result of programming.

Dom

**Marcol** · 09-08-2011, 06:48 AM

What's the difference between a macro and a marco? ....

I often see this posted

I need marco to do this ......

**Domski** · 09-08-2011, 06:58 AM

Originally Posted by Marcol

What's the difference between a macro and a marco? ....

I often see this posted

http://www.excelforum.com/the-water-...his-marco.html

Dom

**NBVC** · 09-08-2011, 08:33 AM

Originally Posted by Domski

I made my name rise up the screen in BBC Basic once. That's about the limit of my programming experience outside of VBA.

Dom

When I was in Italy in the early 80's I had a sinclair ZX-Spectrum.. remember programming on that! Who knows what I was doing.. and recording the program on cassette tape recorder! yikes! I don't have the computer anymore, but I think I still have the cassettes... maybe for some nostalgia, I should play the cassette to hear all those beeps.. music to my ears... not!

I also did some Fortran77 programming in University and PASCAL and BASIC in earlier years....

**Domski** · 09-08-2011, 08:43 AM

I had a Commodore 64 which I did manage to set up a very basic database on, by which I mean wrote a few records to cassette and read them off again. Like most kids though I was more interested in playing Decathlon/Chuckie Egg/Manic Miner/Pitsop 2/Leaderboard etc. Bit of a shame really as I would probably be earning a lot more than I am now if I'd persevered.

Dom

**Whizbang** · 09-08-2011, 09:58 AM

GWBasic and QBasic were my very first experiences with programming. I took a class in Jr. High. They had 8086's, with only two floppy drives (no hard drive). I remember the hours spent trying to recreate Donkey Kong. I only ever got the layout done, plus some basic movement, but I had a blast. I convinced my mom to buy me an old, 3rd or 4th hand, computer (I think it was a 80286, which shows how old the school's computers were), and I programmed an alarm clock on that... That I left running all night every night, just so I could hear the beep in the morning.

Hmmm... Maybe I will find a QBasic editor around somewhere and see what fun I can have.

**Andrew-R** · 09-08-2011, 10:38 AM

I got one of my early jobs based on my "skill" in QBASIC. A company (who shall remain nameless) had got an "Independent software company" (read one bloke working out of his bedroom) to write a program for them. The person they'd contracted handed the entire project over to his 14 year old son, who'd done the lot in BASIC and they were looking for someone to make some changes to the program.

For my interview the bloke running the interview launched QBasic and typed out the code

Please Login or Register  to view this content.

He then ran it to show me what it did (dur!) and asked if I could edit it to show my name instead. That was the entire interview.

It turned out that the actual program was 6,000 lines of BASIC code on a crappy computer (and this is when x286s were considered cutting edge). The version of BASIC it used only supported single character variable names (i.e. A-Z were the only variables you could use), it only supported printing to a 6 inch wide till roll and the entire documentation was two REM statements at the start of the code that gave the name of the 'company' who wrote the software and who it was for.

When I asked what they wanted me to do my boss told me, "Well, can you make it run faster?"

I spent 6 weeks on it - 5 of which were drawing up flowcharts and variable lists and 1 week of actually doing something with the code. The machine was so dodgy that every night I had to backup my work and every morning I had to reformat the hard drive and restore from backup, or else the machine wouldn't run for the whole day. Every day I begged them to let me re-write the code from scratch on the brand new 286 that was sitting, unused, on the next desk along from me, but my boss didn't feel I had enough experience to tackle that.

After 6 weeks they offered me a full-time job, I politely declined, wished them luck and never went back.

**Leith Ross** · 09-11-2011, 12:07 AM

Just a brief note on the term macro. Back before the days of high level languages like COBOL, FORTRAN, and BASIC. the only code that existed was micro code. The very basic instructions that the computer could execute.

When I joined the Navy in 1978, I was familiar with the new microprocessor technology (that would include the Z80 at the time). After I was sent to Mare Island for training, I was shocked that the Navy was still using 3rd generation computers. These had no microprocessors. These had "timing chains". Everything was hard wired, no flexible micro instruction codes.

Micro code revolutionized computers by freeing the machine from itself. The ability to create new routines based on smaller building blocks of micro instructions became known as macros. The term has been borrowed over the years and applied to situations were groups of smaller components function as an autonomous unit.

Interestingly, the trend is now reversing itself from complex languages back to "idiot codes" or reduced instruction sets. While it is more difficult for humans to code in RISC, the same limitation does hold for computers. The era of computers designing computers has been around awhile. Now, computers are be able to program optimal instruction sets for the hardware they create.

Why is Excel VBA called "Macros"?

LinkBack

Thread Tools

Display

Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Re: Why is Excel VBA called "Macros"?

Thread Information

Users Browsing this Thread

Bookmarks

Bookmarks

Posting Permissions