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

[Peng Zang <peng.zang@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 20 October 2008 07:02:46 pm Robert Morelli wrote:
> 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.

Let me first say that I've never written anything large in elisp, so take my 
views with a grain of salt.

I think for small extensions (eg. SOLID) elisp is fine.  Certainly it's not 
the best language, but it's better than writing C or Java, more fun than 
python and more straightforward than haskell.  A couple things bother me 
about it which I'll explain in more detail later.  The overall point is that 
elisp as an editor extension language is satisfising.  My reason for not 
announcing my code is that I developed it to scratch my own itch.  Thus, as 
soon as it worked "well enough" I stopped working on it.  I've always meant 
to make it more robust, write down its assumptions and requirements and 
document it for the benefit of the community at large; however, as perhaps 
many of you have experienced, "things come up".  There's always a fire to put 
out, a paper deadline to meet, research to be done, etc...

As to lisp, well, I like the idea of lisp.  This includes dialects from scheme 
to sbcl to elisp.  The main issues that have irked me about elisp are the 
same ones that irk me about common lisp in general, eg. dual namespace (one 
for functions and one for values).  This was a stupid idea and it's 
irritating.  Lack of a good standard library is another complaint that I 
have.  But what can you do?  Elisp is a CL dialect.  Elisp's main 
differenciating aspect is dynamic scoping.  While for general programming I 
think it is a bad idea, for a DSL aimed at extending an editor, I have found 
it to be fantastically useful.  There may be a safer way to do the things 
elisp lets you do.  If there is, I would love it.  Unfortunately though, I 
haven't found an editor that has it.  In the mean time, Emacs remains the #1 
most extensible, configurable, and flexible editor I know.

In summary, elisp is fine for small things... better than many in fact.  I 
might even go out on a limb and say for really small things, it's really 
great.  It's not a great language though, and it has plenty of room for 
improvement.

Peng




> 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.
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFI/TzdfIRcEFL/JewRAmL7AJ0Q1QkkfGaAlKh2/U6UW5m8qAackwCePLK3
neR4MfWIKfitc8xYnIeQtK4=
=9Jl2
-----END PGP SIGNATURE-----