Introduction To Programming

Basics of Programming

By Sasikumar M, CDAC Mumbai. All rights reserved. You are free to use this for your personal purposes, and for any course work with acknowledgement.

Before we start

Purpose: This writeup is a gentle introduction to programming for those who have never done any computer programming. You must be familiar with working on a computer - logging in, navigating the file system looking at files and directories, running applications and so on. You may have wondered how such applicationa are written or if you could write small applications to play a game of your choice, draw a picture, and so oj. But never learned or attempted any programming. This article is for you, then, to remove those mysteries and get you to fulfill those wishes.

Note: We are not bothered particularly with any specific programming language, as the basics we are going to deal with applies to most programming languages that are widely used. Through notes, along side, we will show you how these constructs look like in PHP - a popular web scripting language. In future other languages may also be covered.

What is programming?

Programming can be seen from different viewpoints. As a computer user, you hav seen applications such as editors, calculators, clocks, media players, and so on. Programming is then the process of building such applications. Imagine that you want a similar application - a computer program for us henceforth - to compute your income tax or to play a game. Writing instructions and making it in a form that you and others can run the program, just as you had been doing with other applications, is programming.

As you would have seen from your experience so far, a computer just obeys our instructions. It cannot discern - and does not bother to discern - what it means or what it would do. You say "print 2", and it prints "2" on the screen. What kind of instructions does a computer understand? That is defined by the programming language you use. Look at your friends and neighbours. They speak different languages - English, Hindi, Tamil, etc. There are also sign languages, Braille for the blind, etc. These languages look very different at a cursory glance. In a similar way, we have many different programming languages. They may appear very different from one another too.

We need a language to communicate anything to others. Imagine using a friend or assistant to get some work done for you. You need to communicate to him what you need to get done, clearly, so that you get the results you want. Most of the human — also called natural — languages are highly ambiguous. You may remember the story of an interview candidate who, when asked to "draw a chair and sit down", picked up a chalk piece, drew the picture of a chair, and sat on it. The speaker and the listener interpreted "draw" in two different senses. We normally use a lot of world knowledge and common sense, to figure out the intended sense of an instruction. But a computer has access to neither. So, we need to be very careful. Compared to the programming languages of yester years, the languages of today are a lot richer and the computers a lot smarter. One day, we can expect the computer to figure out the right meaning, when faced with an ambiguous term or instruction. But for today, a computer is dumb, and we work with that assumption. And so, you will see that a programming language does not sound or read like a natural language. The idea is to make the constructs as unambigous as possible. We want to be as direct and clear as possible, leaving the computer very little trouble figuring out what is to be done. This reflects in the kind of constructs we can use, and the syntax we use in writing programming languages.

Another aspect of language is the kind of things we can ask the computer to perform - the question we posed a while ago. Look at the kind of things a child of 3 years, 6 years, your colleague, and a domain expert can understand. Take an iinstruction like "switch on the a/c". Your technician can execute this instruction without any additional information. Your friend may need to be told "Go to the switch near the door, and put it on". A 6 year old may need to be told, "go to the switch near the door, press the green button till you hear a click". In a similar way, computer languages also come at different levels of abstraction. The lowest level is the machine language, where instructions are numerically coded, and very low level. You can tell only things like add two small numbers, check if a number is zero, and so on. At the next level, the assembly language allows you to name parameters, and use symbolic names for instructions. For example, "ADD X, Y". The so called high level programming languages build layers of abstractions on top of this. You can define adding larger numbers, as taking the numbers from right to left, piece by piece, adding those pieces (taking carry into account), and combining the resultant pieces. Once this is done, your computer now understands "add x, y" where x and y could be large or small. Languages like PHP, Java, C++, etc build in a number of abstractions like this, so that you can talk at fairly high level. However, this is still quite low and detailed compared to how we human beings communicate with one another.

Look at the technician's instruction "switch on the a/c". He is not born with any capability to execute such an instruction. From earlier training (formally or informal), he knows how to perform this action. He internally transforms this to something like "go near the door, locate a large switch board, raise your hand, press the green button, etc". Each of these instructions may need to be further refined, till these are somethings that our "hardware" can understand. Producing such detailed low-level instructions from the high level language instruction is called compilation in programming. You have a language specific compiler which can take a program (a set of instructions) in that language, and produce instructions at the machine language level. In some cases, we do not produce these instructions explicitly, but execute the steps as we figure out the instructions to be carried out. In this case, the application doing this is called an interpreter. PHP is an interpreted language. Java, C++, etc are compiled languages.

So, putting it all together, programming consists of:

  • writing a set of instructions in the chosen language
  • ensuring these instructions comply with the language definition and that they will achieve what you want when executed
  • invoking the interpreter with these instructions

As it happens with human communication, your instructions may not be clear enough or even correct enough. The result is "buggy behaviour" - we say, your program has a bug - our jargon, for an error in your instructions. The interpreter may notice this before executing the instruction and flag an error. For example, you tell the machine "add x to y". But no value has been assigned to x. The interpreter tells you that x is undefined, and hence cannot be added. In some cases, it may be a logical error. You wrote "add x to y", instead of "subtract x from y". The interpreter does not see any problem - remember, it has no idea of what you are going to do. x can be added to y without any problem, and it would do that. You see a problem, when you look at the result. You realise that something is wrong, because the final answer is not what you expected! This kind of problems lead to the "debugging" component of software development, and often the most painful and difficult part of programming. We will talk more about this later.

The challenge in effective computer programming can also be seen to correspond to effective human communication. We saw the issues with correctness of the program. If there are errors of syntactical and logical type, erroneous behaviour will be the result. Another issue is with writing good programs - quite alike effective communication in real life. Choice of words, sentence structure, organisation of steps, overall structure of the instruction, etc help significantly in reducing chances of bugs, misinterpretation, and efficient execution. It is not necessary to master the entire vocabulary and grammar rules of the language to communicate well; often we use a small part of this repertoire for most of the communication. On the other hand, this alone does not make you a good communicator. You need to pay attention to issues such as organisation, using the right construct for the right kind of work, etc. Imagine a 1000 step sequence of instruction, versus, a collection of 10-20 step instruction groups, organised with dependencies. The latter is more easy to understand and also debug. All these concepts carry over to computer programming also.

Thus, our emphasis is not on mastering the nuances of features that various languages provide; but in using the major constructs and features effectively. You can always refer to a reference manual or online help, to get the details of syntax of any specific construct in any given language.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License