[openbeos] Re: The world as we know it

  • From: "Erik Jaesler" <erik@xxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 22 Sep 2002 16:39:22 -0700

>> "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx> wrote:
>> That's nice, but if you don't understand why we are aiming for binary 

>> compatibility (well, for you as a PPC user, we don't even do that :-
>> )), 
>> please, just accept it. Be patient.
>I'm supposed to take your word for it?

I'd wager Axel's word is at least as good as yours, and you would have 
us take it for your arguments. =P

>It is nice, consistent, and modern... compared to the MFC. Outside of 
>that, it is actually not particularly consistent (several different 
>error-reporting strategies, inconsistent string formats, inconsistent 
>use of abstract base classes), not particularly nice (Why the heck 
>doesn't BMessage inherit from BFlattenable? And who thought up the type
>-specific data retrieval interfaces for BMessage?), nor particularly 
>modern (other than classes, it displays a complete aversion to all 
>features of C++).


>just need a single person. And would you seriously support keeping the 
>seriously over-extended and generally screwed up API we have now?

What system-wide API are you comparing BeAPI to that it comes out 
looking so bad?  Sure, there are some limitations and decisions which, 
in retrospect, were not very well thought out.  BeAPI is at least 
pleasant to work with, which is a far cry from "tolerable" -- the best 
that *any* other API I've ever worked with has managed.  Nobody here is 
claiming it's perfect; there wouldn't be a point to any of our work if 
it was -- we'd just use R5 and be permanently blissed that we were using 
a perfect OS!

>> > Exactly. Which is why I'm arguing against binary compatibility for 
>> > the 
>> > time being.

This argument is *over*.  Let go of it and move on already.

>Wonderful. That's when I would add a new API too. And we would of 

???  This flies in the face of virtually everything else you've said, 
which has boiled down to "all new/heavily modified API *now*!"

>course keep the R5 version (because of the different ABIs, they can 
>even go in the same shared object).

Now *this* is a really useful idea that I, at least, wouldn't have 
thought of.  What a wonderfully clean way to get the job done.

>Isn't R5 that process, you say? It is indeed. Starting to make R5 is a 
>wonderful place *to begin*. But it is a process that should never be 
>finished. If we succeed in coding R5, we have gained nothing, for we 
>will have copied blindly, without critical examination. Nobody writes 
>code and says: this architecture sucks! or wouldn't it be nice if I 
>could...? There are terrible design decisions in R5. There are places 
>crying out for new architecture. There are great gaps in the API. But, 
>in cloning, we ignore them. True, we see the errors, and correct them, 
>in fits, with individual routines and modules, but not on a large 
>scale, and, as a result, I am afraid that we may succeed in cloning R5. 

>And nothing worse can happen to this project that to have spent all the 

>time and effort we will have spent when we are done without seeing what 

>it is that we are making.

Are we somehow giving people the impression that we are as dull and 
unintelligent as this paragraph would make us seem?  I hardly think we 
would be capable of achieving our stated goals were that the case.  
Perhaps you merely suppose we are incapable of seeing the "big picture" 
of the system-wide architecture.  Interesting that you are able to draw 
this conclusion without the benefit of being included in all of the 
private communications that inevitably go on between team members.  Let 
me set your troubled mind at ease: we are well aware of the limitations 
of the system and are, even now, plotting their demise.  All things in 
their own time, etc., etc.  Indeed, the scope of our perception extends 
well beyond the mere architecture of the system to include the 
applications which rely upon it and further to the users who rely upon 
the applications.  Those considerations have ramifications on our work 
on the system itself; ramifications which, to one who is not looking 
further than the system, might seem acts of self-limitation or sabotage. 
 This is an organic process and environment, and as such it will never 
be perfect, only a careful balance between all of the competing 

If you choose to continue to ignore the wider scope, what you bring to 
the table will become increasingly irrelevant.  Already, you are 
spending time arguing against decisions which were made nearly a year 
ago and are effectively cast in stone.  There is no profit in this 
course and I, for one, find it curious that you insist on pursuing it.


Necessity is the plea for every infringement of human freedom. It is the 
argument of tyrants; it is the creed of slaves.
        -William Pitt, British prime-minister (1759-1806)

Other related posts: