Introduction to Programming/About Programming

From Wikiversity

Jump to: navigation, search

Contents

[edit] Why should we create computer programs?

What is it that makes computer programming useful or pointless? What are the goals, common problems, and solutions related with computer programming?

Optional reading: History of programming - what problems and tasks motivated the invention of programmable machines?

A computer is a tool for solving problems with information. You can't write a program without knowing what problem you are trying to solve any more than you can swing a knife without knowing what it is that you want to cut.

Code with a purpose. This is how:

[edit] Basic goals of computer programming

When you are planning to create a computer program you should thoroughly consider these aspects of the program you intend to make:

  • Utility: Ensure your program effectively fulfills the need it is addressing.
  • Usability: Ensure that people can easily use your program without a major time investment.
  • Maintainability: Ensure that it is easy to understand, fix, and improve your program without a major time investment.

[edit] Common problems

These are very common mistakes programmers make, which you should avoid:

  • Utility
    • Your program does not do a job any better than an alternative program. At best, you're "re-inventing the wheel", wasting time.
    • Your program does not work how it is supposed to work.
  • Usability
    • Your program is too complicated or too simple to be useful to most people. Only a small minority of people want to play 20,000 questions when they're using a program. Just because you like to hack the details doesn't mean the average user of your program does.
  • Maintainability
    • Other people, or yourself at a later time can't easily understand the programming behind your program. This means your project won't grow and become better as much as it's capable of.

[edit] Solutions

  • Utility and Usability
    • Survey the field to look for programs something like what you intend to make. Determine what you like and don't like about those programs. Figure out ways to improve those programs.
    • Find source code for similar programs to what you want to make if at all possible. Unfortunately, there is also a lot of inferior quality code floating around. Don't be one of those people. Only release quality programs.
    • Thoroughly plan what you want your program to do before you start working on it.
    • Aim towards the maximum functionality your program can achieve while maintaining minimal complexity. Think of the iPod, match-stick, door-knob, and TV. People love things which are simple, useful, and cool.
    • If possible: Talk to people who might use your program to get an idea of what they'd like to see in the program you intend to make.
    • Remember the 80/20 rule - 20% of the features in most programs are used 80% of the time. If you can successfully identify even a few of the seldom used features - and leave them out - you can achieve significant cost savings without sacrificing usefulness.
  • Maintainability
    • Make it easy for someone to look at your program's source code and understand what's going on.
    • Use comments when you're doing complicated things in your program.
    • Don't make very large routines or lines of code.
    • Use simple, easy-to-understand names for variables.
    • Look at a variety of source code, and especially source code meant to be used as an example of proper programming form. Recognise the structure they're using to make things simple. Its definitely there.

[edit] Make programming easy for you and everybody else

Computers and computer programs are intended to make our lives easier, not more complicated. Remember this.

Programmers have figured out a very good way of doing things which is what the idea of a wiki was likely based upon: Open-source software.

Open-source software is software written by an author who has released that software with the source code, freely available for anybody to look at, modify, improve, and implement into their own software. Just like wiki, this is a phenomenally useful way of doing things.

To make programming easier for all coders:

  • Release open-source software
  • Take advantage of open-source software to create more open-source software.

[edit] What is a program?

A program is a set of instructions that tell a computer how to do a task. When a computer follows the instructions in a program, we say it executes the program. You can think of it like a recipe that tells you how to make a peanut butter sandwich. In this model, you are the computer, making a sandwich is the task, and the recipe is the program that tells you how to execute the task.

  • Activity: Come up with a set of instructions to tell someone how to make a peanut butter sandwich. Don't leave any steps out, or put them in the wrong order.

Was that easy? Did you remember all the steps? Maybe you forgot to tell me to use a knife to spread the peanut butter. Now I've got peanut butter all over my hands! Of course, you say, a person wouldn't be that dumb. But a computer is that dumb. A computer will only do what you tell it to do. This might make programming frustrating at first, but it's relieving in a way: if you do everything right, you know exactly what the computer is going to do, because you told it.

Of course, computers don't understand recipes written on paper. Computers are machines, and at the most basic level, they are a collection of switches - where 1 represents "on" and 0 represents "off". Everything that a computer does is implemented in this most basic of all numbering systems - binary. If you really wanted to tell a computer what to do directly, you'd have to talk to it in binary, giving it coded sets of 1's and 0's that tell it which instructions to execute. However, this is much too difficult. In practice, we use a programming language.

[edit] What is a programming language?

A programming language is a way for a person to write a program without writing directly in binary. Programming languages are human-readable but cannot be directly executed by a computer. In order for this to happen, a computer must either compile or interpret them before they can be executed.

[edit] Compilation vs Interpretation

A compiled program has been modified into binary before its use. The binary is then permanently stored. Compiled programs are machine-readable only.

An interpreted program is stored in a human-readable form. When the program is executed, an interpreter modifies the human-readable content as it is run.

There are advantages for both types of software development. As a very broad rule, compiled programs are faster to run but slower to develop. Compiled programs often run faster because the computer only needs to execute the binary operations. In interpreted languages, every time the program is run the computer also needs to create the binary instructions. On the other hand, interpreted languages are often written in a smaller time frame, because the languages are simpler and the whole program does not need to be compiled each time a new feature is bug tested.

Features of both approaches are discussed in more detail later.

[edit] Levels of programming languages

Programming languages are described in levels. Low-level programming is close to binary, high-level programming is closer to natural languages. At the most basic level (low-level) is assembly language. This language is just a direct translation of the binary instructions the computer executes. Every kind of processor architecture has its own assembly language. Here's how to add two numbers in MIPS assembly:

LUI  R1, #1
LUI  R2, #2
DADD R3, R1, R2

This just did the calculation 1 + 2 = 3.

To implement a given feature for a program in assembly language almost always requires more code than implementing the same feature in a higher level language such as C or C++. Assembly language gives the programmer the ultimate in flexibility and performance, at the expense of complexity and development time. As a general rule, a given programmer will produce a more-or-less constant amount of code per day. This makes assembly language very costly relative to other languages.

High-level languages look more like natural language with mathematical operations thrown in. These languages require more translation before the computer will understand them, but they are much easier to write. Here's what the same thing might look like in a high-level language:

x := 1 + 2;

Depending on the language used, and the particular implementation of the language used, the process to translate high-level language statements to actions may involve compilation and interpretation. Compilation is a process in which high-level language statements get translated to lower-level language statements, compilation is done by a special program called compiler. Interpretation is a process in which language statements are realized into actions, interpretation is done either by the CPU or by a special program called Interpreter or Virtual Machine. Not all languages are compiled, although all languages are interpreted in one way or another.

[edit] Translation schemes

Translating source code to binary actions are generally restricted to the compiled scheme and interpreted scheme. A common misunderstanding is that these schemes are properties of the language itself. Technically speaking, they are properties of the implementation of the language. To further complicate matters, perfect classification of different schemes is difficult. To illustrate this, we will discuss the following examples below:

  • An implementation using multiple schemes
  • Multiple implementations using multiple schemes
  • An implementation changing their scheme
  • An implementation using a mixed scheme
  • Compiled Scheme. A program's source code is compiled to machine code/binary/executable. This executable is then interpreted by the CPU (in practice, most compilers do not compile directly to machine code, many compile to C then to assembly before recompiling to machine code, this process is usually done transparently). Example: gcc (C), g++ (C++), MSVC (C/C++), ghc (w:Haskell|Haskell), fpc (Pascal), gpc (Pascal), V8 (Javascript), Visual Basic 6 Native Code (BASIC)
  • Interpreted Scheme. A program's source code is interpreted line-by-line by a program called Interpreter, when there is a control structure . In practice, this scheme is very rarely used, because the interpreter had to reinterpret the source code every time the line is executed again and because it isn't very hard to cleanly move to any one of the mixed schemes. Example: PHP 3 and before (PHP), SpiderMonkey (JavaScript)
  • Mixed Scheme. This is a group of schemes that involves a compilation to an intermediate form but it is never compiled to machine code. Note that some languages implementation in this scheme (e.g. Sun Java) might selectively compile parts of its code to machine code (Just-In-Time compilation) for optimization purpose.
    • Virtual Machine Scheme. A program's source code is compiled to a platform-independent byte-code file, which resembles machine code but cannot be run directly by the CPU. Instead, a special program called Virtual Machine would interpret the byte-code. Example: javac and JVM (Sun Java), CPython (Python), PHP 4 and above (PHP), Visual Basic 6 P-code (BASIC), various .NET languages (C#, VB.NET).
    • Abstract Syntax Tree Scheme. A program's source code is compiled to an in-memory object equivalent of the source code. Thus, the source code is only read once and the program is run from this tree. Example: perl (Perl), pugs (Perl)

Also note that all languages are theoretically able to be implemented in every scheme. However, each language fits a certain scheme better than other schemes.

Some (short-sighted) programmers considers interpreted languages to be inferior because it is slower compared with compiled languages. In fact, because of their dynamic nature, interpreted languages can be substantially more flexible, easier to learn, and faster to develop - sometimes you can have your program weeks sooner for the small price of being a fraction of a second slower; especially when you are using the fast computers of the modern age. In some limited cases, an interpreted language's core functions might be so highly optimized to the extent that an average quality program in compiled language could be slower than one written in interpreted language. In other cases (like applications using a database, or network access) a majority of your application's time is spent waiting to access data or the network, and using a "faster" compiled language will not make much difference. In fact, the general rule is : don't choose a language because it's faster. Otherwise, you'd better use assembly language directly. Choose a language you're comfortable with, which looks "sexy" to you. It will be your friend during your whole programming work so choose well. Try several languages out before making a definitive choice.

It would be nice to have "one language to rule them all" but we don't. The fact is, many different languages exist for different purposes. There are a few languages that fulfill a wide variety of programming needs, but to encompass all of them, it would have to be such a huge undertaking and become cumbersome and segmented as programmers begin customizing the language to their needs. Truth be told, many languages have become customized thus and released as independent packages, simplified for a smaller audience and streamlined for efficiency in that area only. Lua is for example targeted for scripting in games. While it's usable from outside of this context, it's where it will probably be the most efficient/adapted.

[edit] How does one become a programmer?

A programmer is generally tasked with producing a solution to a problem via a computer program, which can be reused as various particular instances of that problem arise. To accomplish this task, the programmer therefore must be able to understand the problem, derive an appropriate solution, and then be able to effectively express that solution in a computer programming language.

The first prerequisite to becoming a programmer is to develop a strong background in problem solving as is often required in fields such as mathematics and engineering. The ability to formally, concisely, and clearly state a problem and then derive its solution is a fundamental skill that precedes the process of any computer coding. The study of computer algorithms focuses on the generalized problem solving approaches often applicable in computer science. Techniques such as programming design patterns provide practical templates which often help frame solutions in an understandable, reusable manner. In general, there are many different classes of problems in computer science that require different techniques to solve effectively: having a strong repertoire of approaches aids in finding good solutions.

The second prerequisite to becoming a programmer is knowing a programming language with which to express a particular solution to a problem. A programming language is a tool, which practice will help hone into expertise. Learning multiple languages can often be helpful as the process will demonstrate the particular strengths of different approaches to solving particular classes of problems[1].

In both these areas, practice is essential. Exposure to a wide variety of problems and tools to solve them will increase your understanding of the field as whole, to judge for yourself the relative merit of techniques in the field, as well as to discover unique, new approaches to addressing the problems of computer science. As with the practice of any new skill, do not be afraid to make mistakes, to redo earlier work, or to stumble along the way to expertise.

Don't be afraid to make mistakes because you will make them - constantly and for the rest of your career. Even the best programmers make mistakes regularly (if they try to say differently then they are either lying or deluded). Making mistakes is really part of the programing process. Someone said, to find a solution to a problem you must partly solve the problem. So you'll probably end up rewriting parts of your programs several times. Part of what distinguishes better programmers is their ability to catch at least some mistakes before they become a problem. Nobody can catch them all without help. Well, nobody can catch them all : there is no bug-free program. Additionally, it is good coding practice to code the smallest modules of a program, one at a time. This provides an isolated testing environment. Just be sure that everything is planned carefully from the outset, so that the little modules are not "orphaned" from other modules that they need to run. Note that when this approach is used, care should be taken to lay the foundation first, making careful note of "dependencies" within the program; code modules upon which other modules rely first, and then code higher-level modules after the foundations have been thoroughly tested. Unit testing is a good programming practice. Some programming processes, such as XP (eXtreme Programming), recommend to write tests before actual code.

Learn to work with others in a team environment. People have different strengths and weaknesses and a good team can bring together people whose strengths and weaknesses are complementary. The members of a team can teach each other. Most importantly, teams can tackle problems that would be too big for an individual. Beware, though, teams are not easy to lead and you can easily make a project a disaster by just gathering as many people as you can. If you want to work with a team, come with a solid design and a strong vision of what the project should look like when it's finished. If other members of the team suggest new ideas, take them with consideration but do not fall in the feature-greed pitfall, e.g. your project is never finished because the final goal grows beyond all proportions. As the XP process suggest, make small and frequent releases, prefer running code to vague and abstract design.

As you continue to practice the art, take some time here and there to learn about the underlying theory that makes up the field commonly referred to as Computer Science.

[edit] Footnotes

  1. ↑ For further information on programming languages and how they vary, see Scott, M. L. 2005 Programming Language Pragmatics. Morgan Kaufmann Publishers Inc.
Retrieved from "http://en.wikiversity.org/wiki/Introduction_to_Programming/About_Programming"