Re: packages with binaries
Stephen J. Turnbull writes:
Attachment thumbnails in the MIME buttons and the message history
buffer. The former I guess you can't avoid these days, but there
should be a way to turn them off -- they're slow and buggy (the bugs
may be in the external helper programs used, but PDF files are
frequently misparsed as PNG for some reason, and it blows everything
up). The latter doesn't seem at all useful to me, and having it pop
up by default was a huge mistake.
Yeah, both good examples! Some of the mess is because, when Kyle Jones
became inactive, there was a bit of a free-for-all in the VM community. Rob
Fenk had the attitude that the more the better. Recall that Rob had a
separate distribution of VM, called "vmrf", which eventually became VM when
Kyle handed control over to Rob. So, there are a lot of these "contributed"
features that I wouldn't have put into VM if I had anything to do with it at
the time.
After I took over, I established the defining principle that "VM" means what
is described in the VM manual and all the other stuff is a collection of
"add-ons". The current codebase describes each file in the VM distribution
as either being "part of VM" or "add-on for VM". The message-history
stuff
is an add-on, and you have to explicitly plug it in by adding invocations in
your .emacs or .vm file, which I suppose you did! The thumbnails are a part
of core VM, but I have added a way to disable them. (Set
`vm-mime-thumbnail-max-geometry' to nil.)
In any case, I am aware of these kind of issues and do some cleaning up as
and when I get around to them.
Sure, but Lisp, even Common Lisp, is very syntax-poor as a language.
What ends up happening is that developers end up creating their own
syntax with defmacro or define-syntax depending on your preferred
method of suicide-by-spaghetti. So, I'm not interested in syntactic
structure of individual functions (which tends to be pretty simple
anyway); I'm interested in the call graph.
If the call graph is not semantic, what is?
I think I am using "syntactic" more broadly, as everything to do with the
program text. That includes the division of the code into functions and
modules etc. So, all modularity is "syntactic" in this sense. However, any
information hiding that is obeyed at run-time is "semantic", irrespective of
whether it is represented in the program structure.
What I mean by "semantic" is the trace of all the primitive operations that
get done during an execution. The call graph is close to this, but it is
still dependent on the program structure because the functions that get
"called" are syntactic. If the functions were badly chosen, then the call
graph doesn't tell us much useful.
A piece of software is good semantically if it is doing the right sequence
of operations in the right order. It is modular if the information flow in
the trace can be easily discerned and is natural. If the system is good in
this way, we can refactor the code for better modularity, and everything
will continue to work fine. But if the software had bad semantics to start
with, I believe that no amount of refactoring will fix it.
If you will indulge me, I can suggest some visual imagery. Think of all
(the instances of) primitive operations as grains of sand. The code is the
mason that assembles these grains into a nice castle that the user will
enjoy using and the maintainers will enjoy tweaking. The beauty of the
castle is an entirely separate issue from the beauty of the mason. If the
mason is good-looking, I wouldn't complain, but if the mason is unkempt, it
wouldn't bother me much either.
I believe that the traditional software engineering confuses the mason for
the castle. Whether it has any idea of the castle at all is questionable.
(The Distributed Systems people seem to understand this though. They often
talk about the trace semantics, and totally ignore the syntax. The
Programming Methodology people are quite the opposite.)
I don't want to "tweak and see what happens". I want
to design, and
see the code do what I designed it to do.
I am not saying you should tweak it to see what happens. But the acid test
of your design is whether it can be tweaked in the future without making it
fall apart. "Seeing the code do what you designed it to do" is a short-term
goal, but that is not good enough, is it? Long-lived software needs to be
maintainable.
Clear structure in the
surrounding code makes that a lot more likely to happen (although
you're right, it's always possible to write code that will fall
apart, and I've done it often enough myself even with the help of an
excellent existing infrastructure to fit my code into).
Yes, "likely" is the operative word here. It is not guaranteed. Neither is
the opposite guaranteed. In other words, even if there is no clear
structure in the code, it is possible to have clear structure in the
semantics. Of course, you average Joe Programmer may not be able to achieve
it. But Kyle Jones could.
I have no idea what you mean by "logical coherence" when
you refer to
VM's code, except that people who work a lot on VM are able to add new
features without breaking old ones. But looking at the code itself, I
see things like:
...
Code related to message threading is scattered all over the code base.
That doesn't strike me as logical or coherent. AFAICS, the vm-thread
library should get a list of messages, and use that to generate and
maintain a tree structure that vm-summary can present to the user.
What are the other 16 files doing in that list?
vm-thread.el builds the threads database for folder, which can then be used
by all other modules. For instance, vm-motion.el uses it to go to a parent
message. vm-delete.el uses it to delete a message along with its
thread-subtree and so on. But the internal structure of the threads
database is exclusively handled inside vm-thread.el, which is the way it
should be.
I can't imagine that this is the only example of excessive
coupling in
the codebase, although I admit threading is what I've been working on
most.
Oh, that is good to know. The threading code had lots of subtle bugs, which
took me ages to fix. In fact, I now regard the threads database as a
challenge problem for programming theorists like me. I hope you now have at
least a reasonably correct code base to work with.
Cheers,
Uday
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta