I should be going out, so I got impatient and fired off my message,
and then remembered that part of it could be rather inflammatory and
really should've been rewritten or deleted. Sorry.
On Thu, Mar 07, 2002 at 05:40:06PM -0600, William Harold Newman wrote:
> I'd be mildly reluctant to work with a project that put too high a
> priority on new features (to the detriment of making a basic set of
> features work right), but that's a disagreement I could live with in
> return for the benefits of sharing a common codebase with more
> improvements from more people. To me the more fundamental difference
> between CMU CL and SBCL is that some coding practices that I find
> impractical and distasteful have found a long-term home in the CMU CL
> codebase (e.g. ignoring the principle of "once and only once", e.g. by
> cutting and pasting three copies of the same code to produce gc.c,
> gencgc.c, and purify.c, and never factoring out the common code behind
> some reasonably clean interface). That bothers me enough that I might
> not be motivated to do much work for a project that encouraged that
> kind of thing. (Other people can disorder code much faster than I can
> order it! Or, sharing a codebase with more changes from more people
> isn't a win if the changes aren't improvements...) Someday I may
> abdicate my autocracy of SBCL in favor of some other person or people
> (or AI?:-). And/or I might realize the error of my SBCL ways and join
> a group which has gone off in a different direction from SBCL, e.g.
> some super-expressive future language with all the advantages of Lisp
> plus other advantages, e.g. better compile-time analysis. But in
> either case I'd like to have some confidence that future commits were
> unlikely to increase confusion in in the system I was relying on.
There are all sorts of ways I should've qualified that. Reasonable
people may differ on how much stuff like that should be in the code.
For that matter, I'm responsible for some stuff like that -- not much,
I hope, but some -- in SBCL. And in both codebases lots of bad stuff
-- brokenness in PROFILE, brokenness in PCL::CLASS vs. CL::CLASS,
unsafe handling of stack overflow, broken X86 function end
breakpoints, whatever -- sits around for years not because people are
too aesthetically crippled to realize it's a bad thing, but because
there aren't resources to fix it. My point is not necessarily ooh, the
CMU CL codebase is bad in any absolute way, but that sometimes there's
a mismatch to my (somewhat extreme) priorities about what's an
improvement. I recognize that this and other kinds of disorder can
work surprisingly well, especially in a horses-for-courses way (i.e.
on the right course). Like the famous "Worse is Better" essay, only
along a slightly different axis. Etc.
I wanted to say something a lot more nuanced, and I said something
potentially offensive instead. Oh well. Oh hell. Sorry sorry sorry.
William Harold Newman <william.newman@...>
"1. If you know what to type, type. 2. If you don't know what to type,
take a shower." -- http://www.c2.com/cgi/wiki?UngarMethod
3. If you aren't sure you typed the wrong thing, don't hit the send key.
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C