Re: Using Emacs Lisp for script writing

[Cecil Westerhof <Cecil@decebal.nl>]

Tim X <timx@nospam.dev.null> 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