From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=DNS_FROM_SECURITYSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id C53B8BBAF for ; Tue, 21 Oct 2008 01:02:55 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsDAECr/EjAXQImgWdsb2JhbACTbwEBFiKoeIVGX4Ns X-IronPort-AV: E=Sophos;i="4.33,454,1220220000"; d="scan'208";a="16299180" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 21 Oct 2008 01:02:55 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9KN2sUp029907 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 21 Oct 2008 01:02:55 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgBAECr/EhMYB4oimdsb2JhbACTbwEBAQoJDAcPqHqFRl+DbA X-IronPort-AV: E=Sophos;i="4.33,454,1220220000"; d="scan'208";a="18316274" Received: from qmta04.emeryville.ca.mail.comcast.net ([76.96.30.40]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Oct 2008 01:02:53 +0200 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id UzVH1a0031GXsucA4B2rGf; Mon, 20 Oct 2008 23:02:51 +0000 Received: from marco.local ([76.27.101.53]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id VB2m1a00h197JVY8TB2ntk; Mon, 20 Oct 2008 23:02:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=wbvPL8zYWWEA:10 a=FD5j4xppBqwA:10 a=xXa-sITrcidYWt4xAUYA:9 a=ccAEp4Xcbyz_-5ri4eEA:7 a=ZWHCV61Mtjt1utq98VVxqMG3Z3sA:4 a=4iXfik_MsjQA:10 Message-ID: <48FD0E16.9030404@flux.utah.edu> Date: Mon, 20 Oct 2008 17:02:46 -0600 From: Robert Morelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Richard Jones Cc: caml-list@inria.fr Subject: Re: [Caml-list] What does Jane Street use/want for an IDE? What about you? References: <200810200919.41561.ober.14@osu.edu> <20081020133711.GP14123@janestcapital.com> <9722eaea0810200705x50c51160p91f740a806f7ab15@mail.gmail.com> <48FCA79E.7090607@flux.utah.edu> <20081020201522.GA13893@annexia.org> In-Reply-To: <20081020201522.GA13893@annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 48FD0E1E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; morelli:01 morelli:01 emacs:01 ocaml:01 emacs:01 ocaml:01 datatypes:01 arrays:01 simulate:01 scheme's:01 20,:98 mile:98 peng:98 peng:98 withhold:98 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.