[futurebasic] FutureBASIC future?

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : October 2007 : Group Archive : Group : All Groups

From: Ken Shmidheiser <kshmidheiser@...>
Date: Thu, 25 Oct 2007 13:41:52 -0400
Chuck asked:

> What I'm wondering is this: Does FB have a future?


Chuck, it's an excellent question.

Basically (pun intended) you can break FB down into three components:

1. The FB syntax based on BASIC and the event-loop programming paradigm

2. The FB Editor and its integrated debugger custom designed to work  
with the FB syntax, and to generate code that can be sent to...

2. The FB Compiler which takes the FB code and generates executable  
applications based on legacy Apple technology.


The FB language, like all languages, will be around as long as it's  
remembered. As a dialect of BASIC, its essential concepts are easy to  
grasp by anyone familiar with BASIC regardless of the targeted  
platform of the BASIC in which they are conversant. However, like  
most dialects and idiomatic speech, only a select group speaks it as  
a "materna lingua"  or true native language. (Probably the majority  
of them can be found in this news group either conversing or reading  
it.)

The FB Editor is probably one of the most endearing features among  
FB's ardent advocates. This piece of time-proven software has been  
relatively bullet-proof, is easily understood and and extremely  
versatile. That said, it was written for an earlier generation of  
Macs and has been strained by today's programmers who demand more  
intimate access to the latest Mac Carbon Toolbox functions and even  
to OS X's Unix underpinnings. The fact that the FB Editor has kept  
pace this long is a testimony to its robustness. However, with the  
new generation of Intel-based Macs, it is becoming quite long in the  
tooth.

The FB Compiler is at best legacy and, in its current state, is  
headed toward total obsolescence. It cannot compile the new Universal  
binaries that run natively on Intel machines, so its executables are  
limited to running under the Mac's built-in Rosetta emulator. The  
compiler would have to be rewritten from the ground up for the new  
generation of machines and that appears highly unlikely to happen.

Katrina hit Staz at the worst time. It came just as Apple was  
changing its horses in mid-stream with the Intel machines. Even  
before the switch to Intel, Apple was quietly "encouraging" event- 
loop Carbon programmers to abandon their ways and adopt object-orient  
programming in the form of Cocoa and its ObjectiveC superset to the C  
language. All new developers are steered in the OOP direction. Apple  
continues to discourage event-loop programming with its recent  
announcement that only Cocoa-- not Carbon-- will offer 64-byte  
support as the new generation of processors are introduced.

Nevertheless, Carbon event-loop coders-- which by extension includes  
FBers who, know it or not, rely on the Carbon Toolbox--have proven a  
recalcitrant bunch. They continue to be an active and significant  
segment of Macintosh developers-- and like it or not, Apple knows  
this. Also, there are still a few things that can be done in Carbon  
that can't be done it Cocoa, although parity between Carbon and Cocoa  
is improving.

With that background, what is the current state of the union?

Even with all its wisdom, Apple abandoned its old (and pricey)  
developer tools (also effectively killing CodeWarrior) and adopted  
the open source gcc Unix compiler that comes with every new Mac.  
Apple's Xcode IDE is simply a pretty GUI that sits on gcc. Since gcc  
can compile C and ObjectiveC-- among other languages-- Xcode serves  
as a fancy editor and an interface for gcc's open source debugger, as  
well as a providing a convenient way to browse documentation, check  
syntax and create several varieties of bundled applications. and  
executables.

A dedicated team of FB coders has taken a similar tact. Using the FB  
syntax and files produced by the FB Editor, they have created an open  
source application-- FBtoC-- that translates FB code into C and sends  
it to gcc to be compiled. FBtoC is a work in progress with elements  
being added almost daily. But even in its current beta stage, it has  
proven itself a capable tool.

Theoretically, a person can write code in the FB syntax in any text  
editor-- BBEdit, TextWrangler, TextEdit. etc.-- and send it to FBtoC  
for translation to C and compilation as a Universal binary with  
FBtoC. Of course, they would lose all the bells and whistles of the  
FB Editor.

In many respects, FBtoC is much more robust than its progenitor. You  
can pass not only FB language through it, but also C. You can also  
easily pass external libraries and frameworks without jumping through  
the hoops imposed in the current iteration of FB.

So as of today, the FB language remains alive and well and the aging  
compiler has a worthy replacement waiting in the wings.

The remaining question revolves around the fate of the FB Editor. My  
opinion and a buck will get you a cup of coffee, but if Staz decides  
to remain static with current FB Editor development, it wouldn't be  
surprising if an independent effort is launched to put a front end  
editor on FBtoC.

Whether or not such an effort would be open source as is FBtoC is a  
question for another day.

HTH.

Ken