Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!husc6!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William E. Sommerfeld)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to SE, part 2
Message-ID: <3860@bloom-beacon.MIT.EDU>
Date: 18 Mar 88 03:29:29 GMT
References: <2586@Shasta.STANFORD.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William E. Sommerfeld)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 75
Keywords: metrics, software engineering

[I revised quotes from the original article to use the correct name
for the X window system]

>So the question is "why wasn't the X window system written in Ada?"  
>(Ouch, Ouch, here come the flames.... ARGH!)
>The design goals of Ada (which the language comes close to) seems to sort of
>match the goals for the X window system.

X started off a lot more like UNIX did than like Ada did: two people
(Bob Schiefler and Jim Gettys) got a hold of some hardware (DEC VS100
graphics _terminals_) which had no software support under UNIX, and
tried to see if they could make the hardware useful.  Some people saw
it, liked it, and it started catching on.  It was ported to MicroVAX,
Sun, Apollo, IBM RT, and numerous other workstations.  Recently, (in
the last year and a half) it has been redesigned and rewritten for
greater portability, just as UNIX, originally written in assembler,
was rewritten in C.

>Instead, X is written in a language
>that is at least fifteen years old, has no standard or compiler validation,
>and has to be stretched to provide the pseudo tasking and pseudo inheritance.

I would guess that you're referring to the X toolkit here, which is
not [yet] formally part of the X standard, and which is admittedly the
weakest part of the current X _implementation_.  The X toolkit does
use inheritance, but it does NOT use tasking (at least in the sense
that I view tasking: several independant threads of control all
running at the same time in the same address space); instead, each
`class' of widgets implements a set of operations, and supplies
pointers to functions which implement these operations.  C++ would
probably have been a better implementation language for the X toolkit;
however, C++ compilers are not (yet) as generally available as C
compilers.

Anyway, back to `X and Ada':

If I understand what I've heard correctly (I'm not sure I believe
it--it sounds like a major deficiency), Ada treats functions as
second- or third-class objects--you can't store a pointer to a
function in a data structure, or pass it as a parameter to another
function.

The current X version 11 `sample' server is heavily dependant on the
use of pointers to functions; the server side of the graphics context
(GC) is implemented as a structure containing pointers to functions
which implement the graphics primitives.  As different parameters in
the GC change (if the font is changed from a variable-width font to a
fixed-width font, or if you change line widths from one pixel to five
pixel, for example), a different procedure can be substituted which
uses a faster, special case algorithm.  This way, the common special
cases (such as fixed height and width nonoverlapping characters in
terminal emulator windows) can be executed much faster, without the
overhead of figuring out what the special cases are for each graphics
operation.  For example, if you wanted to implement circular clipping
regions in the current server, you could do so without slowing down
the 'normal case' of retangular clipping at all.

If Ada does not support functions as objects, implementing the X
server in Ada would probably require an architecture which was not as
easy to extend or port to radically different kinds of graphics
hardware.

On a related note, I believe that Bob Scheifler feels that the `right'
way to develop an interface to X for a language other than C or Common
LISP is to do so at the protocol level, not by trying to interface to
a library which was designed for use from C.  Yes, it's more work, and
you have to spend a lot of time writing procedure stubs (or building a
`stub generator'), but the end result is something which has a much
better fit to the language.  CLX (which is to Common LISP as Xlib is
to C) is probably a good example of this.  While I haven't looked it
all that much, it appears to make the remoteness of the window server
as invisible as possible--for example, you use `setf' to set various
attributes of windows, and the library takes care of converting that
into protocol requests.

				Bill Sommerfeld