Tom Edelson's Songline

Sigh. Goodbye, Radio.

Sun, 21 Jun 2009 00:35:27 GMT

Quoting this post by Userland Software, in case you haven't heard:

UserLand has decided to close the Radio UserLand and Salon Radio services as of December 31, 2009.

You can continue to use your Radio weblog hosted with UserLand until the end of the year.

If you plan on continuing to use Radio to publish your blog, we would recommend that you look for an alternative web host if your weblog is being published to a UserLand server. You can use the FTP option [1] in Radio to publish to your own server.

The closure of Radio will also mean that the UserLand-hosted comments, trackbacks and stats tracking will be unavailable after the shutdown date.

If you have any questions, please send them to customerservice@userland.com

UserLand Software

[1] http://radio.userland.com/userGuide/prefs/1/5

To see the original post with more context: UserLand Product News: Radio UserLand

Life Goes On, But (Mostly) Not Here

Tue, 03 Feb 2009 19:45:34 GMT

Once again it's been quite a while since I posted anything to this blog. But I haven't lost the blogging habit altogether: I've been posting things somewhere else.

I was faithful for several years to Radio Userland as my blogging venue. (And I will always remember it fondly: it was my first.) But the time came when I could no longer resist the allure of a less familiar pretty face, and I have begun a new relationship ... with LiveJournal.

In case you're not familiar with it, LiveJournal is a hybrid: a combination of blogging and social networking. I rather like it (is this New Relationship Energy talking?).

My new blog can be found here: http://edelsont.livejournal.com. You will follow it avidly.

And has this Radio blog been relegated to the dustbin of history? By no means! It's just become more specialized. This will be (for the foreseeable future) my "geek blog".

In other words, what I will plan to post here, from now on, is computer technical stuff. Even some postings on software might go on LiveJournal, if they are directed at an audience of (potential) users of the software, rather than at the sort of people who program, or otherwise work with computers professionally. So if you're hard core, stick around! Well, visit me at LJ too, but come back here when you have the yen to get down into the bits and bytes.

I did create one post "over there" which some might think, by my own criteria, belonged "over here". It's about my programming language preferences (hint: the title is "In Good Taste: Very Schemely"), and you can find it at http://edelsont.livejournal.com/1038.html. Take a look, and judge for yourself where it belongs.

I myself would say that that that posting actually is in the right place: that it isn't directed at a technical audience. The only reasons it gives for my preferences are non-technical ones. I was trying to give the non-geeks a little taste of what it's like to care about such things.

I hope that you enjoy the new blog. And that you continue to enjoy this one, too ... if you're into that sort of thing.

Categorie(s) for this post: Blogging, Radio Userland, Programming Languages.

My Dog Died

Wed, 12 Nov 2008 18:20:24 GMT

Toofus was a fifteen-year-old retired racing greyhound, who had been part of my household for five and a half years. Fifteen is really old: the median longevity of the breed is a little more than thirteen years. He had various health problems, particularly gradual loss of some of the function of the hind legs; so I knew that he was slowing down, and that I should not be surprised if he came to the end of the road within the next year, or even in any given month. But there was nothing acute, nothing to indicate that it was imminent ....

... until 5 am on Sunday, October 12, when I was awakened by noises, and went and found that things were a good deal worse. He had fallen, struggled to get up, and fallen again -- several times, apparently, because all four legs had places where skin had come off as he staggered against the legs of the dining room table.

This was on a hard-floored surface. When I got him on to the carpet, he was able to stand and walk. But shakily.

I began to face the question of whether it was time to euthanize him. I talked to various people on the phone.

Meanwhile, I was observing that he was somewhat stabilized, but not showing any signs of returning to the previous day's level of functioning. He could get up, and walk around some; but he fell down several more times.

I became more or less clear that it was the right thing to let him go, to "send him to Rainbow Bridge", as the current expression has it; but I thought that it could wait for the next day, when the regular veterinarians would be open. Then, in the evening, it got worse yet: he fell down again, and, after twenty minutes, had not made any attempt to get up. So then it became clear, intellectually but also emotionally, that the more merciful thing was to grant him his honorable discharge, and do it quickly.

I ended up using a "pet ambulance" service to get him to the Cary pet emergency clinic. He was given the lethal injection, an overdose of a sedative, at about 11 pm. It was over in less than a minute.

I cried some, there and then. The next day, I was sad, but not intensely so; I was at peace with my decision. However, a month later, I am under no illusion that I am done grieving.

I loved that dog.

Categorie(s) for this post:

Greyhounds

Gettin' Down with the Large Hadron Collider

Sat, 06 Sep 2008 21:03:45 GMT

You gotta watch this. Trust me.

Large Hadron Rap

An Invitation to Read About My Spiritual Journey

Wed, 06 Aug 2008 15:05:25 GMT

Actually, my home page at The Well has had, for some time, a link called "Notes on my spiritual journey". But the linked-to document was in plain text, and not so easy to read.

Now, there's a newer version up, in HTML, and the content has been revised a good bit, too. You can find it via the home page, or at http://www.well.com/user/edelsont/personal/my-spiritual-journey.html.

It offers some insight into the "Quaker" and "Taoist" parts of my self-description (in the masthead of this blog). It doesn't say anything about the "poly" part, but I hope to address that soon.

My Spiritual Journey may also be the only page on the Web with links to all of these Wikipedia pages (among others):

At first glance, my spiritual journey may look like a random walk. But there's some interesting scenery, and good mental exercise, along the way.

Categorie(s) for this post: About me, Philosophy, Quakerism, Writing.

Anybody Want to Test-drive a Moneydance Extension?

Fri, 25 Jul 2008 21:55:58 GMT

I closed the last post by predicting that my software page was going to grow. Well, technically, it hasn't; it's gotten smaller. But that's because its previous content (a general description of my recent software projects) has been moved to a new location: http://www.well.com/user/edelsont/software/as-developer.html.

The new content at the old location is more of an index to my software-related pages: three of them, so far.

Which brings me to my main point: the newest of these pages describes a Moneydance extension I've written. Yes, after talking a lot about extensions I planned to write, I've finally got one working. It's called "Security Price Entry", and its purpose is to make it easier to record the prices of your stocks, bonds, and/or mutual funds from your broker's monthly statements.

The description of it can be found here: http://www.well.com/user/edelsont/software/moneydance/my-extensions/security-price-entry.html.

Now the bad news: it isn't ready for general distribution yet. Actually, I'm hoping to find a beta tester or two.

The ideal beta tester would be another developer of Moneydance extensions. But any Moneydance user who's interested in such a capability should be able to take it for a spin, if I send it to you in pre-built form.

Categorie(s) for this post: Personal Finance Software.

Something New on My Home Page

Tue, 06 May 2008 20:11:12 GMT

Until a few days aga, my home page at The Well didn't have anything on it about my interests and activities in computer technology. Now it does.

I've created a software page with a general overview of the tools I'm using, and the projects I'm using them on ... or hope to use them on in the future.

Expect this page to grow.

Comparing JScheme and SISC: A Postscript

Fri, 25 Apr 2008 20:35:32 GMT

The last five posts in this blog dealt, at perhaps amazing length, with differences between two (of the many) implementations of Scheme, both of them implemented in Java: JScheme and SISC.

In this "postscript", I want to do two things. The first is to give an overview of the previous five posts in the sequence. In particular, I want to call attention to the fact that they progressed from talking briefly about my preferences, to discussing a few of the differences between JScheme and SISC in much more detail. And when I did the latter, I was no longer motivated primarily by a wish to explain my preferences: instead, my goal was to use these differences as examples of much more general points.

After doing that summarizing, I then want to return to the subject of preferences, or rather, of how one would choose between JScheme and SISC. I want to refer, albeit briefly, to a rather larger number of differences between the two implementations: larger, that is, than the small number covered in the previous posts in the sequence. This is in order to give a bit more practical help to someone whose interest is in making that choice; and also to make sure that I don't leave you with the mistaken impression that that small set of differences between JScheme and SISC (the ones that I discussed at length as examples of "tradeoffs in language design") is anywhere close to being all the important differences that there are.

The first of these five preceding posts, titled A Better Scheme, announced that, after working with JScheme for several months, I had decided that I preferred SISC ... enough to convert a project in mid-development from using JScheme to using SISC.

That post didn't say very much about why I prefer SISC, making just one general point on that subject, and one more specific one. The general point was that SISC is "a complete implementation of R5RS, the most recent generally-accepted standard for the language", while JScheme claims only to be a "'nearly complete' implementation of R4RS, the previous version of the standard". The more specific point was that in JScheme, the "... numeric types are the Java numeric types"; and that in some cases, JScheme gives you wrong answers to simple arithmetic questions.

The next four posts were titled as a series: "Comparing JScheme and SISC: Tradeoffs in Programming Language Design (part 1)" through "... (part 4)", the last of these being the most recent post prior to this one. These were, in a sense, a continuation of "A Better Scheme", but their focus was different. They weren't primarily about choosing between JScheme and SISC (even though they certainly presented information that might be relevant to that). While it's a stretch, one could say that their point of view was that of a language implementor, rather than that of a [potential] user of a language implementation.

That statement would indeed be a stretch, because I wasn't writing for language implementors. I was writing for Scheme programmers .... especially those who have reason to want access to Java code from their Scheme code ... which is to say, potential users of JScheme [and/]or SISC. However, I wanted to give these readers a bit of appreciation for the language implementor's perspective. In particular, I wanted to give some examples of how implementation choices may (in fact, pretty inevitably do) involve tradeoffs, in the sense that a single implementation decision may have consequences that users are apt to like ... and other consequences that many users will not like ... where there's no way to separate them, to have the "good" consequences without the "bad" ones.

It took me four long posts to deal with just two of these examples. Each of these two examples was at least partly about how you invoke Java code from your Scheme code, in JScheme or in SISC. There's no question of "following the Scheme standard" here, because the Scheme standard says nothing about how to do this. Thus the implementors of JScheme and of SISC each designed their own extensions to the language for this purpose, and I was comparing those two designs.

The first example was entirely about how you do Scheme access to Java: it directly compared the syntax and semantics of how you do this in each. This was the primary subject of the first two posts in the series. I noted that JScheme's way of doing this, the "JavaDot notation", makes for more succinct code than does SISC's way of doing the equivalent. On the other hand, one may (or may not) regard the JavaDot notation as a major departure from the simplicity and consistency of the Scheme syntax, and object to it accordingly. So that's a tradeoff, at least if you do interpret the JavaDot "syntax" in that way, and do regard Scheme's simplicity of syntax as important.

The second example of a tradeoff took up the third and fourth posts in the series. These returned to the subject of numeric data types (and limited themselves, just in order to narrow the topic, to integer data types in particular). The underlying difference here is the fact that JScheme labels each integer value as belonging to one of the several built-in Java integer types, while to SISC (and to the R5RS standard), an integer is just an integer ... from the user's point of view, at least.

Each of the built-in Java integer data types has a fixed size in the computer memory, and, therefore, a fixed range of values that can be represented. In Java itself, and in JScheme, this entails that some arithmetic calculations (namely, those whose true result is outside the range of representable values) produce answers that, mathematically, are simply incorrect. This doesn't happen in SISC; I think that this can be counted as an advantage of SISC over JScheme.¹

On the other hand, the same decision, to let the JScheme integer data types be the Java integer data types, also allows for greater simplicity (again, as compared with SISC) in how one calls Java from JScheme. To give the Scheme programmer the ability to call Java (or, to an extent, any other language), a Scheme implementation must match up the arguments supplied by the Scheme code with the parameters required by the available Java methods. In JScheme, since each integer argument is already tagged as one of the specific Java types, this matching process is straightforward.

The same matching process in SISC, which doesn't have such a one-to-one correspondence of types, could lead to ambiguities as to which Java method is to be called. To prevent such ambiguities, SISC requires (and, so far as I can see, must require) that the Scheme programmer explicitly do a data type conversion before passing a Scheme value to a Java method. Since that's [a little bit of] extra code to write, it counts as an advantage that JScheme has over SISC.

So we have a second example of an advantage and a disadvantage, flowing from one and the same design decision: a tradeoff. Such tradeoffs are one reason why language design (or even the "implementation" of an existing language, because in real life, that still entails design decisions) is more difficult than it may look (to some). This is a valuable thing to be aware of, partly because one may then notice that the same is true of the design of programs in general ... at least, in those cases where it makes sense to judge a program by more than just whether it meets the explicitly stated requirements.

I have used selected differences between JScheme and SISC as a vehicle for making some very general points about programming. If I just left it at that, though, I might give some readers the mistaken impression that the differences I have mentioned thus far are the only differences between JScheme and SISC. So, before leaving the topic of "Comparing JScheme and SISC", I want to dispel that impression.

There are many more differences between these two Scheme implementations. Most of these differences (at least, if you can judge by the documentation) consist of features that SISC has, and JScheme doesn't.

Some of those features are specified by the R5RS standard, so that their absence in JScheme is a special case of the general statement that SISC is a more complete implementation of that standard. One important feature in this category is the ability to create "syntactic extensions" of Scheme in Scheme, also known as "macros". JScheme doesn't support these, whereas SISC does.

But a greater number of the features that SISC has, and JScheme doesn't have, aren't in R5RS: they are useful extensions to standard Scheme. The SISC user manual describes too many of these to list here. Here are three that may be regarded as important in various quarters:

An exception handling facility.
An object system: a way to define classes in Scheme code.
What could be called a "plug-in" architecture: a defined way to write Java code that implements new Scheme procedures.

SISC, in short, comes with a lot more stuff than JScheme does. It's probably this, more so than the few specific differences that I examined in preceding posts, that primarily leads me to the conclusion that you almost have to prefer SISC over JScheme. That is, it's hard for me to see how you could conclude otherwise, if you wish to use one implementation for all your Scheme programming needs, and you need to write a number of practical (and possibly large) programs.

The conclusion is strengthened if you add one more thing to your list of desiderata: if you prefer to use facilities already defined in Scheme, as opposed to explicit calls to Java code, where possible. That's because you can pretty much do anything in JScheme that you can do in Java, but as compared to SISC, it's more often the case in JScheme that making explicit calls to Java is the only way to accomplish a task.

It's entirely appropriate, then, that JScheme's biggest claim to fame be that it provides easy access to Java. A JScheme programmer depends more on explicit access to Java than a SISC programmer does, in order to get work done. JScheme, as compared with SISC, seems more like a scripting language for Java. SISC seems more like a Scheme implementation which "happens" to be written in Java ... though that fact about it means that you also can explicitly access Java from SISC, when you wish. (And really, it isn't much more difficult.)

As a postscript to the postscript which is this post, I will add that, judging by my own experience, one of the greatest advantages of JScheme, in practice, may be something not mentioned so far. That would be the fact that, to one category of potential users, JScheme has less of a learning curve, at the beginning. I am referring to programmers who want or need to learn and use Scheme, but who are just beginning to do so. Presuming that he or she also will be needing to make use of Java libraries, such a programmer, in learning to use either JScheme or SISC, is learning how to access Java from Scheme, and learning the Scheme language in general, at the same time.

This is something that one would prefer not to have to do, unless one were even more of a glutton for punishment than I am. In such circumstances, when one hasn't yet reached a comfort level in "standard" Scheme programming, one is especially likely to look for the simplest possible way of accomplishing some additional task, such as invoking Java from Scheme. And to such a Scheme newbie, that's what the JavaDot notation looks like: this person cares less about whether it may dilute the pristine simplicity of the Scheme syntax, and more about the fact that you have a one-screen "cheat sheet" which tells you how to do what you need to do.²

And that's where I pretty much was, when I first had to choose which Java-based Scheme to use: I'd been wanting to program in Scheme for years, and felt I understood the concepts pretty well; but I knew that there's a big difference between that and having some significant practice under your belt. You could call it the difference between "knowing about" and "know-how".

So I chose to use JScheme for my first substantial Scheme project. The project turned out to be a good bit more substantial than it seemed at first (don't they all?), and so it came to pass that, well before it was done, my perspective had changed. Now I was comfortable with the basics of Scheme. As a result, learning to use a modestly more complicated interface to Java was not nearly as scary as it had been a few months earlier. In fact, the cost of doing that was now less, in my eyes, than the cost of finishing the project without access to the additional features offered by SISC.

Remembering this sequence of events helps to keep me from thinking that the original decision to start with JScheme was a "mistake". It was the right thing to do at the time, and perhaps not just in the sense that it appeared to be right, from my perspective at the time. I might well recommend that someone else follow the same path -- that is, start with JScheme, with an awareness that one may switch to SISC fairly soon -- if that person were starting out in similar circumstances, with similar goals.

¹This fact also returns to one of the topics of "A Better Scheme" (namely wrong arithmetic answers), and explains how and why these occur.

²Another reason why SISC looks scary, to a Scheme newbie, is the fact that the previously-mentioned SISC user manual is entitled "SISC for Seasoned Schemers".

Categorie(s) for this post: Scheme.