For many a year, I've been programming solely in Lisp, Scheme and ML.
I've recently had the occasion to modify a piece of X code, and was
utterly shocked by the experience. Please allow me to publish the
following, slightly off topic, rant.
This would perhaps be better suited to comp.lang.c, but I feel like
gathering some sympathy.
----------------------------------------------------------------------
Why is X not written in Lisp?
or
C, man, C!
Chapter 1. Ground values.
Consider the following code:
(setf (font-properties xf) '(:fontname "FOO" :pointsize 5))
A first attempt at a translation into X idioms gives:
xf->info.nprops=2;
xf->info.props=xalloc(xf->info.nprops*sizeof(FontPropRec));
xf->info.props[0].name="FONTNAME";
xf->info.props[0].value="FOO";
xf->info.props[1].name="POINTSIZE";
xf->info.props[1].value=5;
You'll notice the convenient syntax and flexible representation. But
as we don't have exceptions (signals) in the language, we need to
check every return value /pedibus calcantibus/:
xf->info.nprops=2;
if((xf->info.props=xalloc(xf->info.nprops*sizeof(FontPropRec)))==0)
return BadAlloc;
xf->info.props[0].name="FONTNAME";
xf->info.props[0].value="FOO";
xf->info.props[1].name="POINTSIZE";
xf->info.props[1].value=5;
You'll notice the elegant manner of adding an error value to a data
type by overloading 0. As we have no dynamic typing or usable sum
types (did I hear `union'? are you kidding?), we intern the strings
and use integer handles.
xf->info.nprops=2;
if((xf->info.props=xalloc(xf->info.nprops*sizeof(FontPropRec)))==0)
return BadAlloc;
xf->info.props[0].name=MakeAtom("FONTNAME");
xf->info.props[0].value=MakeAtom("FOO");
xf->info.props[1].name=MakeAtom("POINTSIZE");
xf->info.props[1].value=5;
We are now unable to distinguish between string handles and bona fide
integers. We therefore introduce another array.
xf->info.nprops=2;
if((xf->info.props=xalloc(xf->info.nprops*sizeof(FontPropRec)))==0)
return BadAlloc;
if((xf->info.isStringProp=xalloc(2))==0)
return BadAlloc;
xf->info.props[0].name=MakeAtom("FONTNAME");
xf->info.props[0].value=MakeAtom("FOO");
xf->info.isStringProp[0]=1;
xf->info.props[1].name=MakeAtom("POINTSIZE");
xf->info.props[1].value=5;
xf->info.isStringProp[1]=0;
Unfortunately, if the second allocation fails, there's a memory leak.
We could store on a stack the values to release in case of failure,
but that would involve more allocation, which would... We give up on
this idea, and write the more C-like:
xf->info.nprops=2;
if((xf->info.props=xalloc(xf->info.nprops*sizeof(FontPropRec)))==0)
return BadAlloc;
if((xf->info.isStringProp=xalloc(2))==0) {
xfree(xf->info.props);
return BadAlloc;
}
xf->info.props[0].name=MakeAtom("FONTNAME");
xf->info.props[0].value=MakeAtom("FOO");
xf->info.isStringProp[0]=1;
xf->info.props[1].name=MakeAtom("POINTSIZE");
xf->info.props[1].value=5;
xf->info.isStringProp[1]=0;
Which, of course, means that if we add some code that allocates data
earlier on, we have to manually update all the emergency
deallocations. Oh, well!
At this point, the reader is advised to consider the initial Lisp code
again:
(setf (font-properties xf) '(:fontname "FOO" :pointsize 5))
and notice how much more explicit and simple the C code is.
(Chapter 2, ``Closures,'' fails to get written as author collapses,
hysterically sobbing, when thinking of the amount of manual
lambda-lifting he had to do.)
----------------------------------------------------------------------
The sad thing is that the X sources clearly show that the authors knew
Lisp. Morality: you might know Lisp, but you're bound to reinvent
it. Badly.
Sincerely yours,
J. Chroboczek
Juliusz Chroboczek wrote:
>
> For many a year, I've been programming solely in Lisp, Scheme and ML.
> I've recently had the occasion to modify a piece of X code, and was
> utterly shocked by the experience. Please allow me to publish the
> following, slightly off topic, rant.
>
> This would perhaps be better suited to comp.lang.c, but I feel like
> gathering some sympathy.
>
> ----------------------------------------------------------------------
> Why is X not written in Lisp?
>
> or
>
> C, man, C!
>
> Chapter 1. Ground values.
>
> Consider the following code:
>
> (setf (font-properties xf) '(:fontname "FOO" :pointsize 5))
>
[snip - page upon page of note-quite-as-effective C code deleted]
>
> The sad thing is that the X sources clearly show that the authors knew
> Lisp. Morality: you might know Lisp, but you're bound to reinvent
> it. Badly.
(ROFL) Well, you certainly have my sympathy. I've written production-quality
embedded expert systems in Pascal and C++ because "no one would be able to
maintain them" after my departure if I had written them in Lisp. More than
one manager has learned the hard way that it's all about the complexity of the
problem, not the syntax.
>
> Sincerely yours,
>
> J. Chroboczek
In article <·················@teleport.com>, ········@teleport.com wrote:
> (ROFL) Well, you certainly have my sympathy. I've written production-quality
> embedded expert systems in Pascal and C++ because "no one would be able to
> maintain them" after my departure if I had written them in Lisp. More than
> one manager has learned the hard way that it's all about the complexity of the
> problem, not the syntax.
This is a very current problem. I believe, but can't prove, that I recently
(read: within the past week) lost a contract to help a local Sony
Playstation developer by developing a tool to convert Nichimen 3D models to
a form usable by Sony's tools. Now, Nichimen had purchased a series of
modeling, painting, and rendering tools from... Symbolics, the old Lisp
machine people, and nowadays offer both Lisp and C++ APIs to the tools. I
was talking about writing in Lisp, and the friend who got me in the door
wanted me to write in Lisp, but this guy was also concerned about anyone
being able to maintain the code once I left. Nevermind that the project in
question is months late on the schedule, nevermind that I could write the
thing four or five times as fast in Lisp as in C++ due to memory management
issues alone, and, as you point out, nevermind that the nature of the
problem--in this case, reorganize a graph of nodes (vertices? surfaces?) so
that it can be traversed in a single pass--just *screams* for a Lisp
solution.
Oh well. We'll find out where they are in another few months...
> > Sincerely yours,
> >
> > J. Chroboczek
Paul Snively
<············@mcione.com>