Lars Wirzenius: September, 2003
- September 27: Snake eyes, New Maintainer process, Drag and drop struggle, AVL trees, data structures, comp.lang.lisp
- September 16: let, Windows harms the whole Internet, Naming free software programs
- September 15: University of Helsing rules for net presence
- September 12: Google placement
- September 11: Epiphany 0.9.2
- September 7: Weeding out spam from mail archives, 1.0.3, Killed cut/copy/paste, dnd trouble, Gnome Iagno plays badly, Gallery installation failed
- September 6: Daredevil
- September 5: I hate remote programming and debugging, Setting up server for friends
- September 4: Insecure computers OFF the Internet!
- September 3: Programming language implementation bloat
- September 1: Birthday, Lack of profiling tools
Saturday, September 27, 2003
Watched Snake eyes again from DVD. It's been a couple of years since the previous time, and I had forgotten more or less everything about the movie, except for a slight feeling about not liking it very much. I think the reason for that feeling is that the main character, played by Nicholas Cage, is not a very nice person. Corrupt policemen generally aren't. (That's not a spoiler, since it becomes evident a few minutes into the film.)
Otherwise the movie is pretty good, actually. The story is not totally obvious from the start, the photography is competent, the acting is not distracting, and so on. Nothing really spectacular, but definitely not bad.
It took much too long, but I've finally read all the archives of the debian-newmaint mailing list. I'll just refresh myself on the new maintainer process web pages, and then I'll offer myself as an application manager.
I continue to struggle with implementing drag-and-drop properly in Lodju. I'll have to concentrate on it for a day to get, this is getting ridiculous.
Cessu added primitives for AVL trees this week. They have made our dictionary data structure tens of times faster than even the most optimized versions written in pure Lisp. This helps some of our applications significantly.
I added simple functional queues to the library. We've implemented queues in a few places in several applications, usually badly. Since functional queues are so simple to do reasonably well, putting them in the library is long overdue. At least six months overdue.
I made the first release for almost two months. All Hedgehog releases are internal to Oliotalo for now, so I can't point you at a tar ball. Hopefully one day we can make Hedgehog free software; right now we're concentrating on making the company profitable.
It seems that Hedgehog was mentioned on comp.lang.lisp for the first time in August. This would be thrilling, except the mention basically said he couldn't find any information. Of course, since we aren't making public releases, there's little point in discussing Hedgehog on public newsgroups.
Tuesday, September 16, 2003
I got fed up with the lack of a
construction in Hedgehog Lisp, so I wrote a couple of macros
to make one. Now I can write code like this:
(let foo 1 bar (+ 2 3) (do (pr "sum: " (+ foo bar)) (pr "product: " (* foo bar))))
Cessu suggests an alternative syntax, however:
(let ((foo 1) (bar (+ 2 3))) (pr "sum: " (+ foo bar)) (pr "product: " (* foo bar)))
Cessu suggestion follows more closely the Lisp tradition,
I think, but I find my version clearer due to the fewer number
of parentheses, even if it does force use of
I've been experimenting with my syntax today, writing code that uses it, and I'm happy. I suspect I'd be happy with Cessu's syntax as well. The important point here being that it becomes rather much easier to do calculations in many steps and naming intermediate results with auxiliary symbols.
I was going to write yet another whining rant about Windows viruses disturbing the whole of the Internet, and the immorality of attaching machines to the Internet without the least amount of security. But what's the point?
I rather think free software authors should spend a bit more thought on naming their programs. For example, Gallery is a nicely descriptive name, but how easily are you going to find it on the web?
I don't think descriptiveness is a major concern when choosing a name. I've tried it a couple of times. My GUI editor got a descriptive name: Simple editor for X. Unfortunately, this resulted in an acronym that many people find amusing. More importantly, just try to look it up in a search engine.
Looking up prospective names with search engines is also important to avoid name clashes. There are now so many software projects, free and non-free, that most of the more obvious names are pretty much uses up. Using the same name as someone else can be embarrassing, and can also be a legal problem: trademarks are valuable property and violating them can result in letters from lawers. Even if no actual court case happens, and you only have to rename your own project, it is an unnecessary annoyance and embarrassment.
Be creative! The name space is infinite, there is no need for name clashes.
If you're having trouble coming up with a good name, expand your horizons a bit. Try obscure cultural references, or little known languages such as Finnish or Sanskrit. If you're desperate, run pwgen in a loop until it comes up with something that is somewhat pronounceable and gives few hits on google.
Monday, September 15, 2003
I just had a peek at the new rules for appearance of the University of Helsinki net presence: things like how web pages should look, and what domain names should look like, and so on. I'm very happy I don't have anything to do with the university anymore. The rules have been designed by some ad agency, and they are totally incompetent. I grant that the pages look nice - if you have the right browser settings.
I though the web was moving away from things like forcing the page to have a certain pixel dimensions. These rules specify the width of a page in pixels. Elements within the page, such as boxes that contain text, are also specified pixels. Fonts are specified in pixels. Therefore, if I have a high resolution (many pixels per millimeter), the text will be smaller on my screen. If I use the zoom feature in my browser, which makes text larger, it overflows the box it is designed for. This is gross incompetence in web design.
They also strongly recommend a signature for mails that is more than twice the size of the netiquette limit of four lines. More incompetence.
I have the feeling that ad agencies still don't get it that the web simply is not a brochure. This simple fact seems to be so difficult for them to grasp that they should be taken out and shot, out of mercy.
I can't give you a link to the PDF with the new rules. Apparently the university no longer believes in publishing things and has hidden the PDF so that it can only be seen from within the university's network.
Friday, September 12, 2003
I just noticed that I'm currently the tenth hit on Google when searching for "Lars". Oh the burden of fame.
The reason for this is probably that home page is referred to on many pages in Debian, and Debian's pages are linked to by so many people that anything mentioned there gets a boost by Google's algorithm.
That might be a good reason for companies to sponsor people to become Debian developers, actually.
Thursday, September 11, 2003
I tried Epiphany 0.9.2, the web browser, after reading today that it will be the default browser in Gnome 2.4. I've been using Galeon for quite some time now. Epiphany seems about par with Galeon (I'm currently using 1.3.7), in a couple of hours of usage. The only two things that I didn't like about in Epiphany were a lack of an option to forget all cookies whenever the browser is closed, and no tab completion in the URL entry box. The latter proved to be a killer for me: I'm so used to it in Galeon that it's lack in Epiphany is quite disturbing. I could easily unlearn the tab completion habit, but it is so convienient I don't want to.
I know Epiphany 1.0 has just come out, but it hasn't been packaged for Debian yet. I don't know how close it is to 0.9.2.
Sunday, September 7, 2003
I've spent several hours of yesterday and today weeding out spam from two years' worth of mail archives. The archive is now some fifty or sixty thousand messages smaller, which is nice. I reclaimed some disk space as well. I guess I could have spent the hours more productively by hacking, but I didn't feel very energetic, and this was better than watching IRC and feeling numb.
On the other hand, I could have been reading a book.
Made a new release, 1.0.3 of EoC. A most embarrassing, though non-fatal bug fixed.
Hacked some on Lodju today. Ripped out the cut/copy/paste code, since it was a kludge, and had broken as well. It needs to be replaced with something that supports the Gtk clipboard API.
Drag and drop also has some trouble: it loses the actual image and the thumbnail, and only transfers the meta data. It works within the same document, since the identifier for the image stays the same. I think. It needs to be investigated.
My current plan for transferring the image data when drag and dropping to another document is to base64 encode and put it inside the XML part that is transferred through the drag-and-drop protocol. This means huge amounts of data transfer, but I can't see a way around it, since the source and the target may run on different computers. (I'll optimize it for the more common case of things happening in the same instance of Lodju, of course.)
For a few weeks now, I've been playing Gnome Iagno whenever I've felt like relaxing my brain completely. As I wrote on August 16, the current version of Iagno has a bug that makes it stop playing occasionally, and so I've been playing it only on the lowest level. This suits me fine: if I want to exercise my brain, I make programs. Playing Iagno has become an almost completely reflexive thing, something my hands do autonomously, without my brain being involved at all. A bit like reading Usenet.
My brain mostly kicks in when it notices that I may be winning by taking away all of the computers chips. For a lark, I've been saving screenshots of such wins. Lately, though, it's become rare to get a new screenshot, since most such games end with a score I already have a shot of.
Tried to install Gallery, a PHP thingy for making on-line galleries, on the prototype ISP server. Everything went well until, except it took ages to upload and process a single photograph, and then it wouldn't even show it to me. The files on disk seemed perfectly OK, though. I probably screwed something up while configuring, but I didn't want it badly enough to debug it, so I just removed the whole thing instead.
On the other hand, I've seen Gallery in operation on a number of other sites, and it seems like a decent enough application. I'm thinking Lodju should support it, by being able to export files in a form that Gallery will accept with the least amount of trouble. Possibly even creating captions in Lodju and having Gallery understand them, as well. We'll see.
Saturday, September 6, 2003
Watched Daredevil from a rented DVD. Didn't like it. The plot is OK, and in fact better than I had expected. Almost comparable to the best Daredevil comic book story I've read, by Frank Miller. The acting, however, was unexpectedly bad, and the real meat of the movie, the action scenes, were outright lousy: they felt much too fake for a big budget Hollywood movie.
On the other hand, this movie further confirmed my suspicion that it is only possible to make good movie adaptions of superheroes if I liked the comic books when I was a young teenager. Particularly since I only like two: Batman and Spiderman. I'm so clairvoyant, I should play poker.
Friday, September 5, 2003
If there is one thing I hate about my current job, it is when we do remote programming and debugging. The current situation is that our application listens on certain events in a vehicle, and reacts to them, and the reaction time is too slow. We've never seen the vehicle, and need to rely on telephoned reports from a customer representative. This is prone to errors, prone to misunderstandings, and quite slow. Extremely aggravating.
I set up a new server at home for other people to use.
In my circle of friends, there are several who would like to have a traditional Unix server, where you log in and do stuff (read mail and news, mostly, possibly IRC under a screen instance) and keep your web pages. They have this from their university, for now, but are looking for other places, for various reasons.
They could set up their own server at the end of an ADSL pipe, but it requires effort and know-how they might not have. Lynoure, Killeri, and I got the obvious idea that we could help them by setting up a server for them.
We plan to keep things simple, and concentrate on simple basic services that just work. There will be a small monthly fee involved. Partly the fee will cover use of bandwidth and electricity, partly it will go into saving for eventual hardware investments, and partly it is compensation for the efforts. Rich we won't be, but I'll be happy if I can get a nice restaurant meal per month out of this. On the other hand, if there is not enough interest, and we stop doing this, then there's no harm done, either.
We're now in the prototype stage: the server is up and running and has a couple of test users who are willing to try things out and tell us of any problems and wishes they have. After a few weeks of this, we can decide whether we want to do this for real. It will be interesting.
Thursday, September 4, 2003
While I came to work today and had a chat with my boss (a total time of about 90 minutes), I received 39 mails that bogofilter automatically and correctly classified as spam or other trash. They have a total size of 3.2 megabytes and most of them are actually sent by viruses trying desperately to invade my system. Windows viruses. The kind that has zero chance of affecting my system. Blech.
People who aren't capable of keeping their computers virus free shouldn't connect their systems to the Internet. This seems to include tens of millions of Windows machines and users. Blech.
Wednesday, September 3, 2003
I found Hints for programming language design by C.A.R. Hoare on the web. (I forgot the URL, sorry.) He writes:
There is another argument which is all too prevalent among enthusiastic language designers, that efficiency of object code is no longer important; that the speed and capacity of computers is increasing and their price is coming down, and the programming language designer might as well take advantage of this. This is an argument that would be quite acceptable if used to justify an efficiency loss of ten or twenty percent, or even thirty and forty percent. But all too frequently it is used to justify an efficiency loss of a factor of two, or ten, or even more; and worse, the overhead is not only in time taken but in space occupied by the running program. In no other engineering discipline would such avoidable overhead be tolerated, and it should not be in programming language design, for the following reasons:
- The magnitude of the tasks we wish computers to perform is growing faster than the cost-effectiveness of the hardware.
- However cheap and fast a computer is, it will be cheaper and faster to use it more efficiently.
- In the future we must hope that hardware designers will pay increasing attention to reliability rather than to speed and cost.
- The speed, cost, and reliability of peripheral equipment is not improving at the same rate as those of processors.
- If anyone is to be allowed to introduce inefficiency it should be the user programmer, not the language designer. The user programmer can take advantage of this freedom to write better structured and clearer programs, and should not have to expend extra effort to obscure the structure and write less clear programs just to regain the efficiency which has been so arrogantly preempted by the language designer.
I find his comments describe accurately the software development attitude today. It is common for programmers to write inefficient programs and then say it can be fixed by buying faster hardware. While I can accept this for many applications, it is really most inappropriate for programming tool implementations. Not the just compiler, either: libraries, frameworks, and such are tools and, these days, at least as important as the compiler. I find the CPU and memory requirements of modern tools to be distasteful, since they don't provide correspondingly more in the way of speed or power.
Ten years ago I could fit on floppy all the tools I needed to develop programs in C: an editor, a C compiler, and the standard library. It took a few moments to compile and link a program of a thousand lines. These days, the C compiler and library are about 28 megabytes, without an editor. That's about 20 times the size. I don't have a good way to compare CPU speeds then and now; clock speeds are about fifty times higher now. My RAM is now 64 times bigger. It still takes a few moments to compile and link programs of similar size, though I suspect it is a bit faster now. Where did all the speed go?
Of course the compiler and library of today are much bigger and more featureful than those of ten years ago. The compiler has many more warnings, and can produce better code. The library has all sorts of nifty stuff I didn't have then. Is the new stuff worth it? I don't know. Nothing fundamental has changed: program execution speed is still dependent on my designing and implementing programs well, and I rarely use most of the new stuff in the libraries. Programming in C isn't any easier now than it was then.
The popularity of C has, of course, not been growing this past decade. Other languages are occupying its place in various niches, and in most niches, that's for the better. C is way too low-level a language for general application programming, and it is good that, say, Java and Python are replacing it for that. On the other hand, a modern Java programmer may need hundreds of megabytes of RAM just to run an IDE, and claims that it doesn't matter, memory is so cheap these days. That would be all right, if their productivity would be correspondingly higher, or they would produce better quality than C programmers ten years ago, but I don't see that happening.
I do actually think that a good programmer using Java is more productive than a programmer of equal caliber using C, but not 64 times as productive. Maybe two times. Something, somewhere, is wrong with this picture.
The other reason Hoare's remarks feel so right on mark for me today is that I've been struggling with the performance of an application written in Hedgehog Lisp at work. It reads frames from a CAN bus (a data bus inside a vehicle). Frames arrive at about ten millisecond intervals, or about 100 per second. We miss most of them, even though we have about three million clock cycles per frame. Either the application is doing something very wrong, or the implementation of Hedgehog Lisp is not up to the quality we need. Either way, my fault. (Even though the current one wasn't written by me, I guided the work and set performance requirements, so I'm responsible.)
Oh, by the way, Hoare wrote those words in 1973.
Monday, September 1, 2003
So this is how it feels like to be thirty four. It's almost as fun as being thirty three, actually, though I have less hair, since I went to the barber today.
Spent today fixing a performance problem on an application we're making for a client. It was quite a simple problem, actually: we have a data structure similar to a Python dictionary or a hash table in various languages. It had been implemented as a linked list for simplicity, with the intention that it would be written properly later, when there was more time. Way too much time was spent traversing the linked list in the application in question. The problem was fixed by changing it to use an unbalanced binary tree. This was fast enough, so there was no need to implement a balanced tree or other fancy data structure, though that will eventually be necessary.
It took way too long to find this problem. I'd like to have better profiling tools for Hedgehog. What we have now is crude, but it might be possible to augment it so that it serves our needs better. Tool making isn't quite what I should be doing right now, however, and it will have to wait.