[Prev][Next][Index][Thread]
Re: The Lambda Nature
In article <LOiP4.1385$CL3.1074@198.235.216.4>, "Michael T. Richter"
<mtr@ottawa.com> wrote:
>(I haven't looked into BeOS'
> GUI stuff yet, so I'm holding out some hope of finding a clean,
> consistent,
> powerful GUI API.)
>
Hopefully making the following remarks will not make me enemies at Be,
but can serve as constructive criticism on how to improve the OS.
I have worked extensively with BeOS and its GUI API and
have been involved in two commercial applications.
One shipped (www.lcsaudio.com) and is a very successful product, the
other didn't.
IMO Be's strength is their OS kernel.
The threading model and priorities really work well.
Everyone loves the GUI API. At first. It's great for making toy programs.
Most people never work on large projects so never run into the
limitations. It is just not as well designed as Smalltalk or Nextstep or
MacApp. I think that this is the reason why there are still not very
many large commercial apps on it.
The UI framework seems to have been coded to a set of specs rather than
having had a paradigm in mind of how everything should work. Many basic
Design Patterns are not available directly in the framework meaning
everyone rolls their own.
The decision to force one thread per window on the programmer causes
needless synchronization implementation complexity for many apps.
There is also the C++ fragile base class problem. Be has already broken
binary compatibility once after they had committed to freezing it.
Many classes are padded out with dummy variables and virtual functions
for future expansion. For an OS that touts being a non-legacy OS, it has
a real legacy creating demon lurking in it in the form of the FBC
problem.
One of the things that is most celebrated about Be's framework is the
BMessage which implements IPC, dynamic binding, drag and drop,
copy-paste, etc. Most of those who celebrate it have never used a
dynamic language like Smalltalk or Objective-C where these features come
along with the language's built in message passing. So in a BeOS app you
are writing a lot of switch() statements to handle BMessages because C++
has no built in dynamic binding messaging. Writing these switch
statements becomes a real pain.
On top of that there is Be's scripting architecture which overcomes the
inabilities of C++ to query the messages an object can respond to, or
store messages for later sending.
So basically you have in the BeOS API a crude implementation in C++ of a
dynamic messaging system which requires a significantly greater
notational burden than if a dynamic language had been used.
I must say that at the beginning I was a true BeOS convert, and I
couldn't understand what all these Nextstep people were ranting about.
Well into my first large program I began to see the light.
All that said, BeOS is still potentially the best OS for real time media
applications because of its threading model.
Follow-Ups:
References: