\chapter{Introduction to Programming\label{chap:intro}}

\section{What is Perl?}

Extracted from the \link{http://www.perldoc.com/perl5.8.0/pod/perl.html}{perl} manpage, \\ 
\textit{``Perl is an interpreted high-level programming language developed by Larry Wall.''} \\


If you have not learnt any programming languages before, as this is not a prerequisite of this tutorial, this 
definition may appear exotic for you. The two keywords that you may not understand are 
``interpreted'' and ``high-level''. Because this tutorial is mainly for those who do not have any
programming experience, it is better for me to give you a general picture as to how a computer 
program is developed. This helps you understand this definition. \\

\section{A Trivial Introduction to Computer Programming}

You should know that, regardless of the programming language you are using, you have to write something 
that we usually refer to as \term{source code}, which include a set of instructions for the computer 
to perform some operations dictated by the programmer. There are two ways as to how the source code 
can be executed by the Central Processing Unit (CPU) inside your computer. The first way is to 
go through two processes, \term{compilation} and \term{linking}, to transform the source code 
into \term{machine code}, which is a file consisting of a series of numbers only. This file is 
in a format that can be recognized by the CPU readily, and does not require any external programs 
for execution. Syntax errors are detected when the program is being compiled. We describe this 
executable file as a \term{compiled} program. Most software programs (e.g. most EXEs for MS-DOS/Windows) 
installed in your computer fall within this type. \\

\specialbox{NOTES}{%
	There are some subtleties, though. For example, the compiler that comes with Visual Basic 6 Learning 
	Edition translates source code into p-code (pseudo code) which has to be further converted to machine 
	code at runtime. Such an EXE is described as interpreted instead. Therefore, not all EXEs are compiled. \\
	
	On the other hand, although Java is customarily considered an interpreted language, Java source files are 
	first compiled into bytecode by the programmer, so syntactical errors can be checked at compile time. \\
}

Another way is to leave the program uncompiled (or translate the source code to an intermediate level between 
machine code and source code, e.g. Java). However, the program cannot be executed on its own. 
Instead, an external program has to be used to execute the source code. This external program is known as an 
\term{interpreter}, because it acts as an intermediary to interpret the source code in a way the CPU can understand.
Compilation is carried out by the interpreter before execution to check for syntax errors and convert the 
program into certain internal form for execution. Therefore, the main difference between compiled programs 
and interpreted languages is largely only the time of compilation phase. Compilation of compiled programs is 
performed early, while for interpreted programs it is usually performed just before the execution phase. \\ 

Every approach has its respective merits. Usually, a compiled program only has to be compiled once, and thus
syntax checking is only performed once. What the operating system only needs to do is to read the compiled 
program and the instructions encoded can be arranged for execution by the CPU directly. However, interpreted
programs usually have to perform syntax check every time the program is executed, and a further compilation
step is needed. Therefore, startup time of compiled programs are usually shorter and execution of the program 
is usually faster. For two functionally equivalent programs, a compiled program 
generally gives higher performance than the interpreted program. Therefore, performance-critical applications
are generally compiled. However, there are a number of factors, e.g. 
optimization, that influence the actual performance. Also, the end user of a compiled program
does not need to have any interpreters installed in order to run the program. This convenience factor is
important to some users. On the other hand, interpreters have to be installed in order to execute a program that is interpreted. One 
example is the \term{Java Virtual Machine} (JVM) that is an interpreter plugged into your browser to support Java applets. 
Java source files are translated into \term{Java bytecode}, which is then executed by the interpreter. 
There are some drawbacks for a compiled program. For example, 
every time you would like to test your software to see if it works properly, you have to compile and link the 
program. This makes it rather annoying for programmers to fix the errors in the program (\term{debug}), although
the use of makefiles alleviates most of this hassle from you. Because compilation translates the source code 
to machine code which can be executed by the hardware circuitry in the CPU, this process creates a file in machine 
code that depends on the \term{instruction set} of the computer (machine-dependent). On the other hand, interpreted 
programs are usually \term{platform-independent}, that is, the program is not 
affected by the operating system on which the program is executed. Therefore, for example, if you have a Java  
applet on a Web site, it can most probably be executed correctly regardless of the operating system or browser a 
visitor is using. It is also easier to debug an interpreted program because repeated compilation is waived.\\

\specialbox{TERMINOLOGY}{%
	\term{Instruction set} refers to the set of instructions that the CPU executes. There are a number of types 
	of microprocessors nowadays. For example, IBM-compatible PCs are now using the Intel-based instruction set. 
	This is the instruction set that most computer users are using. Another prominent example is the Motorola 
	68000 series microprocessors in Macintosh computers. There are some other microprocessor types which exist 
	in minority. The instruction sets of these microprocessors are different and, therefore, a Windows program 
	cannot be executed unadapted on a Macintosh computer. In a more technical parlance, different microprocessors 
	have different \term{instruction set architectures}. \\
}

Recall that I mentioned that a compiled program consists entirely of numbers. Because a CPU is actually an electronic 
circuit, and a digital circuit mainly deals with Booleans (i.e. 0 and 1), so it is obvious that programs used by 
this circuit have to be sequences of 0s and 1s. This is what machine code actually is. However, programming entirely 
with numbers is an extreme deterrent to computer programming, because numeric programming is highly prone to mistakes 
and debugging is very difficult. Therefore, assembly language was invented to allow programmers to use mnemonic names 
to write programs. An assembler is used to translate the assembly language source into machine code. Assembly 
language is described as a low-level programming language, because the actions of an assembly language program are 
mainly hardware operations, for example, moving bits of data from one memory location to another. Programming using 
assembly language is actually analogous to that of machine code in disguise, so it is still not programmer friendly enough. \\

Some mathematicians and computer scientists began to develop languages which were more machine-independent and 
intuitive to programmers that today we refer to as \term{high-level programming languages}. The first several high-level 
languages, like FORTRAN, LISP, COBOL, were designed for specialized purposes. It was not until BASIC (Beginner's 
All-purpose Symbolic Instruction Code) was invented in 1966 that made computer programming unprecedentedly easy and 
popular. It was the first widely-used high-level language for general purpose. Many programmers nowadays use C++, 
another high-level language, to write software programs. The reason why we call these ``high-level languages'' is that 
they were built on top of low-level languages and hid the complexity of low-level languages from the programmers. 
All such complexities are handled by the interpreters or compilers automatically. This is an important design 
concept in Computer Science called \term{abstraction}. \\

That's enough background information and we can now apply the concepts learned above to Perl. Perl (Practical 
Extraction and Reporting Language) was designed by Larry Wall, who continues to develop 
newer versions of the Perl language for the Perl community today. Perl does not create standalone programs and 
Perl programs have to be executed by a Perl interpreter. Perl interpreters are now available for virtually any 
operating system, including but not limited to Microsoft Windows (Win32) and many flavours of Unix. As I quoted above, 
\textit{``Perl is a language optimized for scanning arbitrary text files, extracting information from those text 
files, and printing reports based on that information.''} This precise description best summarizes the strength of 
Perl, mainly because Perl has a powerful set of \term{regular expressions} with which programmers can specify search 
criteria (patterns) precisely. You are going to see a whole chapter devoted to regular expression in Chapter~\ref{chap:regex}. Perl is 
installed on many Web servers nowadays for dynamic Web CGI scripting. Perl programs written as CGI applications are executed on servers where 
the Perl source files are placed. Therefore, there is no need to transfer the Perl source to and from the server
(as opposed to client-side scripts like JavaScript or Java applets). Guestbooks, discussion forums and many 
powerful applications for the Web can be developed using Perl. \\

There is one point which makes Perl very flexible --- there is always more than one approach to accomplish a 
certain task, and programmers can pick whatever approach that best suits the purpose. \\

\section{Scripts vs. Programs}

There has always been some arguments over whether to use the term ``script'' or ``program'' for Perl source 
files. In general, a piece of code that is executed by hardware or a software interpreter, written in some kind 
of programming languages, is formally called a ``program''. This is a general term that applies to programs written 
in machine instructions, or any programs that are compiled or interpreted. However, it is also common today to hear
that people use the term ``script'' to refer to programs that are interpreted, especially those executed on the 
command line. In my opinion, it is not important to draw a distinction between the two terms as both are considered 
equally acceptable and understandable nowadays. In many situations people just use both interchangeably. \\

I am more inclined towards calling Perl programs and CGI programs running on a Perl backend as scripts, so I 
will adhere to this terminology in this tutorial. \\

\section{An Overview of the Software Development Process}

An intuitive software development process is outlined below. Note that this process is not tailored for Perl 
programming in particular. It is a general development process that can be applied to any programming projects with
any programming languages. For additional notes specific to Perl, please refer to the next chapter. \\

Because this tutorial does not assume readers to have any programming experience, it is appropriate for 
me to give you an idea as to the procedure you will most probably follow when you write your programs. In general,
the process of development of a software project could be broken down into a number of stages. Here is an outline 
of the stages involved: \\

\begin{itemize}
\item { 
\textbf{Requirements Analysis} \\
First you need to identify the requirements of the project. Simply speaking, you will need to decide what your 
program should do (known as \term{functional requirements}), and note down other requirements that are important but not 
related to the functions of your program (known as \term{non-functional requirements}), for example, a requirement that 
the user interface should be user friendly. You have to make a list of the requirements, and from it you will need 
to decide whether you have the capability to complete them. You may also want to prioritize them such that the most 
important functionalities are developed first, and other parts can be added subsequently.
}
\item { 
\textbf{Systems Design} \\
From the requirements determined you can then define the scope of the project. Instead of putting the whole program 
in one piece, we will now organize the program into several components (or \term{subsystems} --- a part of the entire 
system). As we will discuss later in this tutorial, modularization facilitates code reuse and make correction of bugs 
(debug) easier. Two major models exist today --- decomposition based on functions and decomposition based on objects. 
After you have fixed the model, you decide on which functions or object methods are to be associated with which source 
file or object, and determine how these components interact with each other to perform the functionalities. Note that 
you don't need to decide on how these source files or objects are implemented in real source code at this stage --- it 
is just an overall view of the interaction between the components. We emphasize functional decomposition 
in the first part of the tutorial, while object-oriented programming will be covered in a later part of this tutorial.
}
\item {
\textbf{Program Design} \\
After we have determined how the components interact with each other, we can now decide how each function or object 
method is implemented. For each function, based on the actions to perform you have to develop an \term{algorithm}, 
which is a well-defined programming-language-independent procedure to carry out the actions specified. You may want 
to use a flowchart or some \term{pseudocode} to illustrate the flow of the program. Pseudocode is expressed in a way 
resembling real programming source code, except language-dependent constructs are omitted. As pseudocode is language 
independent, you can transform an idea from pseudocode to source code in any programming languages very easily. There 
isn't a single standardized pseudocode syntax. In many cases, pseudocode can even be written in English-like statements 
because pseudocode is written to demonstrate how a program is supposed to work, and provided it communicates the idea 
clearly it suffices. It is up to you as the author to express pseudocode in whatever way the algorithm is best illustrated.
}
\item {
\textbf{Coding} \\
This is largely the continuation of the Program Design stage to transform your algorithm into programming language 
constructs. If you have worked out the algorithm properly this should be a piece of cake.
}
\item { 
\textbf{Unit Testing} \\
Unit testing corresponds to Program Design. As each function or object method has a predefined behaviour, they can 
be tested individually to see if such behaviour agree to that defined. Most of the time when we are talking about 
debugging, we are describing this stage.
}
\item {
\textbf{Systems Testing} \\
Systems Testing corresponds to System Design. This is to test if the components interact with each other in exactly 
the same way as designed in the Systems Design stage.
}
\item {
\textbf{Requirements Validation} \\
This corresponds to requirements analysis. The software developed is compared against the requirements to ensure 
each functionality has been incorporated into the system and works as expected.
}
\item {
\textbf{Maintenance} \\
By now the software has been developed but you cannot simply abandon it. Most probably we still need to develop 
later versions, or apply patches to the current one as new bugs are found in the program. Software for commercial 
distribution especially needs investment of a lot of time and effort at this stage capturing user feedback, but 
software not distributed commercially should also pay attention to this stage as this affects how well your 
software can be further developed.
} 
\end{itemize}

Of course, for the examples in this tutorial that are so short and simple we don't need such an elaborate 
development procedure. However, you will find when you develop a larger-scale project that having a well-defined procedure 
is essential to keep your development process in order. \\

This is just one of the many process models in existence today. Discussion of such process models can be found in 
many fundamental text for \term{Software Engineering}, and are beyond the scope of this tutorial. Actually, what 
I have presented was a variant of the Waterfall process model, and is considered one that, if employed, is likely 
to delay project schedules and result in increased costs of software development. The reason I present it here is 
that the Waterfall model is the easiest model to understand. Because presentation of process models is out of the 
scope of the tutorial, some Web links will be presented at the end of this chapter from which you will find selected
texts describing process models, including the \term{Rational Unified Process} which I recommend as an improved process
model for larger-scale development projects. Adoption of an appropriate process model helps guide the development 
process with optimized usage of resources, increased productivity and software that are more fault-tolerant. \\

\section*{Summary}

\begin{summary}
	\item Source code include a set of instructions to be executed by the computer through levels of translation.
	\item Low-level programming languages involves architecture-dependent programming with machine code or assembly language.
	\item High-level programming languages are built on top of low-level languages and source programs can usually be platform-independent. 
	\item Source programs are either explicitly precompiled into object code, or are implicitly compiled before execution by the interpreter.
	\item Perl is an interpreted high-level programming language developed by Larry Wall.
	\item Following a well-defined software development process model helps keep the development process systematic and within budgets.
\end{summary}

\section*{Web Links}

\newcounter{count}
\begin{list}{\thechapter.\arabic{count}}{\usecounter{count}}
\item {
	\link{http://lycoskids.infoplease.com/ce6/sci/A0860536.html}{Evolution of Programming Languages} \\
	\textit{http://lycoskids.infoplease.com/ce6/sci/A0860536.html}
}
\item {
	\link{http://www.rational.com/products/rup/whitepapers.jsp}{Rational Unified Process Whitepapers} \\
	\textit{http://www.rational.com/products/rup/whitepapers.jsp}
}
\end{list}

