The easy way to learn programming fundamentals and essentials So you want to be a programmer? Or maybe you just want to be able to make your computer do what YOU want for a change? Maybe you enjoy the challenge of identifying a problem and solving it. If programming intrigues you for whatever reason, Beginning Programming All-in-One Desk Reference For Dummies is like having a starter programming library all in one handy, if beefy, book. In this practical guide, you'll find out about compiling, algorithms, best practices, debugging your programs, and much more. The concepts are illustrated in several different programming languages, so you'll get a feel for the variety of languages and the needs they fill. Seven minibooks cover: * Getting started * Programming basics * Data structures * Algorithms * Web programming * Programming language syntax * Applications Beginning Programming All-in-One Desk Reference For Dummies shows you how to decide what you want your program to do, turn your instructions into "machine language" that the computer understands, use programming best practices, explore the "how" and "why" of data structuring, and more. You'll even get a look into various applications like database management, bioinformatics, computer security, and artificial intelligence. Soon you'll realize that -- wow! You're a programmer! Note: CD-ROM/DVD and other supplementary materials are not included as part of eBook file.
Ebooka przeczytasz w aplikacjach Legimi na:
Liczba stron: 843
by Wallace Wang
Beginning Programming All-In-One Desk Reference For Dummies®
Published byWiley Publishing, Inc.111 River StreetHoboken, NJ 07030-5774www.wiley.com
Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana
Published by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
Understanding how computer programming works
History of computer programming
Believe it or not, if you can write a recipe on an index card, you can program a computer. At the simplest level, computer programming is nothing more than writing instructions for a computer to follow, step by step. The most important part of programming isn’t in knowing how to write a program or how to use a particular programming language, but in knowing what to create in the first place.
Some of the most popular and useful computer programs were created by people who didn’t have any formal training in math or computer science. Dan Bricklin invented the spreadsheet while studying for his MBA at Harvard Business School. Scott Cook, who worked in marketing and product development at Proctor & Gamble, created the popular money-management program Quicken
Choosing your software engineering method
Using CASE to automate software engineering
The pluses and minuses of software engineering
Writing a small program is easy. You just type your program in an editor and shove your source code through a compiler. If you find any problems, dig through the source code, fix the problem, and recompile the whole thing all over again. No matter how many bugs pop up in your program, chances are good your program is small enough so you can hunt any bugs and wipe them out without much trouble.
Arranging a Program
Dividing programs into subprograms and objects
Building a user interface
Programming is nothing more than problem-solving. Every program is designed to solve a specific problem, such as taking the trouble out of editing text (a word processor), calculating rows and columns of numbers (spreadsheets), or searching and sorting information (a database).
Before you write any program, you must first know what problem you want the computer to solve. Computers are best at solving repetitive tasks, such as calculating rows and columns of numbers in a spreadsheet. Anyone can do similar calculations by hand, but computers make the task much faster and accurate.
After you know what problem to solve, the next step is figuring out how to solve that problem. Many problems may have multiple solutions. For example, how can someone get from the airport to your house? One way might be to take the highway, which may be the simplest route although not necessarily the fastest. Another way may take you through winding roads that can be harder to navigate.
In general, every problem has multiple solutions with each solution having its pros and cons. Should you tell someone to take the shortest way to your house (which might be harder to follow) or the easiest way to your house (which might take longer to get there)?
Computer programs face this same dilemma in choosing the “best” solution. One solution might be slow, but require less memory to run. Another solution might be fast, but require gobs of memory. When deciding on a solution, you always have to consider additional factors, such as what type of computer the program runs on, what type of environment the program is used in, and what type of people are using it.
After you choose a solution, the next step involves dissecting how your chosen solution works so that you can translate those steps into instructions for the computer to follow.
Every program consists of step-by-step instructions. Just as you can write the same instructions for a person in English, French, Spanish, Arabic, or Japanese, so can you write the same program for a computer in different programming languages.
You can literally write a program with thousands of possible programming languages. Every programming language is designed to solve one problem exceptionally well, but may solve other types of problems poorly.
For example, the BASIC programming language is meant to teach programming, but it’s not very good for controlling the hardware of a computer, such as for writing an operating system or antivirus program. On the other hand, the C programming language is meant to give you absolute control over every part of the computer so that’s why most operating systems and antivirus programs are written in C. However, the C language can be much more frustrating and confusing for novices to understand compared to BASIC.
Ideally, you want to pick the programming language best suited for solving your particular problem. Realistically, you probably know only a handful of programming languages, so out of all the languages you know, you have to pick the one language that’s best suited for solving your problem.
You can write any program in any programming language. The only difference is that some programming languages can make writing certain programs easier than others. The “best” programming language to use is always the language that makes writing a program easy for you.
Every program consists of one or more commands (instructions), and each command is a line of code or a statement. The more lines of code, the more complicated the program.
The goal of programming is to write the fewest lines of code that do the maximum amount of work.
Each command tells the computer to do one thing. Put enough commands together and you can create a simple program, as shown in Figure 1-1.
Figure 1-1: If you put enough commands together, you can create any type of program.
Every programming language provides a list of commands dubbed keywords or reserved words. By typing keywords one after another, you can tell the computer what to do.
A programming language’s keywords act like the letters of the alphabet. Type letters in different combinations and you can create different words. Type keywords in different combinations and you can create different commands, as shown in Figure 1-2.
Figure 1-2: Multiple keywords, along with various symbol characters, can create a single command.
Computer scientists are divided on whether it’s better for a programming language to offer a lot of keywords:
By offering a lot of keywords, a programming language can let programmers write fewer keywords that do more work.
By offering fewer keywords, a programming language makes programmers write a lot of simple keywords just to do something that another language might be able to do with one keyword.
Given these choices, having a lot of keywords in a programming language seems to make more sense. The problem is that the more keywords used, the harder it is to write a compiler for that programming language. The harder it is to write a compiler, the less efficient that compiler is in converting source code into machine language, just as it’s much harder to translate a Russian scientific paper into English than it is to translate a Russian children’s story into English.
That’s one problem with the Ada programming language. Ada uses lots of keywords, which makes programming easier but creating compilers for Ada much harder. This is one of the reasons why Ada compilers are much less widespread than compilers for the C programming language.
Unlike Ada, C offers a bare minimum of keywords. This makes programming in C harder because you need to write a lot of keywords to do something as seemingly simple as storing a text string. However, C’s handful of keywords makes it much easier to write a C compiler.
To compensate for the lack of keywords, most C compilers include libraries of commonly used subprograms that can make C programming easier and more useful.
As a result, you can find C compilers for practically every computer because it’s much easier to write a C compiler than it is to write an Ada compiler. The more C compilers available, the easier it is to transfer (port) a C program to another computer. The C programming language is popular partly because you can run C programs on almost every computer.
With a lot of keywords, Ada makes programming easier for humans but harder for computers. In contrast, a handful of keywords in C makes programming harder for humans but much easier for computers. Given a choice between Ada or C, more people choose C, so having a programming language with fewer keywords seems to be more efficient (at least for the computer).
Every program consists of one or more commands, but there are different types of commands. Some commands tell the computer how to manipulate data, such as adding two numbers together. Other commands might tell the computer how to print data, display it on-screen, or save it on a disk.
Although you could jumble all your commands together and still have a working program (see Book 1, Chapter 2 for more on programs), make your program easier to read and modify by organizing similar commands in different parts of your program.
So if your program isn’t printing correctly, you don’t have to search through your entire program to find the faulty commands. Instead, you can just look at the part of your program where you grouped all your printing commands, as shown in Figure 1-3.
Figure 1-3: Dividing a large program into parts can make it easy to find specific commands in your program.
When you write a simple program that consists of a handful of commands, organizing related commands in groups isn’t too important, but when you start writing bigger programs that consist of hundreds or thousands of commands, organizing commands can mean the difference between writing a program that nobody can understand or a program that’s easy for anyone to understand and modify.
When you save your program, you save it as a single file on the computer. However, the more commands you write, the bigger your program gets, and the bigger the file you need to store the whole program.
No matter how carefully you organize your commands, eventually your program will get too big and cumbersome as a single massive file to read and modify easily. That’s when you need to break your program into smaller parts.
The smaller the program, the easier it is to write, read, and modify later. So rather than create a massive program, with related commands organized into groups, you can divide a large program into smaller pieces, or subprograms.
Subprograms essentially break up a large program into multiple miniature programs with each miniature program acting like a building block to create a much larger program, as shown in Figure 1-4. So rather than build a large program entirely out of keywords, you can build a program out of keywords and subprograms (which are themselves made up of keywords).
Figure 1-4: Subprograms create reusable building blocks that you can use to make writing programs even easier.
Think of subprograms as a way to create keywords that aren’t built into the programming language. For example, the C programming language doesn’t have any keywords for working with text strings, so programmers have used C’s existing keywords to create subprograms that can work with text strings. By using these existing subprograms, other C programmers can manipulate text strings without writing their own commands.
Using keywords alone to create a program is like trying to build a skyscraper out of bricks. It’s possible, but it takes a long time to layer enough bricks to reach the height of a typical 50-story skyscraper.
Using subprograms to create a larger program is like using I-beams to build a skyscraper. Essentially, I-beams act like bigger bricks the same way that subprograms act like bigger building blocks than keywords by themselves.
You can store subprograms in two places:
In one file
In separate files
Storing subprograms in the same file is no different than grouping related commands together in one file. This is like storing your socks, underwear, and shirts in the same drawer but pushing them into separate corners. The drawer may be organized, but such an arrangement is suitable only if you don’t have many clothes to worry about. The moment you get more clothes, you need a bigger drawer to hold it all.
The same holds true with storing subprograms in a single file. Eventually, if you group enough commands into subprograms, a single file crammed full of subprograms can still be cumbersome to read and modify.
To keep files down to a reasonable size, programmers store subprograms in separate files, as shown in Figure 1-5. Not only does this avoid cramming everything into a single file, but separate files also give you the option of creating reusable libraries of subprograms that you can copy and reuse in another program.
Libraries of subprograms, stored as separate files, are discussed in Book 1, Chapter 4.
Programmers often sell their libraries of subprograms to others, although each library of subprograms is usually designed to work only with a specific programming language and operating system, such as C++ running on Windows. Many Windows libraries of subprograms are stored as dynamic link libraries (DLL) although you may see some libraries sold as something called ActiveX controls or .NET components.
The name simply tells you what type of programming languages and computers you can use the programming library on. So if you’re using a programming language that can use ActiveX controls, you can buy third-party libraries of subprograms stored as ActiveX controls. If you’re using a programming language that can use .NET components, you can use subprogram libraries stored as .NET components.
When you get a library of subprograms (for free or for a price), you may also get the source code to those subprograms. With the source code, you can modify the subprograms. However, most subprogram libraries don’t include the source code so that you have to pay for an updated version of the subprogram library.
Figure 1-5: Storing subprograms in separate files can make it easy to read and modify one part of a large program without having to see any other part of that same program.
By storing subprograms in separate files, you can write a program with multiple programming languages. That way you can write your main program in BASIC and then write subprograms in C or Java. By doing this, you don’t have to limit yourself to the strengths and weaknesses of a single programming language. Instead, you can take advantage of the strengths of each programming language.
If you’re writing a hard disk diagnostic program, you could write the whole thing in C because C is great for accessing the hardware of a computer. However, you may find that C is too clumsy for printing reports or displaying information on-screen. In that case, what are your choices? You can
Use C to write the whole program. This is great for accessing computer hardware but hard for writing the rest of the program, like the user interface.
Use an easier language, like BASIC, to write the whole program. This is great for writing every part of the program except the part needed to access the computer hardware.
Use a mix of two or more programming languages. Use BASIC to write most of the program and then use C to write a subprogram to access the computer hardware.
By giving you the option to choose the best programming language for a specific task, subprograms help make it easier for you to write larger programs, as shown in Figure 1-6.
Figure 1-6: Subprograms give you the option of using different programming languages to write different parts of a larger program.
The more complicated programs get, the larger they get. If programs get too big, they get harder to write, understand, and modify. This is why dividing a large program into multiple smaller subprograms can make programming much easier. Just write a bunch of little programs and then paste them together to create a bigger program.
Unfortunately, dividing a large program into subprograms isn’t without its problems:
In theory, if you want to update a program, you can modify a subprogram and plug that modified subprogram back into the main program to create an updated version.
In reality, that almost never works. The problem comes from the fact that subprograms aren’t always independent entities that you can yank out and replace without affecting the rest of the program. Sometimes one subprogram relies on data manipulated by a second subprogram. Change that first subprogram, and those changes could affect that first subprogram in a domino-like effect, as shown in Figure 1-7.
Figure 1-7: Changing one part of a program can affect other parts of that same program.
When subprograms are highly dependent on each other, they’re high, strong, or tight coupling. When subprograms aren’t dependent on each other, they’re low, weak, or loose coupling. You want your subprograms to have low, weak, or loosecoupling. That way, changing one part of your program doesn’t accidentally affect another part of your program.
To enforce weak coupling, computer scientists have created object-oriented programming (OOP). The main idea behind OOP is to divide a large program into objects.
Objects act like “super” subprograms. Whereas subprograms give programmers the choice of making a tightly or loosely coupled subprogram, objects force programmers to create loosely coupled subprograms.
By forcing programmers to create loosely coupled subprograms, objects make it easy to modify a program without worrying about any unintended side effects. OOP lets you yank out an object, modify it, and plug it back in without worrying if your changes might affect the rest of the program.
Objects offer another advantage over subprograms. Whereas subprograms typically represent a specific action, objects represent specific physical items in the real world.
For example, if you’re writing a program to control a robot, you could divide the program into the following subprograms that make the robot:
Sense obstacles (through sight and touch) in its way
If you’re using OOP, you could divide that same program into objects that represent the robot’s
Eyes (video camera)
The way you divide a large program into parts isn’t important. What’s important is how easy it is to modify those separate parts later. Suppose you rip the legs off your robot and replace them with treads. In an OOP, you can yank out the Legs object and replace it with a Treads object, as shown in Figure 1-8.
Figure 1-8: Object-oriented programming divides your program into logical parts that correspond to the real world.
Although the robot now uses treads instead of legs to move, the Brain object can still give the same type of commands to make the robot move, such as Move Forward, Move Backward, and Stop.
How do you change the equivalent program divided into subprograms? First, you have to change the Move subprogram to reflect the change in movement from legs to treads. Then you may need to change the Navigate subprogram so it knows how to navigate in different directions with treads instead of legs. Finally, make sure the changes you make in the Navigate and Move subprograms don’t accidentally affect the Sense subprogram.
Sounds like a lot of work just to make a simple change? It is, and that’s why loose coupling between subprograms is so important. Because programmers can’t always be trusted to make sure their subprograms are loosely coupling, OOP forces them to do it whether they like it or not.
The three actions of most programs are
Manipulate that data.
Create a result.
A football-picking program takes in data about both teams, uses a formula to predict a winner, and prints or displays its answer on-screen. A hotel reservation program gets a request for a room from the user (hotel clerk), scans its list of rooms for one that’s available and that matches the user’s criteria (no smoking, two beds, and so on), and displays that result on-screen.
Basically, every program takes in data, calculates a result, and displays that result. To accept data from the user and display a result back to the user again, every program needs a user interface, as shown in Figure 1-9.
Figure 1-9: The user interface accepts data and displays the results of its calculations back to the user.
The user interface of most computer programs includes drop-down lists, buttons, and dialog boxes. If a program doesn’t get data from a person, its user interface may be just a physical cable connection because its user could be another computer feeding it information like stock quotes.
To create a program, you have to create both your program and your user interface. The user interface acts like a middleman between the user and the program. Here are three common ways to create a user interface:
Create it from scratch.
Use a subprogram library.
Use a rapid application development (RAD) tool.
Creating your own user interface takes time to write and even more time to test. Although nothing’s wrong with creating your own user interface, the time spent creating a user interface could be better spent writing your actual program. For that reason, few programmers create their own user interfaces unless they have special needs, such as designing a user interface to be used by blind or disabled users.
Tysiące ebooków i audiobooków
Ich liczba ciągle rośnie, a Ty masz gwarancję niezmiennej ceny.
Napisali o nas:
Nowy sposób na e-księgarnię
Czytelnicy nie wierzą
Legimi idzie na całość
Projekt Legimi wielkim wydarzeniem
Spotify for ebooks