Edit Compile Link Run

...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 OperatingSystems 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 "FatClients" (each of which can host their own development environment).