Chad Perrin: SOB

3 August 2009

Language Deathmatch: Small Basic vs. UCBLogo

Filed under: Geek,Liberty — apotheon @ 11:24

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.

Feature Parity

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 foo directive 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.

Scoping
  • 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.

Arguments
  • 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.

Return Values
  • 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 output.

    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.

Turtle Graphics

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.

Licensing

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.

Example Code

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.

Hello World

Small Basic:

TextWindow.WriteLine("Hello World")

UCBLogo:

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

Small Basic:

base = 3
exponent = 4

Pow()

Sub Pow
  result = 1
  For i = 1 to exponent
    result = result * base
  EndFor
EndSub

UCBLogo:

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

Small Basic:

no such animal

UCBLogo:

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.

Conclusion

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.

Note

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

8 Comments

  1. […] I’ve also written Language Deathmatch: Small Basic vs. UCBLogo, for those who are interested in my take on such an implementation vs. implementation […]

    Pingback by Chad Perrin: SOB » Language Deathmatch: Basic vs. Logo — 3 August 2009 @ 01:43

  2. Great article – you might also like to try comparing SmallBASIC – cheers Chris

    Comment by chris — 3 August 2009 @ 11:04

  3. One small point… assuming that the “Small BASIC” you looked at is the one Microsoft recently put out, I am fairly certain that it is not at a “version 1” release yet, which would explain the poor documentation (although “version 1” status is hardly a guarantee of good documentation).

    J.Ja

    Comment by Justin James — 4 August 2009 @ 10:18

  4. Point taken. Of course, that’s why I mentioned the possibility that documentation might get better.

    Comment by apotheon — 4 August 2009 @ 11:27

  5. The documentation from Microsoft is so hit or miss. Some of it (like the Code Contracts for .NET) is top flight. Some of it (Parallel Extensions Library) is awful (oddly enough, those tems literally sit across the hall from each other). And in some cases (F#) is is virtually non-existant. I don’t get how they have been building up F# for years as a big deal (it’s shipping in.NET 4/Visual Studio 2010 as an item on parity with C# and VB.NET) with its current level of documentation. All that is really out there are a few books which are aimed at the scientific/academic community. Given that F# may very well be the best/only hope in, oh, 20 – 30 years of getting the typical developer for Windows to take a look at functional programming, I want to see it succeed! Huge digression in topic. :)

    J.Ja

    Comment by Justin James — 4 August 2009 @ 11:33

  6. Funny you should mention F#. I started noticing F# books at Barnes & Noble, and lamented the fact that what amounts to a proprietary, platform-bound variant of OCaml that depends on a specific set of libraries and vertically integrated vendor stack of dev tools somehow warrants more attention for programming texts than OCaml itself. That’s especially frustrating considering that OCaml texts would be useful for F# developers (if they could get over their NIH snobbery long enough to read them), but F# texts are largely useless to OCaml developers.

    The only actual OCaml book I’ve ever run across in English (and, sadly, I got it in the hopes it would be at least mediocre) is Practical Objective Caml. That book is a heap of crap. All we really have in English for OCaml is a small handful of online “books” — two or three of them, as far as I’m aware — and some half-baked “tutorials”. I can’t even read a complete specification for the language, because it’s a reference implementation defined language, which is fine when there’s a bunch of good documentation, but not so fine when the situation is more like OCaml’s.

    Bah.

    If you think things are bad for F# documentation, try comparing them to its more portable, more performant and efficient, more flexible parent.

    I think F# is great, as a way to introduce the mass of provincial Microsoft and Visual Studio addicts to something new (to them) and interesting, in much the same way Gaim/Pidgin, Firefox, and Thunderbird have helped introduce a bunch of Microsoft Windows addicts to open source software. I’m just frustrated because I don’t need the Microsoft introduction, and would really like to be able to get a better (actual, physical, hardcopy) book for OCaml than that garbage I have. My only consolation is that the book was a gift, so it cost someone I like a bunch of money instead of costing me a bunch of money. Not much consolation.

    At least F# is making some progress, anyway, even if it’s not at lightspeed.

    Comment by apotheon — 4 August 2009 @ 01:10

  7. I think that OCaml has definitely suffered due to its sponsor (likewise, I think Zend has hurt PHP, and Sun isn’t helping Java much either, its succeeding despite Sun’s best efforts…). The lack of English books is definitely attributable to the fact that it’s not seen as having a future in the US. But you’re right, lots of F# books. That’s because with Microsoft behind it, publishers see enough potential interest to justify a book or two about it, even if the market won’t actually be using it yet.

    From my limited F# experiences, I was not thrilled with it on many levels. I liked the language itself. But it had no way of interfacing with the OS save for calls to the .NET Framework. And unfortunately, that was a mess because everything needed to be typecast in a very clumsy way. It was (if I recall) having to use F#’s casts on .NET objects that I would call casting methods on. Something like:

    let user_menu_choice = to_i Console.Readline();
    

    I’m not sure if that is the right syntax or not. But it was really clumsy. Plus, the .NET calls felt REALLY out of place. It was like watching an interesting movie, but the boom microsoft kept entering the frame and you could faintly hear the director in the background. Totally ruined the submersive effect of being in a functional language.

    If someone got me a horrible book, I’d be even more angry than if I bought it. When I buy a book, I can really evaluate it. It’s pretty rare that a book I buy with my own money turns out to be awful (the same cannot be said for books bought on the company credit card, or sent to me as review copies). But when someone gets me a book as a gift, and it stinks, it really hurts. They cared enough about me and knew enough about me to know that I’d love a book on some bizarre topic (OCaml fits into that). They did their best to get me a gift that they thought would be just right, but they didn’t know enough about the topic to know what was good and what wasn’t. Then they spent their hard earned cash to get it for me. I don’t know anyone except my father and my uncle with cash to burn. When my friends or family get me a gift, I know that for many of them, they did without something they wanted or needed to get it for me. The worst is when it’s my wife… I have to give her the money to get me gifts, so it’s like my money is being wasted by remote control when she gets me a stinker gift.

    J.Ja

    Comment by Justin James — 4 August 2009 @ 11:02

  8. I think that OCaml has definitely suffered due to its sponsor (likewise, I think Zend has hurt PHP, and Sun isn’t helping Java much either, its succeeding despite Sun’s best efforts. . .).

    I definitely agree re: OCaml and PHP. Sun is another story.

    Much like Microsoft, Sun is an interesting mix of good and bad for its products. It tends to do some awful things to product design, implementation, documentation, and so on. On the other hand, it manages to “hard sell” the things enough, and repeat its marketing about the products often enough, that people start believing the artificial hype. All else being equal, if you hear something often enough, you’re going to start believing it — and people have definitely heard Sun talking up Java enough to believe it, no matter how self-evidently full of BS a lot of what Sun has said about it actually is.

    But it had no way of interfacing with the OS save for calls to the .NET Framework.

    I think the only .NET languages that aren’t hampered by that limitation are those that have legacies of pre-.NET functionality as Microsoft languages, and didn’t expect F# to offer any more-direct access to the OS APIs and ABIs or “legacy” libraries.

    let user_menu_choice = to_i Console.Readline();

    That’s one of the major complaints I have with .NET languages in general — the mixing of language syntax with .NET library syntax in such an inelegant manner (on top of which the very Java-like .NET library syntax itself is downright fugly).

    That’s also part of what I described above in my complaints about F# getting books in English while OCaml doesn’t: so much of what one could do in pure OCaml must, instead, be done via .NET libraries when working with F#, thus invalidating a lot of what one learns when working with F# if one wants to translate it to OCaml development skills. Things work fine the other way, though, because learning OCaml is almost entirely useful for learning F#, as long as you already know how to use .NET libraries for development in general.

    Plus, the .NET calls felt REALLY out of place. It was like watching an interesting movie, but the boom microsoft kept entering the frame and you could faintly hear the director in the background.

    I take it you meant “boom microphone” there — and yeah, I totally see your point.

    If someone got me a horrible book, I’d be even more angry than if I bought it.

    Same here. I was being sarcastic when I called that “consolation”.

    They did their best to get me a gift that they thought would be just right, but they didn’t know enough about the topic to know what was good and what wasn’t.

    In this case, it wouldn’t have been possible to properly go over the book in advance, since it was bought through Amazon anyway — and wasn’t available at any local stores where the gift-buyer lived. In addition to that problem, the book’s issues arise when actually reading it more than when looking it over. It took me three chapters of reading Practical OCaml before I came to the conclusion that it was a hopelessly broken text.

    Then they spent their hard earned cash to get it for me.

    Yeah, that’s what most annoys me about this — that someone else spent good money on this turkey for my sake. I don’t like it when people get ripped off, but it’s even worse when they get ripped off for my sake. That author has a lot to learn, and the publisher needs to start taking the advice of technical reviewers more seriously. The technical reviewer for this book broke his silence after publication to share how much he thought this book needed a serious rewrite, and how the publisher basically ignored that advice to meet some kind of time table for publication.

    If you really can’t delay something that bad, you need to just cancel it.

    Still . . . it’s basically the only OCaml book in English. Is it better than nothing? I don’t really know. For my sake, I’m inclined to say “No, it’s worse than nothing.” Maybe it’ll spur some effort to produce a better OCaml book in English, though. I can dream, I suppose.

    Comment by apotheon — 5 August 2009 @ 11:47

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License