Re: Python Emacs (was Re: The <word>.<word>.<word> rule)

[Brian May <bmay@csse.monash.edu.au>]

>>>>> "Eric" == Eric S Johansson <esj@harvee.billerica.ma.us> 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 <bmay@csse.monash.edu.au>