It has been 12 years since I last posted anything here. I think the time has come (probably long overdue) for me to restart this blog in some useful way. However, I’m not sure I want to follow the original vision I had for this blog when I started it. Much has happened since then in my life, and my goals and perspectives have changed. Or have they? My first task needs to be re-imagining this blog in light of my current personal and professional situation.

In recent times I have been working extensively with Ada and SPARK, so that is an obvious direction to take this space. However, it is also true that my retirement approaches (a few more years, admittedly), so creating something that I can continue when I retire, such as talking about my various software projects, is another possibility. Of course these ideas are not mutually exclusive, nor do they exclude still other ideas. In any case, the blog has been “dead” for years. Consider it restarted, and watch this space over the coming months to see what develops.

Exception Specifications

Both C++ and Java (and other programming languages as well) support a notion of exception specifications. The design and even the desirability of these specifications is controversial. In C++, for example, the exception specifications are enforced at run time; if a function throws an unexpected exception the running program is (by default) aborted. In Java the exception specifications are enforced statically. If a method tries to throw an unexpected exception the program won’t compile. Which approach is better?

Exceptions are a dynamic process. The precise exceptions thrown by a program and where they are handled depend on the inputs given to it and on the execution path taken by the program as it runs. One might reasonably wonder if all possible exceptions that a program might throw are handled somewhere. Can this even be determined statically? My guess is that the question is undecidable in the general case. I don’t have a proof of this, but I’d be surprised if it was otherwise. Thus any static analysis must necessarily be either unsound or incomplete or both. In the case of exception specifications this means that either the analysis misses some exceptions that might be thrown and thus says all exceptions are handled when they are not (unsound), or the analysis forces the programmer to handle exceptions that in fact can never be thrown (incomplete).

Many exceptions have the potential to arise very often. For example in Java the null pointer dereferencing exception could potentially arise whenever an object or array is accessed. Requiring this exception to be part of an exception specification would essentially mean that every method would need to be decorated with that exception (and then what would that really tell you?). To avoid this Java’s exception specifications are unsound; certain exceptions, the so called “unchecked” exceptions, do not need to be covered by exception specifications. However, this means that the static analysis done by the compiler doesn’t really answer the question you’d like answered: are all possible exceptions handled in some way? Yet despite that, Java’s handling of exception specifications is also incomplete; among checked exceptions it is still possible that the compiler will force you to handle an exception that, under your specific conditions, can’t occur.

C++ checks exceptions specifications dynamically. This has the advantage of being precise; only those exceptions that actually do violate the specifications are reported. However, this leaves open the problem of what should be done when such a violation is detected. The program is already running at that point so the way in which this error should best be handled is likely to be application specific. Aborting the program outright might be reasonable in some cases, but probably not in most cases. C++ allows the programmer to translate unexpected exceptions into expected ones (using unexpected handlers) but this has the disadvantage of throwing away information about the original exception (although one could imagine an unexpected handler that logs the original exception in some way before translating it).

Yet there are issues with exception specifications that transend the static vs dynamic question. For example an exception thrown in a call back function that propagates through a third party module and is eventually handled by the client of that module should be perfectly well behaved. Yet the exception specifications in the third party module can’t possibly know about the client’s exceptions. There are also questions regarding the handling of exception specifications in generics or templates, etc. Many issues with exception specifications have been described with proponents on both sides of every argument. One is left with the distinct impression that the community just doesn’t know right now how to best handle exception specifications.

To summarize, static checking of exception specifications is unsound and dynamic checking leaves open the problem of how to handle violations. For these reasons, along with other questions about them, I suggest that exception specifications, as we currently understand them, are a bad idea. I am glad that Ada, my favorite language, does not have them. I would encourage the Ada community to be very careful about incorporating them into a future version of the language. I’m not saying that exception specifications can’t be defined in a reasonable and useful way. I’m only saying that doing so is trickier than it at first appears and that neither Java nor C++ got it right.

Project Wheel

Not long ago the Visual Studio installation on my main laptop decided to not work. Specifically, as soon as I opened any project Visual Studio closed immediately without any messages of any kind. The problem turned out to be related to the VMware plug-in for Visual Studio.

Any heavy computer user is going to encounter issues like this from time to time. That’s just life in this field. Still, when it happens to me I tend to get philosophical. I wonder if computer systems have become too complicated for their own good. Certainly I personally do not need all of the features and capibilities that modern software packages provide. I didn’t even know VMware had a Visual Studio plug-in until it started acting up on me. When complex software packages begin to misbehave because of interactions between components I don’t care about… something has to be done. But what?

I long for the days of simple software. I want software that only does what I need and not one thing more. Of course when I need my software to do something new, I’d like that new feature to become available. How could that happen? There is only one way I can see to get software like that: write it myself.

Thus I introduce “Project Wheel.” The goal of Project Wheel is to build a system composed entirely of software I wrote myself. Such a system would be small and simple (out of necessity), and also extremely customized to suite my needs. In addition I would, in theory, understand how it all works… and be in a position to personally fix anything that is broken.

Of course this idea is utterly nuts. Even if I worked 24/7 for the rest of my life I would not be able to single handedly buid a usable system from scratch. Yet even if the goal is unattainable the philosophy is, perhaps, still worthwhile. It is a philosophy of simplicity and self-reliance. Software should be functional, to the point, and tailored to the individual… not loaded with useless glitz that might (or might not) be interesting to someone somewhere.

Yet if Wheel is to have any practical feasibility at all, some concessions will be necessary. For example, I think one reasonable compromise would be to use software built by a team of which you are a member. Thus a follower of Wheel could use traditional open source packages provided he or she is actively participating in the development of those packages.

For example, I’m involved in the development of Open Watcom. Thus I could be fairly true to the Wheel philosophy if I used Open Watcom as the compiler for all my programs. It’s true that I don’t understand how all of Open Watcom works. However, I could in principle come to understand it because it is open source and, what’s more, I’m already engaged with that project and working on it.

Obviously it isn’t feasible to build an entire, modern system from custom made software. Yet I wonder how far one can really go with this idea. Years ago I wrote a simple text editor of my own. Maybe it’s time to clean up that source, compile it with Open Watcom, and then use it to start cranking out software. Yes, maybe it’s time to reinvent the wheel.

Discovering OpenSolaris

I’m back! I’ve decided to give blogging another try. Maybe I’ll find my blogging groove this time around. Or maybe I just like playing around with WordPress!

I was recently introduced to OpenSolaris, the open source version of the Solaris operating system. I downloaded the base system from the OpenSolaris web site and installed it into a VMware Workstation virtual machine. The installation was easy. However, the Solaris VMware Tools that come with my version of VMware Workstation (v6.0.3) do not seem happy with OpenSolaris. I have not yet looked into why. Fortunately the system seems to run adequately without VMware Tools.

OpenSolaris installs with a GNOME desktop and so visually it looks a lot like many Linux systems. It doesn’t take much poking around, though, to start seeing differences. For one thing, the base system lacks a lot of packages that I consider essential… such as a C compiler. I’m sure many additional packages can be readily obtained (for example, through the package manager!) although I haven’t looked into doing that yet.

In fact I haven’t spent much time so far exploring the system, and so I can’t say much about it right now. My first impressions are favorable, however. It seems clean and well behaved. I may write about OpenSolaris again in the future once I’ve gained more experience with it.

Indefinite Hold

I’ve had this blog for about eight months and yet I’ve only posted a few entries in it. Honestly I don’t have all that much to say, and I don’t want to talk just to hear myself talk. Instead of spending time maintaining this blog I find that I’d rather spend time working on one of my many projects. So I’m officially putting this blog on indefinite hold. I may return to it someday when I have in mind a clearer purpose for it. I may never return.

The point of blogging has always been unclear to me. I can see the value of it as a way to support or promote an open source project (for example). Such blogs are well focused and often contain interesting and useful information for the users of the project. However, a blog that is nothing more than technically rambling does seem rather useless.

Email + IM?

It is common to find single applications that integrate several services that could have sensibly been provided with separate applications instead. How much integration is smart is, of course, a matter of opinion. I think integration makes sense if the things being integrated are closely related and can reasonably share application features. For example, Thunderbird supports both email and NNTP newsgroup access. This makes sense because both mail and newsgroups serve a similar purpose. Also both systems can benefit from a unified address book and common message folders. In addition, both systems support similar kinds of message content.

What about instant messaging? Many people today use IM as a major form of interpersonal communication. In some communities it is replacing email as the communication method of choice. IM systems such as Jabber even support asychronous messages; the recipient of a message need not be logged in at the time the message is sent. One can easily see the sense in using an IM sytem for informal conversation and traditional email only for longer, more formal, and more complex documents.

Given this observation, does it make sense to build an integerated email+IM client? Again both systems could benefit from a unified handling of contacts, and it might be nice to store chat session logs in folders alongside email messages. Indeed, Google appears to be headed in this very direction with Gmail and Google Talk. However, I do not know of any desktop email+IM application. Is there one? Should there be one?


I have a thing for editors it seems. Over the years I’ve used quite a variety of different ones. I’ve even written an editor of my own. As I mentioned in an earlier post, I’ve recently taken to using jEdit for my day to day editing needs. However any editor as powerful as jEdit is also a bit heavy for some applications. It’s nice to have an editor on hand that installs easily, loads quickly, and yet is still powerful enough for “real” editing when necessary. One such editor is Notepad++.

Notepad++ has become a popular tool among students at Vermont Technical College where I teach. Students like it because it is easy to use and yet modern enough to be a comfortable editing environment for programming assignments, web pages, and most anything else. Indeed, Notepad++ is surprisingly feature rich for such a small download. It supports syntax highlighting for a wide collection of programming languages, macros, various Unicode encodings, and even a plug-in architecture with a significant number of plug-ins available on the Notepad++ site. The fact that it is open source is an added bonus.

I tend to use Notepad++ when I want to take a quick look at an arbitrary text file, treating the program as a kind of file viewer with editing features. It loads faster than jEdit so it is a good choice for quick and dirty editing when jEdit isn’t already running. Also since Notepad++ is installed on all the lab machines at Vermont Technical College I know I can use it anywhere in our labs without complication. Many of my students use Notepad++ for all their editing needs.

If you are looking for a small, light editor that is also worth using, consider Notepad++.

Is jEdit a Worthy Replacement for Emacs?

I am a long time Emacs user. Yet although I’m comfortable with the editor, I have never really achieved “power user” status with it. I dabbled with some macros and I fiddled around with my .emacs file, but I never got around to creating any non-trivial code to extend the editor in a useful way. Also as much as I respect Emacs, I’ve grown somewhat tired of its old fashion and rather quirky interface. Thus I started looking around for a more modern editor that, like Emacs, would be powerful, extensible, and free.

I found jEdit.

I like the fact that jEdit is cross platform. I use both Windows and Linux systems extensively and, like Emacs, I can run jEdit quite nicely in both of those environments. I also like the fact that jEdit can be extended with Java plug-ins and Beanshell macros. jEdit has plenty of features, particularly with the help of a rich collection of third party plug-ins, and it sports a much more modern interface than, well… Emacs.

My only complaints about jEdit are: 1) The interface is ugly, and 2) The quality of the third party plug-ins is quite variable. Some of the available plug-ins are very nice and work wonderfully. Some are rather rinky dink. Thus one’s experience of using jEdit depends heavily on which plug-ins are involved.

Overall, however, I find myself liking jEdit more all the time. Lately I keep jEdit running constantly on my desktop and use it for all my text editing needs. In the past I ran Emacs that way, but lately Emacs has been relegated to occasional, specialized use. Now I feel like I’m ready to take jEdit to the next level and begin creating some macros and plug-ins for the complex editing tasks that I had always planned to do with Emacs some day.

Is jEdit a worthy replacement for Emacs? Maybe so.

Change My Approach

It’s been a while since I last posted anything to this blog. I have been extremely busy this semester so it’s hard for me to justify spending time writing blog posts. This is particularly true given that I’m blogging mostly as an experiment anyway.

I think if I’m going to survive as a blogger I need to change my approach. Instead of trying to post relatively coherent and hopefully well thought out articles, I will just say a few words now and then about whatever crosses my mind. That will make writing posts easier and thus more likely that I’ll actually do it. It will also make this blog truly just “technically rambling,” and will probably more in keeping with the original spirit of web logging.

We’ll see how that goes.

HTML Email is Not Evil

I’ve reviewed the various objections to the use of HTML in email and, honestly, I think they are all fallacies. In many cases the objections seem to be more about the way HTML email is implemented in current mail clients than about HTML email itself.

The document here summarizes a number of common objections to HTML email. In this post I will offer a rebuttal to these objections. However, I should first point out that I might be attacking a straw man. Most of the anti-HTML email pages I’ve seen are relatively old. The issue appears to be generally less controversial now than in the past.

Here are the objections from the document referenced above, along with my comments.

1. HTML email is dangerous.

Here the objection is especially with regard to scripts but also with regard to other kinds of browser vulnerabilities (since HTML email is often rendered with the help of a browser plug-in of some kind). However HTML itself does not specify scripting other than to say that there exists a script element. A perfectly compliant HTML rendering engine could ignore all scripts. To me this seems like an obvious way to handle the issue. Plain HTML is passive and not especially dangerous.

2. HTML e-mail wastes bandwidth.

Certainly it is true that an HTML message will be larger, perhaps two or three times larger, than a plain text message. However most normal email messages are not very large. If I take a 2 Kbyte plain text message and bulk it up by a factor of five it is still only 10 Kbytes. In comparison consider the size of all the annoying ads and icons one typically downloads on the web pages one visits. Consider the amount of spam that circulates around the network. I suspect the bandwidth consumed by such junk is many times greater than anything likely to be consumed by legitimate HTML email. If one is concerned about clogging the network with crap, going after legitimate HTML email is not the answer.

3. HTML e-mail doesn’t always work.

Here the objection is that not all mail clients support HTML email. However, the lack of such support is becoming increasingly rare. Every modern client I’ve seen recently handles it. Even the text mode client pine displays HTML email in a reasonable way. In any case the multipart/alternative MIME type allows both plain text content and HTML content to be sent in the same message. This standard exists precisely to support mail clients that don’t understand HTML email while still allowing HTML email to be used with clients that do.

4. HTML e-mail can connect to the internet by itself.

Here the objection is to HTML messages with embedded images (for example) that use absolute URLs to access the image data. Again, this does not seem to be a problem for modern clients. For example, both Pegasus Mail and Thunderbird refuse to fetch images in such messages without explicit permission from the user. Again this objection is really about mail client implementations and has little to do with HTML email itself.

5. HTML e-mail renders slowly.

Here the objection seems to be about the added complexity HTML email imposes on mail clients. Certainly it is true that rendering any kind of rich text message is going to require more effort on the client side. So what? If one accepts that rich formats are useful (more on this below), then isn’t that complexity part of the application I want to execute?

6. HTML usually looks [horrible].

There is no doubt that some HTML email is really hideous. However, this is not a problem with HTML email itself. Instead it is a problem with the way people use it (or perhaps with what mail clients allow people to do with it). The solution is not to pull HTML email out of the hands of those who use it responsibly but rather to educate the people who don’t.

7. Digested lists hate HTML mail.

This sounds like a problem with the list digesting software to me. Why should a digest change the MIME type of the included messages? Perhaps the author of the digesting software thinks they are doing people a favor by converting the MIME types of all messages to text/plain. If so, that has little to do with HTML email. It is entirely related to an arbitrary design decision by the digesting software author.

Some people say that sending HTML email is pointless because the mark up adds nothing of significance to the content anyway. However, if that were really true then why do people use word processors when writing documents? Why aren’t all our documents in plain text? HTML adds a number of useful structural features like lists, tables, and embedded images to name three. Why not use them?

In fact, I’d like to go beyond what current mail clients seem capable of doing. I want to send potentially complex mathematical formula, together with associated line drawings through the mail. I don’t want HTML email, I want XHTML email that uses multiple XML name spaces! If the anti-HTML email crowd has its way, email messages will be forever stuck in the dark ages of document formatting technology.

Fortunately, as I mentioned earlier, the HTML email debate seems to be fading. HTML email is here to stay. Now we need to push for the next level.