Boyko Bantchev, 2008
True BASIC, or TB for short, is a dialect and a present-day implementation of the BASIC programming language from the authors of the original BASIC – the so called Dartmouth BASIC. Because of its pedigree, True BASIC deserves a special attention among the many incarnations of this language.
Historically, the combination of a very simple language and an interactive programming system that the original BASIC implementation offered played a huge role for making computing accessible to a much wider audience than the (then small) world of professional programmers.
Today, however, BASIC as a whole is known to ‘serious’ programming professionals as an underdeveloped, devoid of interesting features language, and a relic of the past. Despite this, I did have certain positive expectations with respect to TB. I imagined that somehow this particular kind of BASIC would prove to be indeed ‘true,’ better than its congeners by being a simple, coherent, and useful tool, with a touch of originality and elegance. After all, the creators of BASIC must have had accumulated enormous experience and wisdom in their using the language for 45 years! And where else must this wisdom have found its best expression if not in their own modern version of BASIC? However, my short investigation in TB – the language, its implementation and the way it is being presented to its audience has thoroughly disillusioned me.
The text below is highly critical to True BASIC. I do not mean to offend anyone, though, or to be disrespectful to the valuable historical contribution of its authors to computing. Perhaps I would have not written it at all if not for the exaggerated and misleading assertions and sheer untruth that I found written in praise of TB, in glaring discrepancy with the many indications of low quality of TB itself which I ran into. The text also contains some suggestions for language improvement.
1. A closer look at True BASIC
2.1. The missing Booleans
2.2. Is there MORE #0?
2.3. Possible additions to BASIC
4. Availability and credibility
I love programming languages. I love learning about them and playing with them. Some of them are intellectual revelations, others are plain, humble working tools, but there is always at least one idea in any language that makes it worth knowing about it. At times, in the process of studying a language, historical and personal facts may spring that are no less interesting than the language itself. So I try to collect information of as many programming languages as I can.
My method of studying a language includes writing a small but not completely trivial program in it. This lets me gain my own impressions of really using the language rather than just learning from a manual or a textbook what it can do. My experience tells me that there is a huge difference between these two activities – but of course the same holds of any other field of human endeavour. In fact, with every ‘new’ language I always write a solution to one and the same problem. The nature of this problem is irrelevant here, but it is such that I am forced to go through and make use of all major ingredients of the particular language: primitive datatypes, simple data structures, control structures, and I/O facilities – up to putting together a complete program that runs correctly according to the problem specification. The programming techniques used, and the size and visual appearance of the resulting programs differ wildly.
This time it was BASIC's turn. I used BASIC for the last time in 1984, on an HP 2647A – a machine of the 1970s – and that was the BASIC with line numbers, GOSUBs, one-letter-named variables and not much more. Therefore, the first thing to do was to learn what modern incarnations of BASIC offer. I.e., excluding Microsoft's Visual Basic, which is a beast of another kind.
I learned that:
Initially, I decided to solve the problem I had in mind in the de facto standard QuickBASIC, as the most representative and influential dialect of the language. (See also FreeBASIC – a modern, multiplatform BASIC conforming to and extending QB.) After I completed the program, I felt I had to redo it in True BASIC. This would provide me with the opportunity to learn how the authors of the original language saw their creation today, and in particular, what TB had to set it apart from the other BASICs. The result of my investigation can be shortly formulated as the following conclusions:
In order to learn what True BASIC was, I started by seeking information on its home page. Googling on the name also lead me to these two. There were some user-made tutorials too, scattered around the world. I wasn't able to learn much this way, though – besides constantly reassuring me that their product is ‘high-quality,’ that it is ‘ideal’ for beginners' and other uses, that it is definitely the one noble and true BASIC, etc, etc, the authors did not offer any reference material, or another kind of description, or any data whatsoever comparing TB to other BASICs or educational environments.
For learning and experimenting, I downloaded the demo implementation. The language that it implements is unrestricted, which is great for experimenting. However, experimenting turned to be the only form of learning that the TB ‘environment’ permitted: here again, there was not a single line of documentation or other aid. The TB home page, however, had a very brief reference, more like a simple enumeration of names (without descriptions), of the available commands and functions. That was all the TB publishers had to offer for no money…
By reading the documentation of Bywater BASIC, an implementation which partly fulfils the Full standard, as well as an old journal article on the BASIC standardization, I was able to get a somewhat clearer picture of what the Standard included, and therefore what to expect from TB. Asking questions on the TB forum further helped me with some details. Thus, by reading, asking and a lot of experimenting, in several days or so I learned what I needed of TB, and rewrote the program of which I mentioned above from the QB version.
In the following sections I go into more detail on what I found that I didn't like about True BASIC. The language and its implementation have their good sides, of course, but here I am focusing on the things I find bad, because they may be less obvious (a problem that has remained unnoticed or is not recognized as such is still a problem), and I consider it important that they be known and well understood. It is on the TB current or potential customers, and its designers and implementors to decide whether my criticism is useful to them.
In this part I am discussing at length perhaps rather trivial things, but I thought this is necessary in order to convince both the users and the implementors of TB in the need to act on the issues under consideration.
There are two deficiencies I spotted in the TB language that I want to discuss. Other, minor ones exist, but these two are particularly striking as examples of bad design that should have been avoided. (And actually, it is never too late to be removed.)
One thing that TB lacks is Booelan values. TB does use conditional expressions within IF, WHILE and UNTIL, but nowhere else. There are no Boolean constants or anything equivalent. It is not possible to store a Boolean value in a variable or an array element, pass it as an argument to a procedure, or return such a value from a function. In short, Booleans are not first-class citizens in TB.
Does the absence of Booleans in a language limit its applicability? Formally speaking, no – there are obvious workarounds. If we agree, e.g., to use 0 for ‘false’ and 1 for ‘true,’ we can do ‘fake Boolean algebra’ in terms of numeric algebra (see the examples below). But one can program everything in binary arithmetic and gotos as well, and we do not do that for a good reason: we want our programs to be expressed in a language that is close to the one in which we formulate the very problems that these programs solve.
Booleans are natural and essential to programming. It is not for nothing that so many programming languages have a Boolean (sometimes called ‘logical’) datatype. In fact, no other programming language that I know of – and I mean many tens of them – not even any other present-day dialect of BASIC – lacks Boolean values or some equivalent. The very first all-purpose programming language, FORTRAN, from which BASIC is said to descend, already had a LOGICAL datatype by the time BASIC was conceived. Same of Algol 60 – another well known language of that time.
Aside: It should be noted that while some programming languages have a true Boolean datatype, others (C and most versions of BASIC being examples) use arithmetic values rather than the Boolean constants true and false, but otherwise do not differ: the key property is that the results of conditional expressions are treated as values – be they false and true (Pascal, Java), 0 and 1 (C), or 0 and -1 (BASICs). Not having true Boolean constants erodes the clear separation between datatypes, but makes possible a certain amount of blending between numeric and Boolean arithmetics, which turns out to be enhancing the expressiveness of both.
Having Booleans as values allows one to:
Why then TB is equipped with dynamically sized strings and arrays, with lots of built-in operators and functions to work on them, with modular programming facilities etc, but does not recognize the importance of Booleans? Because they are a too complex thing for beginners and laymen (the expected primary audience of TB) to deal with? Or because they can be imitated through number arithmetic?
Neither of the above seems a serious argument. Boolean algebra is not hard. It has deep roots in our thinking. As for having to deal with Boolean variables and expressions, how is that more difficult than it is with numbers? And if one cannot put up with simple logic, how is he supposed to program at all? Imitating logical calculus through number arithmetic, on the other hand, should be far more difficult to the inexperienced programmers, obscures the program by cluttering it up with irrelevant detail, and is prone to errors. It also depends on certain conventions which should be kept strictly, and that is once more a source of errors.
How can the following observation be explained? In programming tutorials and other teaching and learning aids in True BASIC one never finds problems that involve logic. Summing-up numbers, finding averages etc, and often even simple text processing are welcome, but not logic. How so? Is logic unimportant for those that would program in TB? Technical professions aside, I'd venture saying that, e.g., a philosopher does need to understand logic. Everybody does, or we all are in trouble. My answer to the observation I made is that one does not find problems where logic is (explicitly) involved because TB makes logical calculations difficult.
As an example, let us solve the following problem: write a program to check the validity of a certain Boolean formula, say
NOT (a AND b) = (NOT a) OR (NOT b), for arbitrary Boolean a and b (one of the De Morgan's laws). Discovering the laws of logic by program-aided experimenting certainly has educational value, and the proposed problem is one example of such kind of programming. Let’s see how easy it is to solve the problem in TB.
Since the formula must hold for any Boolean pair a, b, it is only true if it holds for all such pairs. If Booleans were first-class values in TB, I'd write a function such as:
FUNCTION testformula DEF FNdm(a,b) = NOT (a AND b) = NOT a OR NOT b LET r1 = FNdm(false,false) LET r2 = FNdm(false,true) LET r3 = FNdm(true,false) LET r4 = FNdm(true,true) LET testformula = r1 AND r2 AND r3 AND r4 END FUNCTION
and call it by saying
PRINT testformula. The main function calls FNdm for all possible arguments and forms the result by ANDing. FNdm implements the De Morgan formula itself. Simple and straightforward! (Even better if we could instruct testformula which function to test by passiing the name of the latter – in this case
FNdm – as a parameter to testformula. This way, testformula would be able to check the validity of any two-argument formula.)
Now let's rewrite this in true True BASIC, assuming 0 for false and 1 for true:
FUNCTION dm(a,b) IF NOT (a=1 AND b=1) THEN LET x = 1 ELSE LET x = 0 END IF IF a=0 OR b=0 THEN LET y = 1 ELSE LET y = 0 END IF IF x=y THEN LET dm = 1 ELSE LET dm = 0 END IF END FUNCTION FUNCTION testformula DECLARE FUNCTION dm LET r1 = dm(0,0) LET r2 = dm(0,1) LET r3 = dm(1,0) LET r4 = dm(1,1) IF r1=1 AND r2=1 AND r3=1 AND r4=1 THEN LET testformula = 1 ELSE LET testformula = 0 END IF END FUNCTION
Using a straightforward, one-line formula for
dm is now impossible, let alone making it local to
testformula. We were forced to write a much longer function, whose intent and logic is neither easily grasped nor checked mentally. What if we had a more complicated formula to prove? The task would have then turned rather more challenging. How many students would have done the exercise right, and how much time would have this taken them?
Moreover, pay attention that we have to simulate the Boolean constants
true wherever a Boolean value is needed, and in our case that makes 24 places! Whereas, with the truly Boolean solution, we have only 8
falses. All this handling of 0s and 1s is prone to errors. And again, what if we had a more complex formula to prove?
Note also that we have mentally translated the two negations in the expression
(NOT a) OR (NOT b) into checking against 0 in place of 1, so we obtain
(x=0) OR (b=0). Had we not done that, we would have arrived at the heavier expression
(NOT a=1) OR (NOT b=1).
Even with 0s and 1s, we can do much better, but we need to do some preparatory work to achieve that. Let
y be such pseudo-Booleans, each one 0 or 1. Then
1-x can be used for ‘NOT x,’
MIN(x,y) for ‘x AND y,’ and
MAX(x,y) for ‘x OR y.’ In addition,
x=y can be expressed as, e.g.,
With this in mind, we arrive at the following program:
DEF FNnot(x) = 1-x DEF FNand(x,y) = x*y DEF FNor(x,y) = MAX(x,y) DEF FNeq(x,y) = 1-ABS(x-y) FUNCTION testformula DECLARE FUNCTION FNnot, FNand, FNor, FNeq DEF FNdm(a,b) = FNeq(FNnot(FNand(a,b)),FNor(FNnot(a),FNnot(b))) LET r1 = FNdm(0,0) LET r2 = FNdm(0,1) LET r3 = FNdm(1,0) LET r4 = FNdm(1,1) LET testformula = r1*r2*r3*r4 END FUNCTION
which is almost as short as if we had used true Booleans, but hardly as clear. And we will have to repeat the definitions of
FNeq in every program where we need Booleans. If we need to fake by 0/1 the Boolean result of other comparisons, such as < and >, more work is required.
In the end, rather than duplicating all Boolean-valued operators, which are anyway present in the language but their results are not accessible as values, is it not much better to remove this limitation and have true Booleans?
To conclude: Booleans are an essential domain of discourse in programming, hardly less fundamental than numbers. By not providing Boolean values, True BASIC ignores that domain. But omitting fundamental means of expression in a language makes it fundamentally limited.
Note: The above rather long and detailed discussion of Booleans is justified by them being, apparently, a completely unknown concept to True Basic programmers. When I posed a question about Boolean values on the TB forum, two my correspondents insisted that TB does have them and even Boolean variables!
Another annoying part of TB that I ran into is its standard I/O window. This is really more an issue with the implementation than with the language, but it is of such nature that prevents writing a certain class of programs – a large and useful class – and forces bad programming practices. For this reason I discuss it here.
The standard I/O window is where the output from the program is printed, and where you enter data from the keyboard if you use the usual means for printing and reading, such as PRINT and INPUT. In Unix or DOS, this would be the console, and because TB is a Windows program, it uses this window, so in order to use uniform terms let us call it ‘the TB console’ – it works just the same way. Well, almost…
In Unix, while running a program in the console, one can press Ctrl-D on the keyboard to tell the program that there is no more input. Supposedly, there are some means available to the program – perhaps a function call but that depends on the language in which it is written – through which it can check whether there is more to read or the input stream is ended. Thus the program can read just as much data as is available in the particular run, without having to know in advance the amount that will be available. This is precisely as if it reads a file: regarding input, the console acts as a file, with the Ctrl-D signifying the end-of-file condition. There is an additional benefit of this likeness: by redirecting the program input to a disk file, the program – without changing it – will indeed read that file, including it will know without user intervention when the file ends; the end of the file is known by its size.
The same mechanism works in MS DOS, only one ‘types’ Ctrl-Z rather than Ctrl-D.
How does TB handle this? As I was told in the TB forum, there is the
MORE #n condition that checks whether the channel n has more data available. A channel is an integer denoting an open file, and the value 0 is reserved for the console which is considered to be always open.
So all is OK, I can construct my program in TB so that it reads data from the console until there is available data. I have to write e.g.
DO WHILE MORE #0, then read by, say,
LINE INPUT #0, s$ and I am done. Except that there is no way in the ‘console’ to send the end-of-data signal to the program. The TB console neither pays attention if I press Ctrl-Z, nor provides any other means to the same effect. My program is doomed to run forever or be terminated by external force.
But is this omission really important? Are there so many problems whose proper solution will be obstructed by it. There are indeed. A typical example is reading a sequence of numbers in order to find their sum, or average, or other characteristic, or to sort them. Or, we may read a text in order simply to find out how many lines there are in it, or extract some data and store it elsewhere or print it. Sometimes we only need to read, say, either one or two lines, but we cannot know in advance how many. Put shortly, reading an unknown amount of data is a rather typical situation in programming.
Confronted with examples of this kind, what do people do in TB? Looking at a programming tutorial, one inevitably finds ‘inventive’ solutions. A program that has to read a series of numbers, instead of simply doing that until no more possible may first ask for how many the numbers are. Or, after reading each number, it would ask whether there will be more numbers to enter, and proceed according to the answer. These are two ways in which the impossibility to simply check for end of data is circumvented by introducing in the program additional actions, irrelevant to the problem. The original problem is clearly distorted to fit the inadequacy of the tool. And when such ‘ingenious’ techniques are being taught, it is not just an isolated hack – it is already an unfit education!
Unlike what those awry programs want me to do, my pocket calculator operates intelligently. I can enter a series of numbers in its ‘statistic’ mode without a single redundant action. But the same pattern shows up in many other areas. In order to walk to the end of a street, one usually doesn't first ask how long that street is, and does not stop after each step he makes to ask himself, ‘Shall I walk further?’. One just walks until he reaches the end.
The above described degenerate treatment of the console input by TB is in contrast to reading from files. One can perfectly well read up to the end of a file, of course. This is one more reason to rectify the degeneracy.
The programming systems of some other languages also, like TB, place the ‘console’ in a graphical window. Two examples are the GUI of the Factor language and that of DrScheme (an implementation of the Scheme language widely used in education). The former accepts Ctrl-D (or Ctrl-Z) like a real console, and the latter has a special visual button EOF (end of file), which, when clicked, sends the same signal as if it was Ctrl-D/Ctrl-Z. Why not adopt any of these solutions in TB?
That BASIC is an old language does not necessarily imply that it needs changes in order to be up to date. On the other hand, haughtiness with respect to accepting the need to change is a sure way to oblivion. I believe that a couple of things can be added to BASIC without changing its character and philosophy that would make it more expressive and programming in it easier. These additions are nothing new in programming and their usefulness is well-tried. I am convinced that it is the more important to have them in a language when it is used in education.
–1– Number one is in fact not a language construct at all, and is present in many other dialects of BASIC. I am talking about permitting multiple statements to be joined together in a line. There are lots of cases where two or more actions belong together and it is better not to separate them, both to accentuate their coherence and to avoid wasting vertical space in the program. Today, TB is the sole programming language that won't let the programmer do that.
In QuickBASIC and other BASIC dialects the colon character (
:) is used as a statement separator. This makes possible to write e.g.:
LET a = 1 : LET b = 2 : LET c = 3 REM do some processing on a, b, c …or
SELECT CASE direction$ CASE "L" : LET x = x-1 CASE "R" : LET x = x+1 CASE "U" : LET y = y+1 CASE "D" : LET y = y-1 END SELECT
I find the above examples much better readable than the one-line-one-statement alternative.
Eventually, it is up to programmers to choose whether and when to use a feature. There is an enormous amount of evidence that they do not abuse this particular one, whatever language one has in mind. Then why the restriction?
–2– Another useful construct is the simultaneous assignment, where the values to be assigned are computed independently of each other before the assignments take place. It is perfect for swapping the values of two variables, or shuffling three or more such, and also in other cases where simultaneity of several assignments is important. Without it, one has to introduce temporary variables, and is more easy to make an error.
Let us denote a simultaneous assignment by
MLET. Several examples follow.
MLET x,y = xorg,yorg MLET surnm$,first$,second$ = "Smith","John","William" REM pretending ++ is a line continuation mark: MLET x,y = cos(a)*x-sin(a)*y, ++ sin(a)*x+cos(a)*y
In the first two examples the simultaneous assignment is merely an option that, as with the multiple-instruction lines above, makes it possible to express certain coherence. In the third example, if the assignment was not simultaneous, we woud have to write something like:
LET x1 = cos(a)*x-sin(a)*y LET y1 = sin(a)*x+cos(a)*y LET x = x1 LET y = y1
Technically speaking, one temporary variable and three assignments would suffice here, but at the expense of less clear code. The variant with the simultaneous assignment is better than any of the other two options.
Another example – a program that arranges three different numbers in ascending order, a<b<c, by exchanging their values as necessary:
IF a<b AND a<c THEN IF c<b THEN MLET b,c = c,b ELSE IF b<a AND b<c THEN IF a<c THEN MLET a,b = b,a ELSE MLET a,b,c = b,c,a ELSE IF a<b THEN MLET a,b,c = c,a,b ELSE MLET a,c = c,a END IF
Try writing the same in true TB. Implementing a similar logic results in a program four times the size of the above and much less readable! And this for a very simple programming problem…
Note. A somewhat different approach leads to the following program that also arranges the numbers in ascending order:DO WHILE a>b OR b>c IF a>b THEN LET t = a LET a = b LET b = t ELSE LET t = b LET b = c LET c = t END IF LOOP
or, in TB extended with simultaneous assignment:DO WHILE a>b OR b>c IF a>b THEN MLET a,b = b,a ELSE MLET b,c = c,b LOOP
In terms of program length, this aproach is to be preferred. However, now the program may have to do more exchanges than actually necessary. Consider e.g. a=3, b=2, c=1: the exchanges are a-b, b-c, and again a-b, while exchanging just a-c suffices, and that is what our initial program does.
–3– A very useful data structuring concept is that of tuples. A tuple is a short sequence of values, not necessarily of the same datatype, that is treated as one value, and as such can be named, passed as argument, or returned as a function value. Tuples are known from a number of programming languages, and are currently being introduced to others. There is no reason why they cannot be added to BASIC.
All examples of multiple assignment that we gave can be reformulated in terms of single assignments of tuple values, where the left-hand side of such an assignment is either a single name or a name tuple.
Tuples are a more general construct than simultaneous assignments by letting one keep together two or more values that are considered to belong together, such as the two roots of a quadratic equation, the name(s) and the age of a person, etc. For example, one could say:
LET (name$,surname$,age) = ("John","Smith",23)
LET person = ("John","Smith",23)
and then, later on:
LET (name$,surname$,age) = person
to a similar effect.
On the other hand, introducing simultaneous assignment implies a smaller change to the language than introducing tuples.
–4– Failing to initialize a variable is a common programming error. Trying to use the value of a non-initialized variable can lead to unpredictable results and is a hard to hunt error. The best thing to do with such kind of error is prevent it by detecting and reporting its instances. This is a great help for programmers, especially proper for beginners and laymen.
A number of other small modifications and extensions can be proposed, but a detailed listing is not my purpose here.
Why TB has to open so many different windows in a single working session? One for editing, another for issuing commands, yet another for errors, and yet others for the result of compiling and for interaction between the user and his running program. This is confusing and tiring, let alone so much unusual for the average computer user. And, as I am going to show further on, other inconveniences arise from the separation between several windows. How did the TB developers decide on this particular interface design? Did they ask anyone, or look at other programming systems before they did it, or did they ask their users for feedback after they released the TB system?
Here is an illustration to what I said, one that strikes one's eye right after one starts the TB program. The command window is sooooo far below the text window, and for what reason? And what is the reason for keeping these two windows different at all?
Another example. The text cursor blinks in the text window, but TB does not permit one to type there, because ‘the focus’ is not possessed by this window. This happens after the compiler reports some errors – it not only opens a new window to display the error messages but also gives it ‘the focus.’ This is of course confusing. In all other programs I have ever used, the cursor remains still, or is not displayed at all, in a window that doesn't possess the focus.
The TB IDE is not only inconvenient, tiring and confusing, but also has a good collection of bugs. Some of them are easily reproducible, others not. I have seen the system stalled a number of times, making it impossible to type anything anywhere. I am unable to say what causes TB these autistic fits, but no, it is not the end of the 15 minute demo session period.
The following is an obvious and reproducible bug. In the Run menu, just below the Do Lower entry, there follows a complete listing of the directory where TB resides. What for? Who wanted that?
Now enjoy the following experiment. Open the True BASIC program, select New for editing anonymous text, then Compile from the Run menu. Yes, it compiles! And, in addition, to get rid of the result of the ‘compilation,’ you'll have to go through a joyful process that I am going to describe later on. Or, you may choose to save your compiled program: a nice tiny file, precisely zero bytes in size, instantly delivered to a destination folder of your choice.
Try another experiment. Open afresh the True BASIC program and select New. Now select Do Lower or Do Upper from the Run menu. What you get is the message ‘Paragraph out of range for GET LINE. 553 in tc_get,5799 in source_window_doconvcase in conv_case,5762 in source_window_doconvcase,808 in handle_menu_event,296 in Main program.’ Amused? Of course, this would not happen had you first done Run-Do Format on that non-existent program… Apparently, TB has three different responses to a user doing something with a non-existent program. First is do nothing, pretending nothing has happened, second is display a horrifying error message (obviously not directed to the user), and – this happens when you ‘Run’ the vacuum – display another friendly message, ‘No main program. (-556) 553 in tc_get,6141 in setshadowundorange,’ again having nothing to do with the user. By the way, note that, according to the latter message, it is the main program that is missing, not the program as such.
Never does TB care to warn the user about acting on a program that doesn't exist, or to simply prevent him/her from doing so by disabling the corresponding menu items.
But let's go further.
When I instruct TB to compile a program, TB is always first asking me whether I want to save it. Why? I see no immediate danger of losing the text, as I am not exiting the program, just compiling.
After a successful compilation, a new window pops up just to let me know the compilation was successful. This window is identical to the text window, except the former keeps the invaluable message ‘(Compiled program.)’ rather than my source. It even pretends to be the editor window by helpfully displaying the current coordinates of a text cursor which I cannot see but which I can position within the said message that cannot be changed anyway!
Now, since the compilation window happens to completely hide my source, I have to move it somewhere else, or best of all close it. Closing it, however, is a challenge. I cannot File-Exit that window without exiting the whole TB system (which is hardly what I want to do right after I have successfully compiled). TB does not object though if I close the window through Alt-F4 or reach for the mouse and chase that little red button in the upper right corner… (why TB regards differently this method of closing a window is another mistery to ponder on). But hey, there is more to do: I have not yet succeeded in closing the window. Now I am required to say whether I want to keep the compiled file or discard it – another mouse click or two key strokes to say ‘no’. So many work just to get back to my source after it compiled ok!
A few words about the TB program editor. Being very crude, with only the very basic text editing capabilities, it can be considered a version of Notepad. Similar to the latter, it won't (in MS Windows) read correctly text files in Unix or Mac file formats (where line ends are different than in DOS/Windows). Syntax colouring, autoindenting, autocompletion, etc are luxuries unheard of in TB. And that in the age when these things have been available for decades not only in all other programming environments, but also in many general-purpose text editors!
To be fair to Notepad, in some respects it is better: it can read Unicode and knows what the mouse wheel is for. The TB editor is patriotic enough to ignore the existence of Unicode (it even has problems with the ordinary encodings) and won't scroll just because you fancy to be playing with a bizarre contraption such as a mouse wheel.
I want to leave the bugs-and-inconveniences subject in a more positive tone, so here is a bug that brings some benefit to the user. I was wondering, how would TB react to a non-initialized variable, so I entered the program:
print a end
I got the number 0 printed, which is of course a wrong behaviour, if not an outright error: using the value of a non-initialized variable should be at least warned. But – keep your breath – entering the very similar program
print a$ end
granted me access to the immediate mode of the system (that is otherwise absent in the Bronze Demo)! This bug turns to be such a nice present from the developers, but why is the immediate mode prohibited at all in the first place?
How does one assess the availability of a programming language for what the language was designed?
There are a number of things to consider: the language itself, its implementations(s) and other accompanying software, support on different operating systems, program libraries, documentation, textbooks and other literature, user community, ability to use the given language in combination with others, price, etc.
I have already discussed at some length some issues with TB as a language and its implementation (based on the Demo version). Here I want to bring attention to other issues concerning its availability.
True BASIC seems overpriced to me. Its Gold version is $500, which is by far the most expensive commercially available BASIC I've stumbled upon. And let us not forget that there are excellent implementations of BASIC which are completely free.
Indeed, there are less expensive variants of TB: the so called Student, Bronze, and Silver. The Silver is said to be ‘the entry-level-developer version’ and costs $200, which equals the highest price among all other commercial BASICs that I know of. (Silver and Gold seem to offer the same language but differ by adding application libraries, documentation, and the ability to create stand-alone executables.)
Perhaps one can be content with Student or Bronze, which are significantly less expensive? Not so, as it turns out: it has been reported in the TB forum that the documentation which comes with the versions below Silver is very incomplete regarding the language, and the built-in functions in particular. Therefore, I would formulate the trading policy of the TB publishers to be the following: one is not permitted to actually understand what in the world is True BASIC until it becomes a ‘developer,’ i.e. before it pays $200 or $500. And TB, its authors insist, is a programming language and environment especially designed for education! Even if one ignores all the inadequaces, immaturity and bugs that I discussed in the previous sections, assuming that TB is the very embodiment of perfection, what justifies forcing teachers and students to buy a ‘developer’ version?
Moreover, how is one supposed to decide whether it is worth purchasing anything without knowing what it is that he pays for? Remember, the Demo version comes with neither documentation nor example programs whatsoever included!
I strongly believe that it would be much more acceptable if the TB publisher imposed higher charging for more functionality in the form of additional libraries and other accompanying software such as GUI builders, program transformers etc, or for language/implementation extensions such as modular organization of programs and the ability to compile large user programs. Extensive supply of teaching materials and learning aids is another direction where extra charging is reasonable. But the documentation, or at least significant part of it, should be available to anybody for free. Even more so in view of the existence of numerous other BASIC dialects – more open, less expensive, and some of them free.
By the way, I wonder why the TB manual has to be 640-660 pages in volume, which is the size of a bloated book on a bloated language such as Java. Was BASIC not supposed to be the simple language that anyone would start using in no time?
There are other issues regarding TB's inadequate availability, also related to the lack of information. The TB web site has no search facility. In particular, although on the forum one finds helpful people, the archive cannot be searched. Whatever posted, it gets buried forever, instead of being available, unless of course one reads all messages! I guess some topics are going to be raised over and over again…
As the TB system itself, the web site does not offer any teacher's or learner's aids, such as e.g. tutorials, let alone something the size of a textbook, from the publisher. In fact, nothing of this kind at all. As has been mentioned above, there are just a few TB tutorials on other websites, having nothing to do with the TB publisher, and these tutorials are rather limited in scope, and aging.
Also unknown remains how TB compares to other BASIC dialects. How is it better as a language, or as a set of library functions, or as a programming system, or otherwise, if it is at all?
Further still, how does TB stack up against non-BASIC alternatives in the realm of educational programming software? I mean systems such as e.g. DrScheme, Helium, Vital, StarLogo, MSWLogo, Elica. Do the TB developers pay attention to the outside world?
The rather intensive but unsupported extolling of the virtues of True BASIC on its web site hardly builds credibility in the user's mind, especially when confronted to the many very real problems with the language, its implementation and recognition among other BASICs. Despite expressions such as:
‘…a general-purpose language, allowing for the writing of any type of program…,’
‘…a high-quality BASIC, one that reflected our years of teaching experience…’,
‘…the world's best programming language…’
(note – not even ‘best educational’ but simply ‘best’!)
somehow I do not feel convinced to become a TB fan for life. For example, what evidence supports the first of the above assertions? An impressive list of language features? Extensive use? Example programs? And I have never seen written, and never understood myself, for what virtues and in what respects True BASIC shall be considered better than the rest of BASICs. Nor there is any evidence or study that would show why BASIC, and TB in particular, is the high-quality educational language which it is presented to the audience to be.
How popular is True BASIC actually?
If TB is being used in more than 8400 schools and colleges (as asserted on the web site), why is its discussion forum so sparsely inhabited? Posts are rare, with only a few people actually participating. And how come the ‘Polls’ section of the web site is so scantly attended? With a total of 16 votes, it is hardly representative of public opinion, for any meaning of the word ‘public.’ Or is it that the many tens of thousands of TB users are so contented with the product that they feel no need to discuss it or to propose improvements?
Here are another two quotes from the TB web site:
‘Today we continue to support all the popular operating systems. A new Linux edition of True BASIC is coming and that gives us unmatched coverage in the industry.’
‘…continuing to make sure that True BASIC works on new operating systems is part of our charter.’
That has been said in 1999. In reality, there is still no Linux version of True BASIC today. There is no version for Mac OS X either. The ‘unmatched coverage’ of ‘all the popular operating systems’ by TB only includes (underdeveloped and buggy) versions for Windows and obsolete Mac OSes.
And the following two assertions, also from 1999, I leave without qualification. You figure out for yourself whether they were true then, and whether they are now:
‘Programs written in True BASIC can be run, without change, on more operating systems than any other programming language. True BASIC runs on more operating systems than any other programming language.’
‘…it is estimated that more than 75% of all programs now in use are written in BASIC.’
BASIC is surely not the ideal language (and needs not to be one), but at least a number of other implementations are really well developed, cross-platform, complete with documentation, and free. In addition, there are many other programming languages to choose from for whatever purpose one would use a BASIC: highly expressive, really well-thought and useful tools, some of them amazingly elegant – a pleasure to study and work in. As I see it, there is not a single reason to choose True BASIC, even if it were available for free.