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.6 required=5.0 tests=AWL,DNS_FROM_RFC_POST, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL 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 1A036BBAF for ; Tue, 21 Oct 2008 04:22:26 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBACDa/EhC+VLokGdsb2JhbACTMj4BAQEBCQkMBxEDp0gId4ZrAQMBA4NNgUA X-IronPort-AV: E=Sophos;i="4.33,455,1220220000"; d="scan'208";a="16301278" Received: from wx-out-0506.google.com ([66.249.82.232]) by mail2-smtp-roc.national.inria.fr with ESMTP; 21 Oct 2008 04:22:25 +0200 Received: by wx-out-0506.google.com with SMTP id s6so1332560wxc.15 for ; Mon, 20 Oct 2008 19:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:cc:references:in-reply-to:content-type :content-transfer-encoding:content-disposition:message-id; bh=YtU+7kC4UNfoTmKOA7G3Kka1JWDlc9g0u9OKNQAuIsM=; b=kajZ5lsdy7tPBS+Ar6VIW0ZRYIb6O3bwYaCBythetDw17MRsryN092CrgEjt16V3Kf gYYQJMiXPB5YkDfbwBoPWsHj9vIUoJqfqwDfPFSPK+9E1LTO/RA8p5SDKBiZw246bL3Q 84wZ2rV/bcYJeNoe1jtaKm7IG8jXy4qsgev/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to :content-type:content-transfer-encoding:content-disposition :message-id; b=I2uJg8keS6T1schiM4vIJsbxXHAHzglBuhqAjSV1qz+AsBeJ8RSDGQFk93PTt/sJoh xxV3QL80akpGtpA7veOJrvtVqfospQ+Jnwf1Olx0zoPzoGMxnPwPYP973dwI870iAIRj IrbgprsJFOZApdcYcPRlICarV83EHamVYUq6A= Received: by 10.70.72.11 with SMTP id u11mr9503382wxa.70.1224555744165; Mon, 20 Oct 2008 19:22:24 -0700 (PDT) Received: from ?192.168.0.102? (c-24-99-180-210.hsd1.ga.comcast.net [24.99.180.210]) by mx.google.com with ESMTPS id s40sm7316156hsb.9.2008.10.20.19.22.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Oct 2008 19:22:23 -0700 (PDT) From: Peng Zang Reply-To: peng.zang@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] What does Jane Street use/want for an IDE? What about you? Date: Mon, 20 Oct 2008 22:22:18 -0400 User-Agent: KMail/1.9.7 Cc: Robert Morelli , Richard Jones References: <200810200919.41561.ober.14@osu.edu> <20081020201522.GA13893@annexia.org> <48FD0E16.9030404@flux.utah.edu> In-Reply-To: <48FD0E16.9030404@flux.utah.edu> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810202222.21091.peng.zang@gmail.com> X-Spam: no; 0.00; hash:01 morelli:01 emacs:01 emacs:01 ocaml:01 haskell:01 datatypes:01 arrays:01 simulate:01 scheme's:01 beginner's:01 ocaml:01 bug:01 peng:98 peng:98 -----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-----