From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Cecil Westerhof Newsgroups: gmane.emacs.help Subject: Re: Using Emacs Lisp for script writing Date: Wed, 23 Dec 2009 08:38:11 +0100 Organization: Decebal Computing Message-ID: <87hbri16os.fsf@Traian.DecebalComp> References: <87hbrrrl3c.fsf@Traian.DecebalComp> <87vdg09ls9.fsf@Traian.DecebalComp> <878wcw53mj.fsf@lion.rapttech.com.au> <87pr677s4z.fsf@Traian.DecebalComp> <874onj5jxu.fsf@lion.rapttech.com.au> <87ljgv3ymp.fsf@Traian.DecebalComp> <87vdfy4d4o.fsf@lion.rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1261554276 22131 80.91.229.12 (23 Dec 2009 07:44:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2009 07:44:36 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 23 08:44:29 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NNLtU-0001JZ-Fp for geh-help-gnu-emacs@m.gmane.org; Wed, 23 Dec 2009 08:44:28 +0100 Original-Received: from localhost ([127.0.0.1]:40434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NNLtU-0002qp-FT for geh-help-gnu-emacs@m.gmane.org; Wed, 23 Dec 2009 02:44:28 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Original-Newsgroups: gnu.emacs.help Set: dutch X-Homepage: http://www.decebal.nl/ User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Cancel-Lock: sha1:326a+zFrTDhE2NHx6vuRYCfKBcw= Original-Lines: 160 Original-NNTP-Posting-Host: 84.53.123.169 Original-X-Trace: 1261553892 news.xs4all.nl 22917 decebal/[::ffff:84.53.123.169]:26370 Original-X-Complaints-To: abuse@xs4all.nl Original-Xref: news.stanford.edu gnu.emacs.help:175743 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:70819 Archived-At: Tim X writes: >> I'll try to keep that in mind. But compiling the regular expression made >> a big difference. Also, I remember someone telling me that lists are not >> very efficient. What should I use instead? Or will I found that out in >> Practical Common Lisp? >> > I'm always very wary of claims such as lists are not efficient. Lists in > lisp tend to be a lot more efficient than lists in other languages. > However, my main reason for being cautious is that it really depends on > what your doing and what the performance expectations are. While I do > try to develop efficient algorithms and I certainly due try to choose > the best abstract data type for the problem at hand, I frequently start > with a list and then possibly change to some other structure once it > becomes clear the list is not going to be efficient or is going to be > less clear code wise compared to using something else, such as s struct, > array or class. Lists are pretty fundamental in lisp - even the code is > a list of lists. Apart from having an efficient list implementation, > lisp also tends to have a lot of useful functions that work on lists. Lets default stick with lists then and write the code in such a way that it is easily changed. >> With different dialects do you mean different Lisp dialects or different >> CL dialects? The former I think I do not like, the latter is where I >> will aim at. When I write portable code, I can switch to the dialect >> that is best for the situation. > > I was referring to the different lisp dialects rather than different CL > dialects. For example, elisp, scheme, guile, rep and cl are all lisp > dialects. They are similar enough that usually you can understand the > code by just reading it, but they have enough differences that you can > easily get confused when switching between them. I'll stick for the moment with CL and elisp. And when I am 'fluent' in them maybe I'll look at scheme. >>> (though I still find elisp and emacs the best >>> extensible editor and kitchen sink available!) >> >> I agree. For example I am also using GNUS -just as you I saw-. It is a >> lot of work, but I think/hope that when I have GNUS in my fingers, I can >> easily make it do what I want instead of what the developer thought I >> wanted. ;-) >> > Yep, this is the huge benefit of emacs. Its quite amazing what you can > do with it. I use it pretty much for everything. In fact, I have to as It only has a bad press. I once wanted to use it, but everyone told me not to use it because it was 'hard to learn and to use'. Not long ago I started using it anyway and regretted it very much that I listened to other people. :-( > Emacspeak uses a very neat feature of emacs called defadvice. Using I have heard about it, but not tempered with it yet. > etc. It can be a dangerous feature if not used cautiously and it can > create challenges when debugging, but is a very useful feature. Both are very true I think. >>> P.S. Another advantage to CL is that if you plan to share/distribute >>> some of what you are doing, you can compile it to native code. This >>> means people don't even have to know you wrote it in lisp. This can help >>> overcome the considerable FUD regarding CL that exists out there. >> >> That is a good point. But with clisp that does not work as far as I >> know. I tried to install SBCL, but the install process needs Lisp. It >> only mention it to do with SBCL and CMUCL. So that can wait until later. >> > Although I've not done it, looking at the clisp docs, there does appear > to be functionality that will support dumping out the lisp program to > native code. I wouldn't worry about it now, but it probably would be > worth looking at later. I'll not worry about it. Before sharing I first need to get fluent. And I am afraid I still have a road ahead of me. But I think I'll go for SBCL. Compiling to native code looks better to me as dumping to native code. But that is for another day to decide. >> Another question. The BBDB and also the example in Practical Common Lisp >> use lists for the database. Is this not inefficient? Would a real >> database not be better. Not that I want to burn me at the moment on >> databases. ;-) > > Ive used bbdb for years and have a large .bbdb database file. I have > never encountered any performance issues. Actually, bbdb is possibly a > good example of what I was trying to explain above concerning not > worrying about efficiency and performance too much when developing the > code. I have a very small .bbdb, so that was why I was wondering. But I do not need to worry then. The only problem I have with bbdb is that there are no links. Say for example people are part of a certain company. Now I have -as far as I know- to put the general information in every record. With a database the general information could be retrieved from the company record when fetching the employee record. For me that is not a problem, but I think it is a restriction. > I would be vary cautious regarding statements such as lists are > inefficient. Such a statement is a huge generalisation and needs to be > considered in context. Default I'll stick with lists and change it when necessary. > list and will end up with a new linked structure which shares storage > with one of the original lists. Essentially, rather than creating > multiple copies of things, lisps will genrally manipulate the links in a > list to create different representations of the linked atoms that make > up the list. Instead of having multiple copies of the atom, you will > have just one, but it might be pointed to by multiple structures that > represent that atom in different lists. This is why in most lisps you > need to be careful about where you use distructive operations as you > cannot always know what else in the program is sharing some of the > structure. And modifying operations of course. > and the system has few updates/inserts. But a lot of fetching. But that is then proof -because you have a big bbdb- that list are efficient in lisp. > At the end of the day, the real measure of whether it is efficient > enough is user experience. If the user is able to add and update records > and query for data in a time that is acceptable without all available > resources being used and essentially, the system is useful and > beneficial, then the program is efficient enough. Yes and no. I have seen it to many times that a program worked great when the demo was given. But at the moment real data was used, or the data grew above a certain amount, huge problems appeared. But when it is true that in Lisp changing the underlying structure is more easy, then it is not something to worry about. > If you adopt good coding style, changing from one data structure to > another within lisp is usually fairly straight forward. Therefore, my > standard approach is to initially use lists while developing the first > version. If I find that managing the data with lists becomes too coplex > or the efficiency is not good enough, I will change to a new structure. I'll copy you. ;-) -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof