Liberty Basic is develeopped by Carl Gundel
Original Newsletter compiled by Alyce Watson and Brosco
Translation to HTML: Raymond Roumeas

  The Liberty Basic Newsletter - Issue #26 - Jan 98

"The only stupid question is the one you don't ask"!


"There's more than one way to skin a cat." - Part 2

Part 1 covered the big, general aspects of skinning cats.

In this part we take our gloves off and get into the specific aspects of having more than one way to accomplish things.

Ahhh. No. I changed my mind. There is a lot of information that shouldn't be skipped over if you truly wish to understand. I'll make this into a three part article instead of a double header. We'll get to the details after the groundwork has been laid.

You may feel that all of this is unnecessary, and for some of you that may be true, but if you ARE having problems, it could be that you don't have the proper background. Hang in there, we can correct that quickly before moving on toward our goal. I promise to have a few examples of code near the end of this installment.

To begin with, you must understand that most computer languages have more than one way to do things. Within each way however, the lexical syntax of the code you write is very rigid and cannot be altered.

In low level languages (assembly) there are FEW instructions to choose from and you are confined and restricted to one way of doing something. In high level languages (basic) there are MORE of these predefined instructions.

The reasons for this might seem unclear to beginners, but having a bigger list of keywords allows programmers to pick and choose the structure that will do the job best. After you have learned and practiced using these structures many times, selecting the right one will become second nature.

By the time you're through reading this article, you should have a better understanding of the reasons for this - and be able to use this knowledge to your advantage. Soon you will be thinking and speaking in basic - even dreaming in basic.

The FIRST REASON; High level languages are able to use the functions and services that are defined and written in lower level languages. As each new feature is added into a language it becomes easier to use and more useful to more people.

The SECOND REASON is because there are many people involved in developing a computer language. From the top down, we have;

On the inside:

On the outside:

All of the above have been appended with an (s) to indicate these positionsmay be filled by more than one person. In some cases, one person may fill more than one position, and there may be several smaller niches (payroll) in the hierarchy that haven't been listed.

The Concept Originator(s)

The guy (or gal) who discovered a way to make something better, faster, easier to use, cheaper or more versatile. Something was missing from the language they were using at the time, or it would not allow them to do something the way they wanted so they started thinking about what could be done to improve the situation.

The Financier(s)

The people with deep pockets that are convinced the project is worthwhile and figure out how they can all make a living at this.

The Purchasing agent(s)

The ones that buy the things everyone needs to keep working You know, computers, desks, ashtrays, coffee, pizza and rootbeer.

The Researcher(s)

Gather information about anything pertinent, study, collate and then distribute the data to other departments.

The Specifications person(s)

The people that lay out the specifications the language should adhere to. Should they use Microsoft or IEEE math standards. Figure out how many usefull features can be included.

The Designer(s)

Designers take the specifications to the blackboard and start pushing chalk. What will it look like, how will it act, what will it do if this happens, what will happen if this button is pushed before that one.

The Programmer(s)

Take the design and start planning things. Decide what language THIS language should be written in. Lay out the scope and parameters that will be used. Organize the plans into manageable size chunks and flow-chart everything so it will work.

The Code writer(s)

The groovy dudes in the back room that put it all together. They toss out much of the work that has proceeded them, and start getting things done. Along the way, they write a slew of utility programs, a batch of subroutines and hundreds of snippets. All to be used latter in the testing and veri-fication phase. Then they set up the initialization file, the rudimentary beginning code and then start working on the screen interface layouts and dialog boxes.

The Technician(s)

Deal with the hardware aspects of the language. Printer drivers and/or anything relating to physical properties. Trouble-shoot these problems, figure out why something doesn't work right and explain hardware connection details to the code writers.

The Alpha tester(s)

In-house people that put the software through its paces. They are continuously testing updates and new versions. They make sure a problem is repeatable and not just a fluke, take notes and report back to the other groups.

The Documentor(s)

Run the program step by step and write down everything as they go. They explain what happens when each button or menu selection is made, try to give an overall description of the use of the language, make up the glossary, keyword table and appendix.

The Sales person(s)

Make deals with computer stores and software-warehouses to sell the product. Show off the language at conventions. Give demos away and generally strive to make their product be the best on the market.

The Competitor(s) products

It's true, the competions' products play an important part in almost anything. Competition is good. It pushes us forward ... you know the rest.

 Each of them provide usefull input during the languages life-cycle. And once it has started, this feedback process continues - unabated - clear up to the point when the needs of most of those involved outgrow the original conditions, and then someone else will come along with a newer idea and start the whole thing over again.

All of them make suggestions. Everyone wants to have their own ideas included if possible. Pecking order does carry some weight, but it's a secondary issue. It's up to the central core of people to decide what is, and what isn't used. Usually the good ideas find their way inside - and the rest are filed.

This development depends on things like how big the bankroll is, how much time they have, how gifted the staff is, what the weather is doing ... you name it, the list goes on and on.

Think back over what you've just read, it's a bigger picture than you thought it was. And think about this too - Carl's trying to do most of it himself. I have great respect for this guy.

The THIRD REASON is because programmers are all different, each has their own idea about how things should work. They always want to have as many choices as possible. As many "WAYS" as they can to solve their problems.

The FORTH REASON is ... just because ... because it's natural ... because it's normal for us humans to do things in different ways. It would be a pretty boring world to live in if there was only one way of doing things.

Everyone has a different perspective on how things should work.

Here kitty, kitty, nice kitty. Meow?

The cat is out of the bag now and it's time to get to work.

Recently I've seen questions posted about the differences between the "Decision-making" structures we have in Liberty Basic. Good, I'm glad to see you asking questions like these. These are one of the fundamental things you will be using over and over in your programs. Hundreds, no, thousands of times, so you really need to have a clear understanding of them if you want your programs to be successful and work properly.

Be thankful we have three, I'm hoping version 2 will have at least one more. Some languages have even more than four.

They are;

  1. the IF condition THEN statement
  2. the IF condition THEN statement1 ELSE statement2
  3. the WHILE condition : statement: WEND

These are the primary decision making statements. Each of these have secondary syntax structures which we'll get into in the next part of this article. Essentially, these are similar. They are all designed to allow you to ask questions and make decisions based on the result.

In the following examples, I use the word 'condition' to indicate a test, a question, and based upon that test, the 'statement' will either be executed or ignored. Statement can be almost anything. Printing something, calculating, or branching to another section of the program.

Example 1: IF x = 5 THEN PRINT x

 The question is 'Does the variable named 'x' equal the value of 5 ? If x has been set to another value, nothing will be printed - but if x has been set to equal 5 THEN the computer will print; 5 on your screen.

Example 2: IF temp$ = "Stev" THEN PRINT "Stev"

The question is 'Does the variable named 'temp$' equal "Stev" ? f temp$ has been set to another word, nothing will be printed - but if temp$ is in fact equal to "Stev" THEN the computer will print; Stev

 f temp$ is empty, or has been set to "STEV" nothing happens because these letters are in upper case. "STEV" is not the same as "Stev"

You can ask all sorts of questions. Besides asking if something is equal, you can ask if two things are NOT equal by using <>

Example 3: IF x <> 5 THEN x = 5

You can also ask if something is LESS-THAN or if it is MORE-THAN something by using < or > symbols.

Example 4: IF x < 5 THEN x = x + 1

What this did was ask if x is less than 5. If it is, then 1 is added to the value that x contains.

The computer does not care what the question is, or what the following statement is. It ONLY answers the question you are asking. It is up to YOU to know what question to ask, and what statement to execute IF the condition of the test is true or false.

4. the IF condition THEN statement1 ELSE statement2

Allows you to have two statements ready for the computer to execute depending on the true or false result of the test.

Example 5:

IF x = 5 THEN PRINT "X is equal to 5" ELSE PRINT "X does NOT equal 5"

Another word for ELSE would be 'otherwise'

We can also do several tests at the same time, and in several ways. We could ask

IF x <= 5 THEN PRINT "Yes, x is less than or equal to 5"

Or

IF x >= 5 THEN PRINT "Yes, x is more than or equal to 5"

One way is to ask:

Example 6:

IF x = 1 OR x = 2 THEN PRINT "X is either 1 or 2 but nothing else"

Or:

Example 7:

IF x > 5 and x < 10 THEN PRINT "X is more than 5 and less than 10"

Or:

IF x < 5 and temp$ = "Stev" THEN PRINT "Both conditions are true"
 

A simple use of tests like this is to put a timing loop in your program.

Example 8:

x = 0
[timedelay]
IF x < 1000 THEN x = x + 1: goto [timedelay]
 

And, here's the flip side - WHILE condition : statement : WEND

Example 9:

WHILE x < 5 : x = x + 1 : WEND

This tells your computer to keep checking the condition of this variable named x, and as long as its value IS less than 5 it should add 1 to its value and then turn right around and check it again. It is a conditional loop structure. If the condition x < 5 is true, add 1 and recheck, otherwise go on to the next line of code and proceed from there.

Example 10:

WHILE x < 10 : x = x + 1 : PRINT "Still counting" : WEND

Can you tell what this line will do? Try it out. If you leave out the x=x+1 part, it will run on forever telling you that it is still counting, but in fact it is only checking. This is called a continuous hanging-loop, an unfinished loop that will never end.

It doesn't matter if you put the x = x + 1 statement before or after the print statement, it just needs to be somewhere after the condition test and before the ending WEND.

WEND, in other words means When condition is true END this loop.

Example 11:

x = 0
WHILE x < 1000 : x=x+1 : WEND

This does the same thing as the [timedelay] loop above but without using bracketed target names and is quicker to write and executes faster.

I hope this has made it clearer to you. You will need to practice using these 'conditional' tests many times before it really begins to sink in, so take the time you need. Mess around with them as much as you want, study the results closely and you will discover quickly that

"There's more than one way to skin a cat."

Part 3 will continue where this one leaves off, and take us into the multi-statement-line styles of both IF...THEN ELSE and WHILE...WEND.

If time and space permit, we can delve into the mystical aspects of ...

are you ready ... conditional-branching and GOTO vs GOSUB.

Working examples and snippets will be included for you to play with.

Until next time, Stev


Another great article by Stev.

I believe this newsletter needs more articles like this. The more experience we get, the more we forget the basics. Well, we don't forget them - its just that we do them instinctively and never consider explaining them to others, even though we sufferred through trying to learn these things ourselves.

I was delighted with the feedback that you gave to Stev for his last article - and I hope to see a similar response from this one.

Thank you Stev

Coming soon to an Inbox near you:


Newsletter compiled and edited by: Brosco and Alyce.

Comments, requests or corrections: Hit 'REPLY' now!