Why BASIC?
All information herein is the view of the author. Use at your own risk, no warenty of any kind is provided.

There are many that still view BASIC as the limited cut down language that was seen on many 8-bit computers, and thus think it is a poor language to use. Structured BASIC versions have been around for a long time, even if it took till the mid 1980s for them to catch on on most systems. Herein is a look at why BASIC is a good choice for many projects, as capable as C, and with significant focus on BBC BASIC V on RISC OS.

• BASIC, Structured & Usable.
• BASIC is Meant To be Compiled.
• BASIC V : A Good Langauge.

While for a time in the late 1970s and early 1980s the BASIC most saw was the less capable version from M$, Dartmouth SBASIC has been structured at least since 1977. In the mid 1980s MS even saw the light and provided Structured BASIC implementations first for Macintosh and Amiga computers. BBC BASIC has been structured a bit longer than most others, and we are all the better for it.

Structured BASIC implementations have named procedures and functions. Most have means of making direct system calls (LIBRARY on Amiga, TRAP on Macintosh, INT86 on later DOS BASICs, etc), thus having no limit on ability. Also most structured BASICs have some way to run machine language subroutines directly.

Unfortunately the majority of structured BASICs did not have support for inderection until the late 1990s, using PEEK/POKE instead. Though BBC BASIC has supported indirection since day one, and with one of the best implementations of any language.

Also most structured BASIC implementations support multiple-module code. In most cases this requires compiled code, though BBC BASIC V does it interpreted as well.

With all the modern tendancy towards interpreted languages, it should be taken into consideration that interpreting BASIC has a long history to draw from. There are a number of good interpreters for BASIC that are quite fast, especially when considered that they are pure interpreters. Also in many cases the very fast interpreters can be used as a model to implement very fast JIT compilers for the dialect of BASIC. So why are messing areound with lanaguges that tend to be noticably slow, even when JITed?

Dartmouth BASIC is a compiled language, and the language from which all other BASICs decend. Thus BASIC was designed to be compiled.

Unfortunately many modern BASIC Interpreters implement functionality that inhibits Compilation of the code to machine lanugage. Things like EVAL are a problem, and not part of any version of the original line of BASIC from Dartmouth.

It is a good idea to take care to not use features that do not do well with compiled code, as it is likely that someday your BASIC code will get compiled. Even in RISC OS, compiling is common place, usually by means of the !ABC BASIC V Compiler.

BASIC V has all the features of a good structured procedural High Level Programming language, and thus should be looked at as a realistic option.

The big down statement made about the bad BASICs is the use of GOTO/GOSUB and spegetti code. I do not think I have ever used GOTO or GOSUB in any BASIC V program, nor can I think of a case where I have seen either used. They are not needed because we have a well structured langauge.

Some of the features of BBC BASIC V (AKA ARM BASIC) include:

• Named Procedures / Functions.
• Extended Looping Structures (WHILE, REPEAT, etc).
• Switch style multi condition structures.
• Direct System call support (SYS).
• Built in Assembler.
• Typed Variables.
• Byte, Word, String inderection operators.
• Support for modular code.
• Good error handling.
• A lot more.

The only downside is that when compiled, the FPE in RISC OS is slower than the BASIC V builtin floating point routines. Though as most code does not need floating point of any kind this issue kind of cancels itself out in most cases.

Also it is of note that many programs that use the Window Manager in RISC OS are written in BASIC V, and run interpreted. This includes many professional quality (and better hobby quality) programs. This also makes it so that there are a lot of programs that run well on modern ARMv6/7/8 RISC OS 5.xx Computers that were originally written for ARMv2 Archimedes / A-Series computers running RISC OS 2, and still run on the old systems.