Review of FutureBASIC II (long) ---------------------------------------------------------------------------- From apdoo@research.att.com (Alan Weiss <6672-14324> 0112120) Organization AT&T Bell Labs, Murray Hill, NJ Date Thu, 11 Jan 1996 21:50:14 GMT Newsgroups comp.sys.mac.apps,comp.sys.mac.scitech Message-ID ---------------------------------------------------------------------------- Summary: FutureBASIC II now includes the Program Generator and an improved debugger. It is a very worthwhile upgrade, especially if you don't already own the Program Generator. It is a very good language/development environment for hobbyists. Online and telephone help is free and responsive. There remain two long-standing issues with the compiler, though, that probably make it unsuitable for developers: still no PowerPC support, and poor SANE support. Outline of the review: 0. Who am I to write a review? 1. What is FB? 2. What is PG? 3. What's new? 4. What's old? 5. What's good? 6. What's bad? 7. Conclusion. 0. Who am I to write a review? It is a daunting task to try to review a development system, especially since I am not a professional developer. The only reason I am at all qualified to do it is that I believe that I am a typical FB user: a hobbyist. I have been programming with FutureBASIC (FB) for several years. I found it to be a simple way to get real, compiled programs up and running on the Mac. While I mostly use it for writing scientific programs related to my work, I did write and release one game, Quarto!, a few months ago on info-mac. This is not to say that commercial quality applications can't be created in FB, because they can and have been. But FB is, in my opinion, primarily a hobbyist's environment. 1. What is FB? FutureBASIC II (FB) is the BASIC language compiler/development environment, originally published by Zedcor, but now published by Staz software. Andy Gariepy, the original and current author of FutureBASIC, left Zedcor for Staz, so the program is in good hands. FB is a structured dialect of BASIC, with local variables in subroutines, SELECT/CASE, DO/UNTIL/ WHILE/WEND, and other structures. It is strictly a compiler, with all the advantages and the few disadvantages of such systems. It will also run most vanilla BASIC programs unmodified. It includes such niceties as an inline assembler, so you can tweak your code for speed once it's up and running, if you know some assembly language. The FB II package contains a development environment (I'll describe that shortly), the Program Generator (described in the next section), a few utilities such as ResEdit and MacsBug, tutorials, sample code, and unlimited free help. It comes on 6 800K floppies (a thoughtful gesture to those of us with older machines), requires System 6.07 or later, will run on a 1M machine (though it prefers at least 4M), and only requires 4M on your hard disk, though you will probably be happier with more room for sample code, tutorials, and your own projects. My FB folder is 25M, including 17M of my own projects and notes. FB is a fairly mature language. There is a wealth of sample code, for doing everything from such basic tasks such as incrementing an integer quickly, to complex tasks as writing a SimpleText clone (including QuickTime movie player and speech manager routines). Support is good, too. There is an unofficial FB WWW site (http://www.ids.net/~paumic/FutureBasic/index.html), an active support area on AOL (keyword Ariel, and one of the main reasons I have an AOL account), good telephone support (all you pay is the toll call, there's no extra charges once you buy the program), and email support, too (STAZology@aol.com). FB II comes with 5 manuals. Three are rather substantial: the Handbook, Reference Manual, and PG manual. Two are slim manuals, one aimed at complete beginners, the other at relative novices who know some variant of BASIC. All but the Program Generator manual are updated editions of Zedcor's manuals, which I thought were first rate. What's missing from those is a concise listing of what's new in FB II. 2. What is PG? The Program Generator is a companion program that enables you to get your program's interface and structure established very quickly and easily. PG enables you to draw windows and controls and menus, and then it generates resources and FB subroutines that handle these interface items. For example, you can create a window of "Text Editor" type, and standard File/Edit/Font/Size/Style menus, and then PG generates ALL the code necessary for a user to type in this window exactly in the Mac standard fashion. If you want to modify something, feel free: the source code is there for you to examine. All this power comes at a price, though. It takes some time to understand PG, and PG also adds to the size of your finished application. What you get is tested interface code in very short order. In order to test PG, I decided to try to write a SimpleText clone. It was amazingly easy to get started, even without reading the manual. I simply made a "Text Editing" window, got a set of default menus to handle them, and I was halfway there! After I opened the manual, I saw that one of the tutorials is a "File Viewer" project that displays and prints TEXT and PICT files, which is 90% of what I wanted to do. It's amazing that you can get one of these things up and running in half an hour (not polished, but up and running and not crashing). 3. What's new? The Program Generator (PG), a visual programming tool, is now included with FB. PG is now up to version 4, and is included with FutureBASIC II. I personally did not have PG before, so I can't compare this version to the previous one. FB also has a completely new debugger, which is being touted as one of the best new features of the program. The debugger has been so completely changed that it isn't really comparable to the old one. It can now be used with precompiled routines (INCLUDE files). Instead of inflexible "panes," the debugger has a set of floating windoids. Its only obvious deficiency over the previous one is that it is quite awkward to examine arrays now--you can't simply look at x(5) to see its value, you instead have to look at raw memory contents. There's a utility function for converting MPW Pascal headers into FB Include files, so if you have a developer CD from Apple, you can add any new Toolbox routines yourself. (I don't have such a CD, so I couldn't test this function, but it seems simple enough that it ought to work.) There is a "project manager" window that shows the names of the labels and functions in your project, and can be used for quick navigation. The whole system has a reasonably polished feel. Some minor bugs and deficiencies have been reported (and I've duplicated): STAZ screen, aliases on desktop move when debugger active (but return on restart), the WindowClipper utility was inadvertently left off the distribution disks, etc. However, STAZ has already issued an updater that corrects some of these problems. I believe that this is more in the nature of good news than bad: it is almost impossible to ship a bug-free product, but it isn't often that a company is so responsive that is ships an updater within a month. 4. What's old? FB II will run your FB code unmodified, provided you saved it as text files. The only exception to this is that debugger statements (TRON) now act differently. The Reference manual, which describes all the built-in functions, is almost exactly the same as the FB I version. I compiled a number of applications with FB II, and saw no difference in the output, or the compile speed. While FB II is NOT PowerMac native, the author claims that it compiles much faster on a PowerMac than FB did. I couldn't check this, since I only have an '040 machine. Math is still done in a flexible BCD format. You can choose to have almost any number of decimal digits in floating point. This is very good for some scientific applications. However, it is very bad for a many applications, because it is still almost impossible to access an FPU. This means that floating point calculations are always slow using FB, but accuracy is whatever you like (with a tradeoff of speed and accuracy). The FB development environment includes a smart integrated editor (it indents structures such as FOR/NEXT loops, highlights keywords, color-codes comments, etc.) The editor has not been substantially changed from FB1.03, except that it now color-codes comments. It still has some quirks with extending selections. 5. What's good? The online help in FB has always been a strength. The entire reference manual is available online, and it's searchable. Also, it contains code snippets that you can copy and paste into your program. The help window is resizable, although this may cause some of the formatting to be peculiar. PG included. The combination of FB and PG is almost certainly the fastest way to get a small application up and running with a good interface and without having to write a lot of event handlers. I had not used PG before, and I'm impressed. Edit fields now default to TEPInScroll instead of TEScroll. This was a minor interface problem for years, and I'm glad they fixed it (it means that edit fields now stop scrolling when there's no more to show, as in most other applications). 6. What's bad? The worst aspect of FB II is what didn't change: there is still no good SANE support, and it is still not PowerMac native. The former weakness means that it is very difficult to write FB programs that access a floating point coprocessor. This means that floating point math is slow, so certain games and scientific calculations and 3-d applications are hard to program efficiently. The second weakness means that commercial developers will probably not want to use FB. This should be less of an issue to hobbyists, since our programs are only written in our spare time anyway, and the FB/PG combination is so good at saving time that it probably overcomes all other objections. I don't know if FB will ever become PowerMac native. If it doesn't, then I expect the language will dwindle away. I also have some "whiney" complaints. PG does so much, including some things that I would have thought would be almost impossible to do. Yet there are some things that are obviously missing and easy to do. PG sets up menus very easily, and even handles most common ones completely automatically, such as the entire Edit menu (including Undo!). It automatically makes named constants so that you can refer to each menu item easily. What's it doesn't do is put the names of these constants where you would like them in your source file, such as the following pseudo-code: CASE _menuAction SELECT menuName CASE _itemone CASE _itemtwo ...etc. You have to type or copy the constants by yourself. The Program Generator manual is not quite as good as the rest. Many topics are addressed inadequately, if at all. For example, windows are referred to quite differently when using PG than when using FB; with the former, you refer to windows by class number, whereas with the latter, each window has a separate identifying number. How is one supposed to make sense of this? After a good deal of thought, I decided that PG's method is probably superior, since the action your program takes is almost certainly dependent on window class, not ID number. But how is one to refer to a specific window when two or more share the same class? (Of course there are ways.) The PG manual is silent on this entire subject. Furthermore, there are many functions that are inadequately documented in the manual. In the FB Reference manual, each function has a code snippet showing exactly how it is used. The user is left to dig for himself with PG. There is a plethora of sample code, so I am reasonably certain that I will be able to dig out the answers to my questions. But the manual is definitely not up to the standards set by the rest of the package, even if the programming environment is. PG has a much weaker online help system than FB. It is not really searchable...there is an outline of topics displayed, and clicking on a topic brings up more information in another pane in the help window. Also, it doesn't work quite right--several topics did not display fully or properly. I had some pretty severe crashes with FBII, and while they were not the results of bugs within FB II, they were worse than I ever had with FB. One was the result of setting some debugger preferences without knowing what I was doing. One was from running a PG project without doing some obvious steps. Nevertheless, my system got fried. I think the new power of FBII (especially its debugger) comes at a price for ignoramuses (such as me) who don't read the instructions first. Caveat emptor. 7. Conclusion. I must say that I feel my $75 upgrade fee was a very low price for everything I got. This price is only good until 1/15/95 (1/31/95 for out-of-US&Canada upgraders). The non-upgrade price is $229 + $6.65 shipping direct from STAZ: (800) 348-2623. I don't know if there is a "competitive upgrade" price.