A general process for developing a program is Planning > Design > Implementation > Testing (verification) > Release.

1. Plan what you want to achieve, how to achieve, ... - scope, time, cost, ...
2. Design the system - what modules, interfaces and interactions between modules, ...
3. Implement modules, test modules, fix bugs, ... - very much an often repeated loop
4. Test - system tests to verify everything works as expected
5. Release - to customer or for you own use

The above is a very brief overview and introduction and doesn't show any of all related processes and documents that are usually also created. Like project plans, system- and module design documents, implementation descriptions, test plans, documentation for installation, end-user usage (User's Guide), etc.

Implement and Test

For this introduction to programming material, we focus on implementation and test. That is, create executable programs that you can test.

1. Write (edit) your program code - source code.
2. To execute - run
   1. Compiled programming languages (C, C++, C#, Java, ...): Compile, Link, Run
            
      • Your source code is converted from text to executable code one single time.
      • Executes much faster - why big applications (like MS Word, web browsers, your computer's operating system etc are compiled programs.
      • More work to get from source to working executable.
      • en.wikipedia.org/wiki/Compiled_language
      • en.wikipedia.org/wiki/Compiler
      • (The Executor in the illustration above would be your operating system - MS Windows, Apple Mac OS X, etc. Compiled programs can only run in the environment for which is was compiled for.)
   2. Interpreted programming languages (JavaScript, script languages like bash, sh, CMD-prompt in MS Windows, ...): Run
           
   • Your source code is read and executed by an interpreter each time you run the code.
   • Somewhat slower execution than compiled languages.
   • Source code can most often be read, visible by user - something you may not want to happen...
   • Less work to get something done.
   • en.wikipedia.org/wiki/Interpreted_language
     
     (Graphics above from openbookproject.net/thinkCSpy/ch01.html)
      
   • A possible intermediate variant is Transpiled languages. This is the form when a language on some abstraction level is converted to a similar abstraction level, from one languge to another. Wikipedia on source-to-source. Google transpiler.
     • More common examples of programming languages include converting CoffeeScript, TypeScript, and ECMAScript 6, to JavaScript.
     • Other well-known examples are converting from more advanced style sheet languages like LESS and Saas to CSS, something web browsers actually can understand, interpret.
        
   • Other formal languages (formal but not programming languages) like HTML (Hypertext Markup Language) or SQL (Structured Query Language) are also interpreted at runtime or used as input to tools to create binary data ('compilation').
      

     This course and its web pages is a great example of interpreted languages: Web pages are created in HTML (text, content) and CSS (Cascading Style Sheets; formatting) and is interpreted by your web browser when page is loaded. Some pages also use JavaSript to create nice syntax formatting of code examples - also interpreted and executed by your web browser when page is loaded. Pieces of the pages are also created "on the fly" on the web server (before the page is sent to your browser) using PHP - another interpreted language.

     
     
3. Test, Debug: run the program, and verify results are as you expect.

What You Need - Tools (Applications)

More on Compiled vs. Interpreted

Including a couple of reference texts - for the interested student.

From publib.boulder.ibm.com/infocenter/zos/basics/topic/com.ibm.zos.zappldev/zappldev_85.htm:

Compiled versus interpreted languages

Application programming on z/OS

During the design of an application, you might need to decide whether to use a compiled language or an interpreted language for the application source code.

Both types of languages have their strengths and weaknesses. Usually, the decision to use an interpreted language is based on time restrictions on development or for ease of future changes to the program. A trade-off is made when using an interpreted language. You trade speed of development for higher execution costs. Because each line of an interpreted program must be translated each time it is executed, there is a higher overhead. Thus, an interpreted language is generally more suited to ad hoc requests than predefined requests.

Advantages of compiled languages

Assembler, COBOL, PL/I, C/C++ are all translated by running the source code through a compiler. This results in very efficient code that can be executed any number of times. The overhead for the translation is incurred just once, when the source is compiled; thereafter, it need only be loaded and executed.

Interpreted languages, in contrast, must be parsed, interpreted, and executed each time the program is run, thereby greatly adding to the cost of running the program. For this reason, interpreted programs are usually less efficient than compiled programs.

Some programming languages, such as REXX™ and Java™, can be either interpreted or compiled.

Advantages of interpreted languages

There are reasons for using languages that are compiled and reasons for using interpreted languages. There is no simple answer as to which language is "better"—it depends on the application. Even within an application we could end up using many different languages. For example, one of the strengths of a language like CLIST is that it is easy to code, test, and change. However, it is not very efficient. The trade-off is machine resources for programmer time.

Keeping this in mind, we can see that it would make sense to use a compiled language for the intensive parts of an application (heavy resource usage), whereas interfaces (invoking the application) and less-intensive parts could be written in an interpreted language. An interpreted language might also be suited for ad hoc requests or even for prototyping an application.

One of the jobs of a designer is to weigh the strengths and weaknesses of each language and then decide which part of an application is best served by a particular language.

From tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/languages.htm:

11. How do computer languages work?

We've already discussed how programs are run. Every program ultimately has to execute as a stream of bytes that are instructions in your computer's machine language. But human beings don't deal with machine language very well; doing so has become a rare, black art even among hackers.

Almost all Unix code except a small amount of direct hardware-interface support in the kernel itself is nowadays written in a high-level language. (The ‘high-level’ in this term is a historical relic meant to distinguish these from ‘low-level’ assembler languages, which are basically thin wrappers around machine code.)

There are several different kinds of high-level languages. In order to talk about these, you'll find it useful to bear in mind that the source code of a program (the human-created, editable version) has to go through some kind of translation into machine code that the machine can actually run.

11.1. Compiled languages

The most conventional kind of language is a compiled language. Compiled languages get translated into runnable files of binary machine code by a special program called (logically enough) a compiler. Once the binary has been generated, you can run it directly without looking at the source code again. (Most software is delivered as compiled binaries made from code you don't see.)

Compiled languages tend to give excellent performance and have the most complete access to the OS, but also to be difficult to program in.

C, the language in which Unix itself is written, is by far the most important of these (with its variant C++). FORTRAN is another compiled language still used among engineers and scientists but years older and much more primitive. In the Unix world no other compiled languages are in mainstream use. Outside it, COBOL is very widely used for financial and business software.

There used to be many other compiler languages, but most of them have either gone extinct or are strictly research tools. If you are a new Unix developer using a compiled language, it is overwhelmingly likely to be C or C++.

11.2. Interpreted languages

An interpreted language depends on an interpreter program that reads the source code and translates it on the fly into computations and system calls. The source has to be re-interpreted (and the interpreter present) each time the code is executed.

Interpreted languages tend to be slower than compiled languages, and often have limited access to the underlying operating system and hardware. On the other hand, they tend to be easier to program and more forgiving of coding errors than compiled languages.

Many Unix utilities, including the shell and bc(1) and sed(1) and awk(1), are effectively small interpreted languages. BASICs are usually interpreted. So is Tcl. Historically, the most important interpretive language has been LISP (a major improvement over most of its successors). Today, Unix shells and the Lisp that lives inside the Emacs editor are probably the most important pure interpreted languages.

11.3. P-code languages

Since 1990 a kind of hybrid language that uses both compilation and interpretation has become increasingly important. P-code languages are like compiled languages in that the source is translated to a compact binary form which is what you actually execute, but that form is not machine code. Instead it's pseudocode (or p-code), which is usually a lot simpler but more powerful than a real machine language. When you run the program, you interpret the p-code.

P-code can run nearly as fast as a compiled binary (p-code interpreters can be made quite simple, small and speedy). But p-code languages can keep the flexibility and power of a good interpreter.

Important p-code languages include Python, Perl, and Java.

References

• Graphics from chapter 1 of How to Think Like a Computer Scientist: Learning with Python v2nd Edition documentation -openbookproject.net/thinkCSpy/ch01.html.
• en.wikipedia.org/wiki/Software_development_process