Prev: embedding lisp ...
Next: SBCL's internal functions
From: netsettler on 18 Dec 2009 13:03
On Dec 14, 10:42 am, Kazimir Majorinc <em...(a)false.false> wrote:
> Unfortunately, there is a bias
> toward Common lisp:
> ...
>   + Kent Pitman (Common Lisp)
> ...

I can speak only for myself, but you certainly sell me short if you
think that I have only been involved in Common Lisp. I was a co-
author of the RnRS papers for a number of revs of that, was one of the
original designers to T (Yale Scheme), worked on Maclisp, and
Zetalisp / Symbolics Lisp. I implemented a tiny Lisp in TECO so I
could run my Lisp Machine Zmail init file when reading mail in TECO-
based Emacs. I designed a dialect of Lisp that no one will remember
called ULisp that was used for a term teaching at MIT. I have
programmed in a number of obscure dialects of Lisp for brief stints. I
was Project Editor not only for Common Lisp but for ISO ISLISP. I've
studied a number of other dialects I haven't used a whole lot. And
I'm a big fan of Clojure even though I've not had a chance to use it.
So just because you don't personally happen to know any of this, I
think it's a bit of a stretch to say that we're CL biased.

CL is an established dialect, but that doesn't mean our mission in
life is to do everything in procedurally by denying papers or
dominating committees. That means we're a rich source of experience
that can contribute usefully to properly peer-reviewing papers.

I suspect similar histories are true of many of the other reviewers.

I can tell you I've been in only a subset of the discussions of what
papers to accept and have seen absolutely no one raising dialect-
centric remarks as reasons to allow or deny papers. Papers are
addressed at the level of whether there is a clear problem statement,
whether the presentation is clear, whether people have done proper
research about what has come before, whether there is likely to be a
user community that is interested (which has actually worked against
CL programmers in the papers I've seen reviewed, since an awful lot of
stuff is already done in CL and doesn't need to be reworked), and
whether there are novel claims made.
First  |  Prev  | 
Pages: 1 2
Prev: embedding lisp ...
Next: SBCL's internal functions