John Norstad
John Norstad was one of the early inhabitants of comp.sys.powerpc (before there
were dedicated Be newsgroups). Shortly after the creation of the
comp.sys.be newsgroup, John posted a review of his first experiences
with a BeBox from his point of view as a long time mac user.
From: John Norstad (j-norstad@nwu.edu)
Newsgroups: comp.sys.be
Date: 1995/12/20
Subject: BeBox First Impressions
(edited by The BeBox Zone to extract BeBox review. See Google Groups for full post)
I've had the good fortune to be able to actually begin playing with a
BeBox for just a few days now. I thought I'd share my first impressions.
Be prepared for a bit of a shock when you first experience the BeBox. For
me, even though I wasn't expecting a Mac, when I first started using the
BeBox, I couldn't avoid expecting Mac-like behavour. After all, "Macisms"
have become part of my fingertips after all these years, and it's really
difficult to get used to or accept anything different, especially at
first. On first glance, the BeBox looks and feels kind of like a Mac, but
on subsequent glances I quickly discovered that it definitely is not a
Mac! When I encountered the differences, my first reaction was to get
terribly annoyed. Also, the Browser and other user-visible parts of the
BeOS today are crude. Don't expect anything close to perfection yet. It's
very raw and preliminary stuff.
I expect Amiga people will have similar initial reactions. Don't expect
all of the various "Amigaisms" you know and love to be on this box. They
won't be there! Sure, I'll bet quite a few of them should be there.
There's time for Be to make this happen where it makes good sense. You
also must at least try to understand and fairly consider those many
details about the BeBox which will always be different from the way the
Amiga works.
If you're a Mac bigot or an Amiga bigot or any other kind of bigot, you're
going to hate this box. The BeBox is not a "cleaner leaner Mac" or a
"cleaner leaner Amiga" or a "cleaner leaner UNIX". It's something new and
different from all of these things. If that's not what you want, stay
away.
Don't look at the BeBox and expect polish or even something that's very
pretty. Judge it not as something that is good or bad as it is today,
because today it's really pretty bad, but rather as something that has the
serious potential to become something very good indeed. This is a
foundation and an architecture for the future, not the future here today.
There are all sorts of influences on the BeBox architecture which you'll
notice as you start to use and program the box. Lots of Mac human
interface influence, as expected, but also lots of ideas from other
"direct manipulation desktop metaphor systems" like X-Windows and NextStep
and even MS Windows. Lots of UNIX-isms too, like the shell (a bash port)
and POSIX-style system function calls for those who want to use them. I
don't know about Amiga influences, because I don't have any experience
with the Amiga.
Give yourself time to get used to it. Be patient with it!
My advice to end users: Stay away! There's nothing here for you yet! Give
us time! But pay attention to what we're up to and keep thinking about us
and wishing us well. If all goes well, your day will come.
My advice to people who love to program and are frustrated with their
current behemoth systems with all their baggage and complexities: Get your
hands on one of these boxes as soon as you can. Don't delay! You won't
regret it.
My advice to people who despise C++: Forget it. Sorry, you lose.
I just finished reading the BeBook from cover to cover (except for the
media and midi kits, which I don't expect to be using), and I'm starting
to write my first little learning exercise programs. This is where I think
the real excitement and beauty of the box resides - in the way you program
it. The class hierarchy seems very well designed and above all, very clean
and simple. Of course, it's not perfect - nothing is. But it's a great
foundation. The core OS microkernel services also seem adequate - the
usual semaphores, message ports and message passing, shared memory,
virtual memory, and thread management junk. For most application
programmers, the higher level classes provide access to these services,
and you'll rarely need to call the low level stuff directly. For example,
the BLooper ("blooper") class makes it easy to create threads with simple
message queues which drive them, and the BMessage, BMessenger, and
BReceiver classes makes it easy to create simple structured messages and
post them to other threads in your program or send them to other programs.
Messaging is very important on the BeBox - objects send each other lots of
messages to get things done. Threads and the BLooper class are also very
important - both the BApplication and BWindow classes derive from BLooper
and work by processing messages which arrive on their queues. Every window
gets its own preemptive thread (actually two of them, because there's
another system thread that runs in the "application server" for each
window). Because of this design, nothing ever waits for anything else
unless it absolutely has to. Everything is completely live and immediate,
including window dragging and resizing and scrolling.
I can tell already that this box is much, much easier and more fun to
program than the Mac. For example, I can guarantee that any Mac programmer
will have an immediate orgasm the first time they do a scroll bar on the
BeBox! And we Mac programmers can forget about all those ugly things we
have to do in our Mac programs, like worrying about yielding time properly
for graceful cooperative multitasking, hassling with handle-based memory
management and fixed application partition sizes, 68K vs. PPC vs. "fat"
binaries, compatibility with old versions of the OS, horribly complicated
"Apple event" mechanisms, an infinite number of mutually incompatible
"plug-in architectures", etc. The list goes on and on. Of course, there's
a few new things we have to worry about too, like hassling with
pointer-based memory management (:-), and especially getting used to
managing competition between multiple preemptive threads for shared
resources. On the BeBox, you don't have to worry about locking memory
handles at just the right times, but you definitely do have to worry about
locking shared objects at just the right times. It's a new concept for
most Mac programmers which will take some getting used to. If you don't do
this correctly and understand what you're doing, horrible things can and
will happen. For me, it's reminiscent of the ancient days when I did
mainframe OS programming.
Again, however, the programming kits are also very raw. There's lots of
errors, inaccuracies in the documentation, and massive changes still being
made by the BeOS designers. For example, they still haven't decided
whether "resources" are even a good idea yet!
As with the "user experience", you're going to need tons of patience with
the "programmer experience". We have to be prepared for lots of changes in
these early days, even major design changes. The programming tools are
also currently very primitive (but this will get much, much better real
soon now, I understand - hi, Jon :-) I'm willing to deal with all of this,
though. I think it's a good thing, and worth the effort and aggravation of
being an early pioneer with this stuff.
--
John Norstad
|
