Begging pardon in advance if I offend anybody's deeply-held convictions here, 
but it's my opinion that a language compiler is a tool, not a religion. So 
I'm somewhat baffled that people seem to have an emotional attachment to 
their tools; kind of like getting attached to a screwdriver, y'know?
 
Recently, Scott spencer said of REALbasic:

>It is a very nice product, but IMHO FB offers much more flexibility and
>capability than RB.
>
>RB is very good for beginers, and some pretty advanced apps can be built
>with it.  But if I really want to learn and understand how things are
>"really" done on the Mac, I don't think you can beat FB.

I can understand that statement, though I don't think it's correct. It 
reminds me of the statement made when the Macintosh first came out that DOS 
offers more "control" and "flexibility" than the Mac OS, because you can get 
right down on the machine; or, before that, that punch cards offer more power 
and flexibility than terminals, because with punch cards you "really" get 
down and see how things are done.

Object-oriented programming is a completely different paradigm, and 
programming in RB is significantly faster and easier than programming in FB 
for many applications. But, RB allows a good deal more power than FB in many 
cases, too. Want to write a program that establishes a link to another 
computer over TCP/IP, or interfaces with a 200,000,000-element SQL database? 
You can do both with about three lines of code in RB. Want direct access to 
the Mac Toolbox or Windows API? RB, like FB, offers both.

More significant, however, are some fundamental issues that have turned me 
off FB recently. Half a /decade/ after Apple has abandoned the 68000 family 
of processors completely, FB still compiles only for 68000. That, I believe, 
is very telling. So is the fact that the Staz Web site hasn't been updated 
since the Eisenhower administration.

Ken Shmidheiser said:

>But the saving grace of FBII (my copy, v2.3.1, has as its latest 
>copyright 1995 which, in computer years, is almost anachronistic. Of 
>course, updaters have offered some relief) has been it's ability to 
>take you deep inside the bowels of the Mac, right into assembly for 
>those who want to go there.

I don't think that's a saving grace. Almost all compilers allow this kind of 
down-on-the-bare-metal programming; RB does, as does Apple's MPW, and 
Metrowerkes CodeWarrior (both of which I have, BTW), and any other modern 
compiler. But writing and maintaining large applications, particularly large 
applications that must manipluate non-trivial databases or interface with a 
wide variety of different hardware types or perform high-level network 
access, is not best done on the bare metal. That's why high-level languages 
exist in the first place. And with FB in particular, you're writing on bare 
metal IN EMULATION! Most FB programs will be deployed on a computer that does 
not even contain the kind of processor FB's assembly language instructions 
are written for. So there goes the speed advantage of assembly, right out the 
window.

Ken Shmidheiser also said:

>We all use QWERTY keyboards, not because they're best-- Dvorak is far 
>superior-- but because QWERTY was here first. Most of us probably use 
>ZIP disks, not because they are best-- most of our drives eventually 
>will succumb prematurely to the "click of death" and probably take a 
>few disks with them-- but because ZIP was here first.

I think these examples are flawed; ZIP disks succeeded because they were 
superior to the SyQuest disks they replaced, and right now there is nothing 
else on the market to compete with them. (SuperDisk? No--not available in 
SCSI.) When something else hits the market that is better, Iomega will sink 
without a trace.
 
But there IS a valid point here, although I think it's backward. I think many 
people are still using FB, despite the limitations of 680x0-only development 
and despite the fact that it isn't object-oriented, because they learned it 
first. And, to be fair, FB is a good, solid programming environment, for its 
time. But even a good programming environment has to keep moving.

And Ken Shmidheiser said:

>Of all the languages I have ever seen, FutureBasic does the best job 
>making event-loop programming understandable. In fact, learning it is 
>probably the easiest stepping stone to other, more complex languages.

Perhaps you should download the RB demo. In an opject-oriented paradigm, 
every class and every window has its own event queue. So instead of a single 
event queue where, for example, you do

Select case event
   case windowRefresh
         select case ID
             case 1
                fn refresh FOO
             case 2
                fn refresh BAR

(etc)
 
you simply put the code to refresh window FOO in FOO's paint event method, 
and to refresh BAR in BAR's paint event method.

(Incidentally, for those not into OOP, a "method" is like a function or 
subroutine. An object's methods can be called explicitly, by a statement like 
someObject.someMethod (whihc is similar to FN SomeMethod), or by an event, or 
by both. A method, like a function or subroutine, can have local variables, 
access global variables, and return data; however, methods may also access 
variables that are global to all the methods in a particular class, but 
cannot be seen by methods outside of that class. And unlike traditional 
programming techniques, object-oriented programs can share entire 
classes--meaning their methods, data, and events--not just their code.)

There's a reason object-oriented programming has revolutionized the computer 
industry and is used at almost all "big" programming companies to write 
everything from operating systems to Adobe Photoshop. Like event-driven 
programming, it is an extremely powerful metaphor that allows programmers to 
create highly sophisticated, portable, reusable, easily-maintained programs 
of very large size, very quickly. And if you already understand event-driven 
programming, object-oriented programming won't be that great a stretch for 
you.

And finally, Phil Yates said:

>FWIW, the other day I dug out a ZBasic program which I'd compiled almost 8 
years
>- on 11 Sep 1992, to be exact. God knows what Version of the OS it was 
compiled
>under, or on what computer. But the program still runs without error on my G3
>Desktop and G3/400 Powerbook. The same is true for all my FB1 and FB2 
programs.

That's a testament to Apple's OS design, I think. But here's the key 
question: Will they work on MacOS X? Apple's new operating systems use a new 
API, called Carbon; programs not written in PPC-native code and which do not 
adhere to the Carbon specification will not take advantage of the protected 
memory, preemptive multitasking, and similar new features of MacOS X, and in 
fact may not run at all. In any event, it's unlikely that the code that has 
served you thus far will continue to serve you as well in the days of 
FireWire, USB, Open Firmware, a UNIX-kernel operating system, and the other 
new landmarks of Apple's brave new world. Hell, my large FB applications have 
trouble on G3 machines with a megabyte of Level 2 cache, unless I use a 
special cache control panel to reduce or disable the cache!

Phil Yates also said:

>A CodeWarrior (and I liked the typing error someone made when they called it
>CodeWorrier), RB, C++ Program, won't, in general, do much more than an FB2
>program - what's different is how you get there. FB3 is a major advance (I'm 
a
>Beta tester), but in the end, all you have an an executable.

And that is the crux of the matter.
 
FB is a tool. Nothing more.

If it works for you, then by all means, use it. A phillips-head screwdriver 
shouldn't be used to remove flathead screws; and if you do more than one kind 
of program development, you should be conversant with more than one compiler.

If rapid deployment on multiple platforms, development of many programs using 
common code, network access, heavy event handling, database management, or 
Internet TCP/IP access are important to you, consider RealBASIC. If you need 
high speed, high performance, direct memory management, low-level I/O, or 
real-time control, use Apple or Metrowerkes C++. For preservation of legacy 
code, development environments on older computers, and reasonably rapid 
small-to-medium scale development, FutureBASIC is fine.

I have virtually abandoned FB in favor of RB's more modern, more powerful 
development environment, because FB no longer serves my needs. RB can do 
many, many things FB cannot, and I prefer object-oriented programming. If 
FB^3 is better than RB (and offers PPC and Win32 code generation), I'll 
switch back. Neither FB nor RB will ever be the only compiler I use, though. 
I think an important step in program development on any platform, with any 
language, is an analysis of the needs of the project and the environment and 
language best suited to it.

Franklin
[private email welcome]