...LatherRinseRepeat.

The steps to produce a working program in many traditional languages; though with sophisticated IntegratedDevelopmentEnvironments, modern OperatingSystems and other tools, much of this can be automated.  The four steps are:

	Edit:	type in your program using an editor of some sort, or modify existing code.
	Compile:	Cause the file(s) you have been just edited to be translated to some other format, usually object code for the underlying machine.  (A secondary step in many systems is "assemble"; it's not uncommon for a compiler to emit AssemblyLanguage which is then assembled to ObjectCode; however this step usually is transparent).  Assuming no errors, you then....
	Link:	Using a program called a "linker", combine the different object files that make up your program, along with any libraries you want to use (and the language's runtime system) into a final executable.
	Run:	Invoke the executable.  (Actually this is also two steps--loading it into memory, and executing it when it's there).  When it crashes or otherwise doesn't work, go back to step 1.  (Better yet, run a debugger--another step I didn't mention).

Obviously, the above is a gross oversimplification.  Modern OperatingSystem''''''s can defer much of the linking to the load phase; and almost every environment known to man can combine the compile and link phases, whether it's an IntegratedDevelopmentEnvironment or a Makefile.  However, the steps still occur, in this order.

Some folks rather dislike EditCompileLinkRun environments/languages; thinking them outdated.  Indeed, Makefile maintenance is a major chore; and building a large sophisticated product with an IDE can be an equally scary experience.  In most such languages, large programs are broken up into many different files; keeping track of all of them is a pain (and in languages like CeeCeePlusPlus, handling the build dependencies is also a pain--maintaining a large project ''without'' a sophisticated IDE or a Makefile is almost impossible).  And, even with a good IDE, the "seams" are rather obvious (compared to an ImageBasedLanguage).

However, EditCompileLinkRun has its advantages:

* It's highly portable.  There is a clear deliniation between what is "source" and what is "derived"; and the entire set of information needed to build a system can be found in a set of text files. 

* Integrates very well with ConfigurationManagement systems.

* Integrates very well with multiple developers.

* Supports heterogenous projects (those written in multiple languages) well.

* Deployment of object files is trivial (main issue is finding appropriate files in a multiple-file system).

* Aren't dependent on one particular environment: if you don't like VisualAgeForJava, you can pack up your stuff and go use EclipseIde or make or whatever else you like.

* Works well across a network; especially across a network consisting of many "FatClient''''''s" (each of which can host their own development environment).