In my last column, I promised that this month would mark the beginning of a discussion of computer languages. In particular, I want to take a look at the strengths and weaknesses of various languages. So this month, I'll open the mini-series by looking at data types.
If BASIC is your only programming language, then you probably have not run across this topic before. Yet, more than likely, you have already used various data types. In BASIC, the two underlying data types are numbers and strings. Typically, you might write program lines such as these, where the first line demonstrates numeric data types and the second shows strings:
TOTAL = 3.7 * SUBTOTAL FILE$ = "D3 : TEST.DAT"
Because BASIC has only these two types, the language has a very simple scheme for distinguishing them: String variables have a dollar sign on the end of their names, and string literals have quotation marks around their contents. Other data items are assumed to be numeric— simple and clean. Yet even in BASIC there are actually several implied data types that are not specially declared.
For example, consider the address that you PEEK or POKE to. It must be a number between 0 and 65535. The actual value at that address must be a number between 0 and 255. File numbers must be between 0 and 7. The list could go on. You object? You say these are all simply restricted ranges of the basic numeric data type? In BASIC, that is true. But in other languages….
Just My Type
Consider the following fragment of a Pascal program. In Pascal, the keyword TYPE means that the following declarations are naming various kinds of data, not reserving actual data space. The keyword VAR means that further declarations do indeed reserve space for variables.
TYPE Mem_Address = 0..65535; Mem_Data = 0..255; Channel = 0..7; Open_Mode = ( Rd, Wr, Up ) Cust_Rec = RECORD Name : String; Addr : String; City : String; State : String; Zip : 0..99999; Credit: (OK, Avg, Bad); END; VAR Peeker : Mem_Address; Peeked : Mem_Data; Customer : Cust_Rec; Mail_List : ARRAY [1..100] OF Cust_Rec;
Do you see what we have done? Thanks to Pascal's very rich data-typing capability, we are able to explicitly say what kinds of things a given variable is expected to handle. Take a close look at the variable Peeked. Its declaration says that it is a memory data type. Most Pascals will not even let you try to do a statement such as this:
Peeked = 3.7 * Total;
You are trying to assign a number that probably has a fractional part to a variable that can only have integer values from 0 to 255. Pascal knows you are being naughty, and the compiler burps real quick! And, although the following statement might get through the compiler, it will probably get you a range error when you run the program (if the original value of Peeked is 2 or more):
Peeked = 243 * Peeked;
Wow! Safety first, right? Well, yes. But it is more than that. Code written with strong data typing is more likely to run correctly (I have had several Pascal programs that worked the first time, once they had successfully compiled). Most importantly, in a commercial environment, such code is maintainable— a programmer can look at the code months or even years later and figure out what it is doing.
So, without even really trying, I have shown you one reason to consider learning languages other than BASIC. And I did not mean to imply that Pascal is the only language that has advantages here. Although C is generally more forgiving (another way of saying you can shoot yourself in the foot more easily) than Pascal, you can build quite readable and properly declared data types and structures with it. And, in fact, the newer versions of C—ones which follow the proposed ANSI standard—offer an option of choosing all the close checking of Pascal.
Setting The Record Straight
Go back and look at those Pascal data type declarations again. In particular, look at the Cust—Rec type and the Customer and Mail—List variables. Just as Pascal allows more restrictive variables than BASIC, so does it allow more complex variables. Consider these legal Pascal statements (given the above declarations):
Customer.Name : = ‘Jones’; Customer.Zip : = 77344; Mail_List [ 7 ] : = Customer ; IF Customer.Credit = Bad THEN Write (‘No Credit!’);
Those first two lines might find their way into a BASIC program looking something like this:
CUST$(l, 30) = "JONES" CUST$(78, 82) = STR$(77344)
Which is more readable? If you decided to change from 5-digit to 9-digit zip codes, which program do you think would be easier to modify? No contest, right? And how would you begin to do something as simply as those third and fourth statements in BASIC?