From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/31049 Path: main.gmane.org!not-for-mail From: Brian May Newsgroups: gmane.emacs.gnus.general Subject: Re: Python Emacs (was Re: The .. rule) Date: 18 May 2000 10:10:11 +1000 Sender: owner-ding@hpc.uh.edu Message-ID: References: <00May12.111709edt.115683@gateway.intersys.com> <200005121547.RAA12153@marcy.cs.uni-dortmund.de> <200005172027.WAA16517@marcy.cs.uni-dortmund.de> <019e01bfc047$07748130$0500a8c0@rufus> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035167504 11852 80.91.224.250 (21 Oct 2002 02:31:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:31:44 +0000 (UTC) Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by mailhost.sclp.com (Postfix) with ESMTP id 71F92D0520 for ; Wed, 17 May 2000 20:10:49 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id TAB12758; Wed, 17 May 2000 19:10:47 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 17 May 2000 19:10:05 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id TAA05313 for ; Wed, 17 May 2000 19:09:52 -0500 (CDT) Original-Received: from lyell.csse.monash.edu.au (lyell.csse.monash.edu.au [130.194.64.41]) by mailhost.sclp.com (Postfix) with ESMTP id 48A00D0520 for ; Wed, 17 May 2000 20:10:13 -0400 (EDT) Original-Received: by lyell.csse.monash.edu.au (Postfix, from userid 3752) id 20276F5E5; Thu, 18 May 2000 10:10:12 +1000 (EST) Original-To: ding@gnus.org X-Home-Page: http://www.csse.monash.edu.au/~bmay/ In-Reply-To: "Eric S. Johansson"'s message of "Wed, 17 May 2000 17:29:47 -0400" Original-Lines: 54 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:31049 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:31049 >>>>> "Eric" == Eric S Johansson writes: Eric> all they are asking for use for the tool to accommodate Eric> their current knowledgebase. Lisp has an perceived Eric> extremely high learning curve. When people are trying to Eric> solve a problem with a tool, the last thing they want to be Eric> told is that they need to discard what they know and learn a Eric> new way of thinking. My main dislike of LISP, is in my experience LISP programs seem rather fragile and not robust compared with other programming languages. When something goes wrong with a LISP program, more often then not, I get a LISP error that means nothing to me. I send bug reports, etc, but most of the time never get any response or nobody is able to help me. (No offence to the people who *do* try to help). I can only conclude that it is harder to write and maintain robust programs in LISP compared with other languages. I suspect part of the problem, is that there might be tight bindings between independent components. ie implement A, then fix problem B, and accidently break A, without any warning unless it A is specifically tested again. Take, for instance, the mml-narrow-to-part command, M-m n, in gnus message mode, "Symbol's function definition is void: mml-narrow-to-part". Perhaps this has never has been properly implemented. Or perhaps, something happened to break it. I don't know. As another example, take the revision history of Gnus. Sure, it is Beta, but when you consider the new bugs which have been introduced since 5.8.0, I think it is significant. eg MIME attachments recently breaking. Note to mention downright weird behaviour that people often complain about. Sure, some of these are user errors (eg the user sharing the same directories for multiple back-ends), while others are gnus errors (eg duplicate groups appearing). However, all these small things, in my mind, add up to mean a fragile program, that must be used exactly as intended, or you risk data loss. I have had similar problems with other LISP code that I have used in the past. This isn't meant to undermine the efforts that anybody has made in maintaining any of these programs in question. To be honest, yes, I have seen a number of problems in beta perl code, such as "Uninitialised variable" warnings, but in practise, the program seems to work fine, regardless. -- Brian May