Myths About BASIC

[kevin]

Myths About BASIC:

Document Revision: V0.02

Q. What is this ?  

      A.  This tutorial (in the form of an FAQ) is to help address some the pseudo facts (MYTHS) that perpetuate about BASIC over the decades.   While some of stuff was true once, it's false today.  

      Please note: These are in no particular order..



Q.  GOTO is fastest way to change control !

      A.   False.  In the majority of old school BASIC implementations,  programmers relied upon GOTO heavily.  It was the main construct to redirect execution in many of those old editions of BASIC (1980's ->1970's).   Decades on, virtually all modern structured BASIC implementations, feature various loop and control change mechanisms to negate the need for GOTO.   However,  given that GOTO was the fastest (and often only) way to change control in old days, many old schools users still take this a fact today.  It isn't.  


         Related Article: Should I use GOTO in my programs ?



Q.  White Space / Blank Lines Between Code Slow Program Execution Down!

      A.   False.  This is another of the Myths that stems of the classic BASIC interpreter period (1970's to late 1980's / early 90's) period.   During this period it was uncommon for BASIC programs to be translated into machine native.  Therefore many dialects of BASIC would execute code from either a tokenized form or even purely text form.    Meaning that program execution could indeed be affected by the how the source code was spaced out.

         Today, this is 99.999% FALSE.  The majority of the modern BASIC dialects either compile to Native Machine code or compile to a VM.   In both forms white spaces (spaces/tabs etc) and blanks lines are completely irrelevant.   That is to say, the spacing between code, makes no difference to the what the compiler produces.  So execution is the same, with or without spaces/tabs between commands.



Q.  BASIC isn't fast enough for writing games

      A.   This stems from the continued idea that any language based upon the BASIC dialect, must somehow always mean interrupted.   Which today is largely False.   The majority of BASIC languages today are either compiled to native machine code, or  compiled to run on a dedicated Virtual Machines.    
   


Q.  But BASIC compilers are too slow and don't optimize code ?

      A.   Yes & No.  Like much of these debates, these types of statements is based upon a generalization.    It's true, some  BASIC compilers that have some horrific compile times (one major gaming one on the PC can be bad as less than 100 lines per second), and yes  many BASIC compilers don't feature the same level as optimzation as some of the more established compilers (C, Pascal).   But there are also many that now do.

           In terms of PlayBASIC this is a none issue.  For us, reducing the compile time has been something we've focused upon from the get go. Today it's routinely able to build around 9,000 lines per second on average.    The compile pass also includes two primary optimizers.  The first is general expression level optimizations, which include constant expression redundancies  and some opcode level redundancies, the second is Type /Array caching, which dramatically reduces the cost of accessing the same structure sequentially.      These operations allow the compiler to produce more much efficient opcode streams from user code.    Yes.. We could do more.. but these allow programmers a harness anything from a a few % up to 10/30% (or more) on depending upon the algorithm.  


          Related Article:

             PlayBASIC To DLL Development Blog - Convert PlayBASIC bytecode to optimized machine code



Q.  I can make games in BASIC ?,   I thought all games were written in C/C++ today ?

      A.   This old chestnut has been rehashed and rehashed again and again over the years, and basically stems from the same old 'language / platform'  bias (my dialect is better than your dialect, my platform is better than your platform) that was once aimed at C/C++ back in the Assembly days.

            The majority of commercial / indie games written the 1980->1990's for example (8bit / 16bit platforms ) were generally either written in the machines native BASIC and/or Machine Language/Assembly during this period.    The uptake of C/C++ didn't really have any great impact until C compilers improved and 'portability'  became the issue across 32bit platforms in the mid 1990's.

            During this period, C/C++ was indeed the dominant language of choice.  So it comes as no great surprise that's still commonly perceived as being the only language used to write games today.   But as time goes on, this has become more and more a red herring.  Not just in the Indie (bed room coder)  scene, but in large scale game development (triple AAA commercial releases), which rely more on scripting and high level languages today than ever before.   Interestingly, given the size and complexity of the modern games, developers routinely choose to use scripting dialects and high level languages to develop the actual game logic in, rather than pure C/C++.   Why ? -  It's easier.    
 
            As time goes on though, the need to use low level languages such as C/C++ (and assembly before that) is slowly but surely being eroded.   In the old days, we had to use C/C++ or assembly namely for performance reasons, there wasn't an option.  Today, the choice is fast becoming a personal one.   As modern high level languages are steadily becoming just as powerful in terms of language flexibilities, performance and 3rd party libraries support (GFX, Sound etc, AI, Physics).   Not to mention, the cross platform adoption rate is constantly improving.

            C/C++ won't ever die, it's too well ingrained.  But the idea that you have to learn C/C++ in order to write a game today, is completely false !  
   


Q.  Isn't BASIC just stepping stone to learning a real language ?

      A.   Define real language ? - The stigma of BASIC hangs on to this day, to the point where some BASIC dialects have dropped the 'basic" from their name entirely.   For many established programmers, BASIC was indeed a likely stepping stone to learning lower level dialects such as C/C++/Pascal/Assembly etc.   This is true,  but we have to put such things into context.    Often what we want to get out of programming, guides our programming language choices.    For example, If you want to make web games, then learning Action Script/Java are some obvious path ways, if you wanted to write OS'es or low level libraries then Assembly/C/C++ etc is a likely path.  

           Personally,  I starting learning BASIC programming  way back in the 8bit days (1982/1983) and moved onto 6502 Assembly soon after.   The reasoning was performance related back then,  the things I wanted to do (Make Video Games) were just beyond me from a purely BASIC environment.   Given the choice today, I can't imagine taking that same path.   We're now so spoiled for options in terms of programming languages and combined with the performance of modern hardware, you can write video games in virtually any language, BASIC or otherwise.   So the absolute need to jump into assembly just isn't there.  Now I find myself picking the best language in order to get a result .    
 
           Going beyond working out what you want to achieve,  Learning to program is more than just learning the syntax of a language.  The syntax is often the least important thing we need to grasp, in particular when jumping from a high level language into a low level one.  As without some sound understand of programming principals,  jumping ship prematurely will more often result in failure.   So if you decide you need to move, then make sure you're completely understanding your current language first, it'll made picking up others easier in the long run.  The more you do this, the more comfortable moving between dialects becomes.  Good luck !

Return To PlayBASIC Tutorial Index