In comments following Language Deathmatch: Basic vs. Logo, Johnathan Allen complained that I compared the Logo family of languages to the BASIC family of languages, rather than comparing the Logo family of languages to Small Basic. I find this odd for a number of reasons. Among them:
A family-to-family comparison is an apples-to-apples comparison.
The reason for the family-to-family comparison was to address the matter of what makes the better language family to use as the basis for a modern eduational programming language. It was inspired by Google’s announcement of its Simple language, which is based on BASIC.
For purposes of this particular case, it would see that if he wanted a comparison to a specific implementation of a particular BASIC dialect, Simple would probably be a better choice than Small Basic for getting to the meat of the matter — though that would mean waiting until Simple is more “finished”, of course. Maybe the Small Basic inclusion of a turtle graphics facility is behind the Small Basic choice, though.
Small Basic is crap, which basically just sets the BASIC descendant up for failure in such a comparison.
In the interests of honest and helpful discourse, though, and because I felt like it (having been inspired by doing some algorithm implementation comparisons between Logo, Perl, Ruby, and Scheme — a language I’m currently learning — last night), I decided to provide a comparison of Small Basic with UCBLogo. I chose UCBLogo because of my current familiarity with it and the fact it’s already installed on several computers here, to say nothing of the fact that I already wrote some code last night I could use for comparison with Small Basic today (namely, the recursive exponentiation procedure).
Without further delay, I give you Small Basic vs. UCBLogo.
I won’t belabor the point of all language features provided by one or both of Small Basic and UCBLogo. I will simply point out those that leaped out at me after playing with both languages to an extent where I understand the implied workflow of programming in each language and the general complexity management style each language demands.
In particular, I’ll skip the more advanced capabilities of UCBLogo, since Small Basic essentially has no advanced capabilities whatsoever.
Help, Intellisense, Reference
Small Basic offers “intellisense” style auto completion.
Documentation on Small Basic is exceedingly scant, and as a result there’s a possibility I may have failed to stumble across some important features that are described as being absent here. I did make a good faith effort to “discover” such features in the short time I have played with Small Basic, even when I suspected they were nonexistent, but neither the documentation nor experimentation provided any hint of the existence of such “missing” features.
Small Basic does provide an automagical “intellisense” style auto completion facility, which can be used (as I had to) to determine whether certain apabilities exist if you’re clever enough about it and know enough about what you’re doing, but for beginners it is no excuse for actual documentation or help facilities, and even for experts it is a pretty poore excuse for documentation and help facilities. Since there are no help facilities within the IDE at all, and documentation is so scant, this is a real problem. The significant variation between BASIC dialects, and this dialect in particular as it is differentiated from others, ensures that even borrowing documentation for other dialects is an exercise in frustration and futility.
Of course, this is not an indictment of the language or its core implementation, per se. There’s always the possibility that better documentation and help facilities may arise at some later time. If you want to be certain of the reference resources for your educational language of choice — particularly for right now — you’re out of luck with Small Basic, though.
UCBLogo provides a comprehensive help system.
Within the UCBLogo REPL itself is a comprehensive help system primitive command and procedure listing, with definitions of all primitives available, via
help. As such, a worst-case scenario is that you’ll have to skim the list of 340 primitives for those that look like likely candidates for what you want to do, then issue a
help foodirective to the REPL to get information about each “foo” about which you want information.
There’s no intellisense capability, and while documentation particular to UCBLogo is somewhat disorganized for reference purposes (as far as documentation I have found), it is fairly thorough, and the fact its form is substantially identical to that of other Logo dialects in terms of its core language design, other Logo dialects’ reference documentation is useful as well.
The help facility is actually a feature of the UCBLogo implementation of the Logo language itself, and this sort of help facility is in fact common to a number of different Logo implementations.
Small Basic evidently uses only global scope.
Universal global scope (aka, “no scope”) is the most obvious and, for an absolute beginner, most easily grasped manner of handling scoping rules for beginners. It is not, however, conducive to learning programming beyond the first week or so, especially since growth of program sizes beyond a couple dozen or so lines of actual working code (that is, not counting blank lines, comments, end delimiters, et cetera) becomes increasingly unmanageable without scoping to help separate concerns. This lacking feature alone limits the usefulness of Small Basic so drastically as to make it essentially useless to anyone with the desire to learn programming beyond a kindergarten level.
UCBLogo uses dynamic scope.
This is important because it effectively allows global scope and local scope “as needed”, implicitly. There are arguments for static scope as well, of course, as a superior alternative to dynamic scope. The point is that for the progress of the student’s education in programming beyond the first week or so, some kind of protected scoping mechanism is important.
Small Basic provides no facility for subroutine arguments.
The in ability to take arguments to programmer-defined subroutines is simply gross negligence in language design. The idea that all state originating from outside the code should be managed outside of the subroutine leads to some truly monstrous coding practices, such as having to explicitly alter the value of global variables maintained outside of subroutines every time you want to execute the subroutine with new values. This makes management of naturally progressing values between subroutine invocations absurdly tangled and prone to error. Speaking of errors, the Small Basic IDE actually throws an error when you try to run code that has values inside the parentheses attached to the end of a subroutine name when invoking that subroutine, confirming the absurdity of demanding delimiters for syntactic correctness while prohibiting their use to actually delimit anything.
UCBLogo allows arguments for procedures.
Procedure definitions in UCBLogo can include fairly intuitive argument specification and use.
Small Basic apparently cannot define return values for subroutines.
Compared with the universally global scope of state and the abhorrent inability to explicitly pass state into a subroutine, the fact that subroutines cannot be defined with a return value is small potatoes. Still, the lack of scoping combines with the lack of ability to return values from subroutines to contribute to an ever-mounting pile of global state that cannot even be “pretend”-separated from the rest of the program in a way that clarifies the structure of the program as a whole. An entire program must be tightly coupled in all respects, across the entire length and breadt of it, with the sole exception of external libraries (which behave more the way subroutines should, but cannot be defined by the Small Basic programmer). This state of affairs requires any changing state to be liberally sprinkled throughout the primary routine like chicken feed around the barnyard, denying any reasonable mechanism for avoiding problematic repetition. The only hope of dodging such repetition in programs beyond the very simplest examples is nesting subroutine calls and loops within subroutines and loops ad infinitum. Even then, the programmer will end up with subroutine calls and control structures repeated far more than is healthy.
UCBLogo allows explicit return values for procedures via
If anything, the specification for return values — necessary to the full range of recursive procedures, as well as definition of hygienic functions in the general case — is even more intuitive and obvious than specification of arguments.
The Small Basic and UCBLogo implementations of turtle graphics are roughly identical in terms of their core capabilities. It simply becomes a much more complex task doing some of the more interesting things a turtle graphics facility can do because of some of the above-mentioned limitations of Small Basic.
GUI Development and Other Libraries
Small Basic provides a fair bit of library support for such a tiny little toy language, notably including GUI toolkit capabilities. This allows beginner programmers to start learning about GUI development early, though it fails to get beyond the most rudimentary, “toy” GUI development.
There aren’t any libraries for UCBLogo outside of turtle graphics itself, as far as I’m aware. This hampers any GUI development urges that may arise early on in beginners, unfortunately, but the non-GUI software one can write with UCBLogo definitely scales beyond the level of a “toy”.
Overall, the case of GUI development and general library support leans in favor of Small Basic, though the learning curve is painfully short, and the actual usefulness of the libraries is debatable, minimizing what benefit it might gain from such capabilities. The library support is in essence useful for the “wow factor” and little else — other than the fact that much of the library support is dedicated to duplicating critical functionality that is provided by the core functionality of any serious languages (even serious educational languages suitable for children, such as Logo).
Note, however, that I haven’t looked into MSWLogo or FMSLogo — Microsoft Windows ports of UCBLogo with extensions particular to that platform. These may well go beyond the meager capabilities of Small Basic for both “wow factor” and actually useful library support.
Lest we forget, Small Basic comes with a substantial EULA that makes my head spin. While UCBLogo also comes with a substantial EULA that makes my head spin (it’s called the GPL), at least in the latter case I’m allowed to modify it, and even redistribute it (with or without charging) as long as I follow some very strict rules about the form of distribution, to say nothing of cross-platform compatibility and greater potential longevity, thanks to the licensing difference.
Some example code seems to be in order. I’ll provide only very short snippets intended to highlight points about the similarities and differences between the languages.
print [Hello World]
The fact that calls to external libraries are necessary even to accomplish the most simplistic program — a Hello World — in Small Basic is discouraging. As part of its “designed for beginners” goal, Small Basic has only 15 keyword primitives, but this simplicity of the core language is undermined by its reliance on external libraries whose functionality cannot even be duplicated using that core language to perform the simplest of tasks. Small Basic’s size balloons rapidly, leaving the size of the UCBLogo a small speck in its rear-view mirror, once the standard library is included in the weight of the thing. That it both gets so large in practice and does so little even with the standard library included is a sad state of affairs indeed. On a related note, Small Basic is supposedly Turing equivalent, but it achieves this only when the standard library is part of one’s evaluation.
Atomic Iterative Exponentiation
base = 3 exponent = 4 Pow() Sub Pow result = 1 For i = 1 to exponent result = result * base EndFor EndSub
to pow :base :exponent make "result 1 repeat :exponent [make "result product :result :base] output :result end pow 3 4
As you can see, there are six lines of code that do any work in the Small Basic example, and two in the UCBLogo example. The algorithm is essentially identical, but the separate global variable declarations for what would otherwise be arguments are necessitated by the shortcomings of subroutine definitions in Small Basic described above. Things get more complex and unwieldy if the programmer wants to reuse the subroutine later on.
Atomic Recursive Exponentiation
no such animal
to pow :base :exponent ifelse lessequalp :exponent 0 ~ [output 1] ~ [output product :base pow :base (difference :exponent 1)] end
While recursive operations in Small Basic are possible, atomic recursive operations (that is, recursion that doesn’t rely on outside operations in parallel to help keep track of the number of recursions) are essentially impossible in any reasonable sense thanks to the lack of programmer defined subroutine arguments and return values.
All things considered, I see this comparison as not mitigating the my Logo-friendly assessment of the comparative features of the BASIC and Logo families of languages, but rather enhancing it to a rather substantial degree. I also tend to think it’s kind of an unfair comparison, since Small Basic is in my opinion one of the worst examples of an education-appropriate variant of BASIC, whereas UCBLogo is one of the best examples of a Logo implementation. The variation between different Logo implementations tends to be rather small, however, for purposes of initial introduction to programming — with the exception of more significant departures such as LEGO Logo.
While I’m at it — I might also mention that I expanded upon Language Deathmatch: Basic vs. Logo to produce the beginnings of a WikiVS page: BASIC vs. Logo