Cross Platform Programming Languages
lloy0076 at adam.com.au
Wed Jan 17 09:18:20 CST 2007
> If you can get over the fact that it's not free, and it's basic,
> consider Real Basic (the Linux standard edition is free apparently).
RealBasic uses an object oriented version of BASIC not unlike Visual
Basic (at least in VB 6.X days). Its OS X GUI is very easy to use and
its debugger is highly effective. It's not too rare that a developer
will be able to answer your questions if something goes wrong.
> I had a bit of a play with it last year (on Linux and Windows) and
> they also have a MAC version as well, and the code is generally
RealBasic is a Mac product. Because it runs atop its own virtual
machine, it's able to port to other operating systems as you have found out.
> In fact from speaking to their CEO you can actually
> deploy to other platforms from a single "professional edition" version
> of the product.
Here is the crux of the matter. The core material, developed by Real
Software, is truly cross platform. However, as Real Software isn't the
largest software developer not all things one might require are an
official part of RealBasic.
I probably should say that I've had extensive experience working with a
Real Basic POS application which initially communicated via a
"proprietary" API to a PHP backend. Realising that the communication was
becoming cumbersome, we took a slight digression:
1. I implemented a Perl SOAP server
2. The other person used RealBasic's SOAP plugin/libraries
3. ...and threads
Here is where trouble started.
Firstly, the virtual machine that RB uses is like the old Windows 3.1
scheduler. It's co-operative; it cannot be preempted. In order to hide
the delays caused by the SOAP method calls, we put the SOAP calls into a
n RB thread and then called it in the thread.
But the threads run on the RB virtual machine and they can't be
preempted. So, the SOAP thread would land on the RB virtual machine and
would sit and wait for the SOAP server. Of course, the GUI thread would
get blocked and suddenly the application would appear to freeze.
This got to be a total pain. We took another path. RB would write to an
SQLITE backend and a Perl client would read from the local database and
send the messages via SOAP to the server. This proved to be a winner, or
so we thought...
At some stage we noticed that messages were mysteriously dropped. We
couldn't quite work out what it was except we knew that it would happen
if I set the Perl SOAP client to send data too fast.
I came to the conclusion that it wasn't the Perl stuff alone. I could
put that on four different machines and run it as fast as Perl would
loop it all at once and the Perl client/server would stay in sync.
We discovered that RealBasic doesn't implement non-blocking writes to
SQLITE3. Perl, on the other hand, would grab a lock on the database
while it was writing to it as it was possible that RB and Perl could
clash with each other...and we discovered that if the Perl client was
accessing the SQLITE3 database at the same time as the RB client, then
the Perl client would take precedence and the RB client would do "random
"Random stuff" usually equated to dropping whatever statement it was
doing, but occasionally it would corrupt the SQLITE3 file.
Whilst we looked and asked, we came up with no sensible answer to this
dilemma. As far as I currently know, RB will always do a blocking read
if it's trying to access a database that is locked for some reason and
that this block will also have the same effect as blocking the
I think I would still recommend RealBasic but only with careful
investigation as to:
a) Its handling of databases, transactions and locks
b) Its handling of threads
c) Its handling of SOAP / XML-RPC if you plan to use it
To be useful in the application I suspect Evan wants it to be, you need
to be able to do have a virtual machine where you can't block the GUI
from doing things.
At best you'll look unprofessional - at worst you'll get a hung application.
More information about the linuxsa