Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Robert Morelli <morelli@flux.utah.edu>]

Richard Jones wrote:
> On Mon, Oct 20, 2008 at 09:45:34AM -0600, Robert Morelli wrote:
>   
>> What Emacs lisp does wrong is virtually a checklist of bad programming 
>> language design. On the
>> other hand, these are all of the things languages like OCaml do right.
>>     
>
> It'd be interesting to hear[1] what exact features of elisp are
> counterproductive for large-scale collaborative programming.
>
> I've not looked very closely at elisp, but assumed the reason that
> emacs remains "unconfigurable" for most users is because it's Lisp,
> not because of the particular dialect of Lisp.  Most programmers look
> at Lisp and run a mile, and I don't think an OCaml editor will fare
> much better if that is the case.
>   

Because of its poor design, I lost the heart to try to program complex 
tasks in Emacs lisp quite
a while ago, so I don't have everything fresh in my mind. Perhaps Peng 
Zang who posted
in this thread about more recent work can comment on his experience. Let 
me point out that
Peng Zang's experience of withholding his code because it wasn't quite 
finished is very typical.
Unfortunately, Emacs lisp code is never really done. It's always in this 
not-sure-this-is-right
state, exactly the kind of murkiness that people who favor languages 
like OCaml hate.
I have done the same thing, withholding code. Ironically, it's probably 
often people with decent
programming standards who withhold their code, with the effect you can 
surely predict.

As far as the problem being a dislike of lisp, no. I'm more of a static 
typing kind of guy, but good
implementations of Scheme are certainly respectable languages. Emacs 
lisp falls far short of that.
For instance, it has no true higher order functions, and makes an 
artificial distinction between function
values and data values. For that matter, it has a somewhat wacky 
smattering of types for its data values,
with a lot of redundant parallel functionality that's always getting in 
the way. It uses dynamic rather
than lexical scoping. Emacs lisp has no structured datatypes like 
records (only lists, arrays, and such),
nor even good conventions for how to simulate them.  Scheme dialects 
generally implement record types
with macros using a familiar pattern.  Speaking of macros, emacs lisp 
uses an unsafe kind of macro in
distinction to Scheme's hygienic macros.  There's also no notion of 
namespace in emacs lisp, nor any
concept of modularization, nor of object.  Emacs lisp conflates 3 
distinct notions into the symbol "nil":
the empty list, the false boolean, and the symbol whose name is "nil." 
Emacs lisp programmers
seem to embrace this confusion with zeal, and this is one of the many 
reasons why it's tedious
to translate Emacs lisp code into a higher quality lisp dialect.

Emacs lisp is closer to Common Lisp than Scheme in appearance. In my 
opinion, Common Lisp is an overly
complex language, a bit like the C++ of the lisp world. The philosophy 
of Scheme, which attempts to
boil down the basic language features to the most fundamental but 
powerful building blocks, is a much
more satisfying approach. But while there's a lot of junk and complexity 
in Common Lisp, there's
also quite a lot of powerful features to compensate. Not even that is 
true of Emacs lisp.

In addition to language deficits like these, the standard libraries of 
built in functions in emacs lisp
are quirky, limited, somewhat haphazardly organized, and buggy. And it 
executes in a single threaded
environment, which doesn't play well with gui and network features.

Etc.

It is my opinion that Emacs is so poorly designed, and the existing base 
of Emacs lisp code is of
such low quality, that continuing to build on top of this foundation is 
doomed to produce the same
low quality of software at the same glacial pace as we've seen over the 
past 3 decades. My hope is
that people will in fact stop writing Emacs lisp and somehow, through 
some magic, a sizable community
can coalesce around a more intelligently designed editor platform. As 
always, the issue is the barrier
to entry in a world that's been dominated by two text editors since 
ancient times.

By the way, this message was written in Emacs, the editor I've been 
using for 25 years.

PS: Almost exactly the same pattern of poor quality and glacially slow 
development has plagued the TeX/LaTeX
world over the past few decades and I believe the issue is the same. If 
anything, the foundations of TeX are
even worse than of Emacs. That's another place where someone with an 
understanding of modern language
design could make an enormous contribution.