Interview with Andrew Barry
This interview was originally published in the January 1999 issue of Apple Wizards, a free magazine located at <http://applewizards.net/>. Apple Wizards retains all rights to this interview.
AppleWizards (www.applewizards.net) recently had an interview with Andrew Barry in their Macintalk (remember that extension?) column. Seeing as I didn't provide any info about Andrew in last issue (after all, I made him RB-Man Of the Year), I figured this would more than make up for it. Enjoy!
Welcome to the first Macintalk of the
last year of the second millenium. Macintalk is my series of monthly interviews with
people who make a difference in the Mac world and beyond.
This month the technologically sophisticated, the technologically interested,
and those who are just curious should be interested in the following interview with
Andrew Barry of REAL Software. REAL Software is the publisher of REALBasic, possibly
the foremost implementation of the BASIC programming language on the Mac. Andrew
speaks in BASIC (is it possible to dream in BASIC?), so for your reading pleasure
I have translated the following interview into English.
Check out this month's interview, then email me your ideas, comments,
and suggestions for who you would like to see interviewed in an upcoming issue.
Interview conducted 18 December
1998
Bruce Klutchko: Please tell us about your background. How did you get into
programming?
Andrew Barry: I'm a mainly self-taught programmer I first started programming
when I was nine on my father's [Radio Shack proprietary] TRS-80 Model I (with a whole
4 K). Of course my programming horizons expanded immensely when he upgraded it to
16 K of memory (and the substantial improvement in the BASIC implementation that
came along with the upgrade).
Of course in my early days, my programming wasn't exactly rocket science a program
that printed "Hello world" and kept it on the screen was pretty exciting.
As I grew older, my proficiency grew, as well as the power of the machines I was
using: a MicroBee (a hobbyist computer in the Australian market still based around
the Z80 processor, though with 32 K of memory!), an Amstrad CPC (a hobbyist computer
from Britain I don't know if they ever made much of a presence in the US market
again, Z80 based, but with 128 K of bankswitched memory), and Amiga 1000 my
first exposure to the 68000 processor, and a whopping 2 MB of memory, once I added
a RAM expansion.
At this point I'm just about to enter a university to be specific, Australian National
University but one of my crowning works was a Modula-2 style compiler I wrote on
my Amiga as my Year 12 final semester project. Actually, this was a pretty nice piece
of work for an entirely self-taught compiler writer.
BK:
Did you have formal training?
AB:
I've got a Bachelor of Science degree which was predominantly Computer Science based.
BK:
How did you become interested in the Mac?
AB:
One of my close friends in university had just bought a IIci we'd previously played
around with doing games development (nothing completed, at least on the Amiga), but
here was a more interesting machine with far more potential. Of course, my first
programs didn't even use the Macintosh Toolbox but slowly I managed to scrape together
my first Inside Macintosh set, and slowly but surely started to tame this new platform.
Once again, my learning sped up substantially once I had managed to save up enough
money to purchase a IIsi, just a day after they were released in Australia.
BK:
How about REAL Software? Some of our readers have been following you since the Cross
Basic days, but most of us would like to know more about who works at REAL Software.
AB:
The other people at REAL software are, in alphabetical order: Janet Davis in Customer
Service. Janet handles orders, customer service and shipping. Jannice Faber in Administration,
handles the accounting, is our press contact, manages our trade show presence, as
well as all of the other administrative tasks necessary to keep the company running.
Jason Parsley inTechnical Support is the first line of support which takes a lot
of the load off me. He also has writes and maintains the custom order system we use
to automate our order processing. This system is the reason we can handle so many
orders from start to finish without requiring a large staff. Geoff Perlman, President
and CEO, is the main guy he runs the company, works with me on product planning,
and wrote most of the documentation.
We also now employ several people on contract to do our graphic design, documentation
updates, set up our international distribution, etc.
BK:
Who are the other people who are important to the success of REALbasic?
AB:
The entire REALbasic user community is important to the success of REALbasic without
the support, and sometimes patience, of our users, REALbasic would never have gotten
as far as it has to say nothing of future versions.
BK:
The Mac has not had the same choice of programming languages as the Wintel platform.
Some time ago, we had Lightspeed C, Think C, and then MPW C. Now we have Code Warrior
C. There are now several versions of BASIC available for the Mac, but until REALbasic,
none have seemed to do very well. In fact, one BASIC with a visual interface, developed
at about the same time as REALbasic, seemed to stop being supported just as it was
released. Why do you believe this situation came about?
AB:
Well, it's always been a big leap of faith to implement a programming language
and most corporations are much more willing to put their engineering time into writing
new WYSIWYG HTML editors. So, a lot of the development work being done on development
environments is being done by lone programmers in their spare time.
The reasons that a programmer wants to be writing a development environment in their
own time tends to be one of the following reasons: for fun so they know that they
are able to do it, or for play the programmer has some wild idea and they want
to make it fly.
The problem with this is that there are no commercial considerations indeed, usually
just after they've reached the proof of concept, they drop the project and start
a new one, because they've already proven they can do it, or because they've got
a wild new idea that's even more interesting than the previous one.
I was, of course, such a lone programmer but one day I decided that I was going
to stop jumping from concept to concept, and instead sit down and finish programs.
Luckily REALbasic was such a broad concept, that there is a lot of room to try out
interesting concepts, while still progressing the product as a whole.
Turning a lone programmer project into a commercial solution requires a new or established
company to take over the project and fill in the blanks. One classic example of this
is how Metrowerks transformed itself from a marginal Modula-2 compiler vendor into
a leading C/C++ compiler vendor by buying their C/C++ compiler from a lone programmer.
Of course, the whole process of a commercial company being interested in taking the
risk with a product is related to the size of the niche and the competition in that
niche.
The perceived weakness/future of the Mac platform has meant very few development
environments coming out in recent years.
BK:
Is the Mac a good programming environment? As someone who has had to look at the
OS from the inside out, just how good is it compared to the competition?
AB:
There's sort of a love-hate thing going on here. To compare the Windows API and the
Mac Toolbox, the Windows API operates at a higher level, but this higher level nature
means that sometimes under Windows you're forced to be competing with the OS to find
some workaround to get exactly the behavior you want.
On the other hand, the Mac Toolbox works at a very low level, which means that there's
a lot more work to get a simple app up and running, but you've got a much finer degree
of control on how your program behaves.
BK:
I'm surprised to hear that. So many of the older DOS programmers used to complain
about the Mac, saying that they'd never program on a computer where the ability to
control to computer was to such a large degree predetermined by the OS.
AB:
This is largely an artifact of the "since I have chosen this OS/car/city/...,
it must, perforce, be the best OS/car/city/...". I mean, they're hardly going
to say "I feel like a complete idiot for continuing to support this outdated
OS".
While the MacOS works at a somewhat lower level than Windows, it's still a far smaller
conceptual gap than that between DOS and the MacOS. (You must remember that Microsoft
worked closely with Apple on the Macintosh inexplicably, chunks of the Windows
API are very similar to the Mac Toolbox).
Once upon a time, I was a reasonably proficient DOS programmer writing TSRs, using
assembler, etc and if you were going to write even a semi-professional program,
your main interaction with DOS, outside of file I/O, was a chunk of code telling
DOS to get out of your way (in the form of critical error handlers, etc). I mean,
no-one in their right mind would use the BIOS for keyboard input, screen output,
serial port control, etc. it was such a POS that you bypassed it wherever possible.
Of course, I'd love to have memory protection can't wait for Mac OS X...
BK:
As a developer, how do you see OS X changing the user experience, both for the average
Mac user and the kind of user who will purchase REALbasic?
AB:
The changes will be subtle but actually profound for the user experience I mean,
putting aside any of the visible changes that MacOS X provides, the addition of preemptive
multitasking between programs provides a far smoother user experience. For example,
the first time I tried Windows NT after using Windows 3.11, while everything appeared
identical, the environment was more productive for me because instead of various
programs locking up the computer or using too much processing time, I could just
seamlessly switch to other applications and continue working on other bits.
BK:
Do you see Apple continuing to be a viable platform from the perspective of the quality
of the operating system and hardware? And how about from the perspective of its commercial
viability?
AB:
Yes I believe Apple will continue to survive, even grow, in the future, and REALbasic
is planning on supporting Apple for the foreseeable future.
The main thing that will contribute to Apple's success is its ability to maintain
its newfound commercial sensibilities. From my perspective, Apple has, until recently,
worked like a bunch of 'lone programmers' each little subgroup has been off and
doing their own little wild concept projects, while the platform, as a whole, became
neglected because nobody was "taking out the trash."
This changed only when Apple started saying, "well, even though it would be
more fun to develop our own (insert: graphics accelerator, expansion bus architecture,
serial port replacement, memory architecture, network architecture, internet replacement,
web browser, OS kernel, etc) from scratch, it would be cheaper, more stable, interoperable,
faster time-to-market, etc. if we just licensed the technology from somebody else."
BK:
Who is the typical Mac user who might use BASIC? Is this person the same as the person
who would write a program in C? Someone who might use AppleScript? Or a (now orphaned)
HyperCard programmer? When should the user customize a database such as FileMaker
Pro, and when should he or she tackle a programming language? Which is best for which?
AB:
"One ring to rule them all and in the darkness bind them."
The truth is that a person should always use the tool appropriate for the job. If
all a person needs to do is some simple automation of another app, then using AppleScript
alone is probably better than using REALbasic.
To make a very broad generalization, existing Macintosh development tools fall into
two categories: low level tools, such as CodeWarrior, where anything is possible,
but with a very steep learning curve, and high level tools, such as Director, are
far more accessible, but are limited when you try to do things that the developers
didn't intend.
REALbasic attempts to span the gap between the high level tools and the low level
tools, in that it tries to be accessible to a wide audience, while having sufficient
breadth to allow the user to accomplish a wide range of programming tasks.
Of course if the task you're trying to accomplish fits well within the bounds of
an existing high level tool, such as Director, then you're probably better off using
the specialized tool, rather than the Swiss army knife.
Taking your example of FileMaker Pro FileMaker Pro is an excellent product, and
if the user's problem is best solved by using FileMaker, then that's the solution
that should be used but if FM doesn't provide the degree of flexibility that they
require, then they should look for another solution.
As an aside, REALbasic 2.0 is currently under development, which will provide strong
database connectivity, including a royalty-free single-user database engine.
BK:
It takes a beginner just minutes to write the "Hello World" program in
most BASICs. How steep is the learning curve for the new REALbasic user?
AB:
The learning curve is equally gentle, if not more so. When REALbasic opens, it automatically
opens the default window just drag a static text control onto the window and type
Hello World. Then run it.
REALbasic contains a fairly broad range of features, but the amount of knowledge
required to use any particular feature has been kept fairly shallow. While REALbasic
is object-oriented, the user doesn't have to worry about learning OOP, unless the
code they'll be writing is object-oriented.
BK:
How steep is the learning curve for the experienced programmer?
AB:
The experienced programmer should find it easy to get up to speed with REALbasic
the core language will be very familiar, and they'll get up to speed on the various
features quickly. Programmers coming from Visual Basic on the Windows side will feel
right at home.
BK:
The term "Object Oriented Programming" seems to scare away some would-be
programmers. How does OOP impact on the programming experience?
AB:
Initially, the user doesn't really have to worry too much about object-oriented programming
at the simplest level everything is automatically handled for them. They will need
to learn OOP if they want to fully exploit the program, but many users get along
just fine using just what has been provided.
BK:
Your program can run Visual Basic source code. Does this code run as well on the
Mac as on a PC?
AB:
Yes. In fact it should run even better REALbasic was designed to be a compiled
language, while Visual Basic is still mainly interpreted.
BK:
Does this mean we might see some Windows programmers porting their applications to
the Mac?
AB:
We're already seeing this we get lots of mail along the lines "we have this
VB application and we're getting lots of interest from some of our Mac clients, and
we heard that you were the best way of porting VB programs to the Mac".
In fact, with the RB 2.0 Pro feature of transparent cross-compilation to Windows,
we've got some users who are planning to drop VB entirely and do all of their development
in REALbasic whether targeting Mac and Windows, or sometimes even if they're only
going to be targeting Windows.
BK:
It would be quite a pleasure to see the Mac helping out its unwanted offspring, Windows!
Much has often been made of the difference between BASIC and C. Some claim that BASIC
is a high level language, and therefore cannot have the degree of control of the
Mac and the speed of execution of C code. They say that this means that "serious"
programs can't be written in BASIC. How does REALbasic stack up in this regard?
AB:
There's actually a couple of different strands to this question, so I'll try and
address each of the components. Purely from the language standpoint, REALbasic offers
several advantages over code written in C: true dynamic-length strings (including
DBCS support), array bounds checking, garbage collection, and pre-emptive multitasking.
All of these things require a certain amount of overhead, so in that respect, C code
will typically execute faster than the equivalent piece of REALbasic code. Of course,
a piece of C code is much more likely to crash and if you hand-code into the C
code the equivalent safety features, the speed much more closely approximates the
speed of the REALbasic code. REALbasic version 2 has some options that allow the
overhead to be reduced to some extent, but at least until version 3, there will be
a slight speed disparity. Also, REALbasic offers a rich environment of windows, controls,
and classes that encapsulate the commonly used Mac OS Toolbox services. While these
offer lots of features and capabilities, it's certainly true the sometimes people
need a finer degree of control than a 'one-size-fits-all' implementation can provide.
The traditional way a high level environment gets past limitations, whether in speed
or in features, is through a plugin architecture, and REALbasic is no different in
this regard. REALbasic supports its own plugin format, which offers the best level
of integration. Plugin writers can write new methods, classes, and controls which
seamlessly integrate into the product. Hypercard has a popular plugin extension using
XCMDs/XFCNs, which people used to add many features to Hypercard that it didn't intrinsically
support. REALbasic programs can also use XCMDs/XFCNs. Apple introduced the Code Fragment
Manager for the PowerPC, which was about their fourth attempt at a shared library
facility. REALbasic programs can directly call into CFM shared libraries, which also
includes the entire Mac Toolbox. While REALbasic has intrinsic routines for constructing
AppleEvents for inter-application communication, sometimes it's a lot easier to write
an AppleScript which can also be easily utilized by REALbasic programs.
BK:
Plug-ins and XFCN's are very important to the viability of a programming language.
What are some of the more useful XFCNs that you have seen for REALbasic?
AB:
We support our own custom plugin format. Some of the more interesting plugins that
have been written include Additional toolbox support, Quickdraw 3D support, and Java
support.
While it's true that people probably wouldn't be writing Photoshop entirely in REALbasic,
it's entirely conceivable that they could write all of the image processing stuff
in a plugin (written in C) and do up the entire interface in REALbasic.
BK:
Does the smaller user base for the Mac detract from the economic incentive to write
a Mac program?
AB:
Well, it depends. You should never really judge platforms by the entire size of the
user base, but by how many copies you think you can sell. (Yes, I know this is cold-hearted
capitalism, but if you want to be successful...)
So in my mind, the Mac market was a lot more attractive than the Windows market,
because the product would have a far greater possibility of success in the under-subscribed
developer tools market while we would have been completely overshadowed by products
such as Visual Basic on the Windows platform.
Generally, I don't think that writing programs in REALbasic should restrict them
from deploying on other platforms the 'pro' version of REALbasic 2 will contain
a fairly transparent cross-compiler for Windows, and you should expect to see more
compilation targets in future versions.
BK:
I recently acquired a very useful freeware program, called "Sigerson,"
which is a program which helps in creating Sherlock sets under Mac OS 8.5. I was
immediately impressed with how well it worked and its truly delightful interface.
It wasn't until using the program for a while and checking the "About"
box that I learned it was made with REALbasic.
AB:
People who talk about how "serious" programs can't be written in a high
level language are usually just chest-beaters who feel that the only way to write
something is by doing it the hardest way possible.
If we're thinking of the same article, the columnist's opinion was something along
the lines of "high level tools encourage amateur programmers to write software."
He rationalized this with a set of the standard arguments, including: "To be
honest, I don't want just anybody making software. If you don't know what a guard
page is (...), then you shouldn't make software for anyone but yourself and a few
friends." "If you want something done right, you do it yourself. You don't
let some application make buttons for you, you do them yourself. You don't drag and
drop a pop-up menu, you make it yourself."
Personally, I'm all for people expressing their creativity perhaps Sigerson would
never have been created if REALbasic didn't exist.
BK:
REALbasic has a large and very active community of users. There seem to be very many
message boards where users swap advice and code. How important are they to the success
of REALbasic? Do you get involved with them at all?
AB:
The active community of users is extremely important to REALbasic as they are our
evangelists, as well as providing a lot of self-help for the community. I try to
maintain a presence on the main REALbasic lists both to answer questions that nobody
else can, but I also lurk a lot, seeing where people are running into limitations,
and keeping a list of future enhancements to the software.
BK:
Most people who have programmed in BASIC have encountered a code monster, called
Garbage Collection, that could stop a program dead in its tracks for no apparent
reason. It has been a problem for BASIC but not for other languages. Why does BASIC
uniquely have this difficulty? How does REALbasic handle garbage collection?
AB:
Well, this was more of a problem with BASIC implementations running on those old
slow machines, where BASIC would probably be the only language that would have the
temerity to attempt to have garbage collection and the style of garbage collection
used would require periodic scans of the entire heap to flush out all of the unused
objects, which caused the hiccups that you remember.
REALbasic uses a progressive garbage collector, which causes the expense of garbage
collection to be spread out evenly across the entire execution time removing those
irritating hiccups.
BK:
One last question. As a developer, how do you judge Apple's attitude towards its
users and developers? Are they making an effort to make your work easier? How could
Apple do better to increase the vitality of their product?
AB:
I think Apple is finally listening to its users and developers you can judge this
by the directions that their product lines and operating systems are moving.
As for ourselves, we have very good ties with various people within Apple. We're
committed to making REALbasic work with many new technologies, since what good is
technology if it's unapproachable?
I can't offer up a magic recipe for the success of Apple I believe in their current
strategy, and will be backing up that belief with solutions something that I couldn't
say for many of their previous strategies.
Thanks, Andrew, for spending some of your valuable time with us. Those of you who want to check out REALbasic can visit REAL Software's website at http://www.realsoftware.com/.