Mike Schaeffer's Blog

A few months ago, my wife and I recently switched from a Sanyo 4700 and a 4900 on Sprint PCS to a pair of Sony Ericsson T-637's on bCingular Wireless. Overall, the switch has been an improvement, but there are still a few nagging issues:

• Cingular's selection of Java games is much sparser and more expensive than Sprint's.
• There's no "Phone Ringing" Ringtone on the phone, just a bunch of generic and/or unrecognizable music files.
• There are buttons on the side of the phone that activate the web browser and camera. These are pretty easy to hit by accident.
• Sanyos and Nokias have this problem too, but the Sony doesn't really handle the case of multiple directory entries with the same phone number. When called by someone at a number that for which I have multiple entries, I'd really like to see a list of all of the entries containing that number. (This would help handle the case of two people each with cell phones and with one home number.)
• The incoming call logs are by number, not by call. This makes it difficult to tell when you've missed multiple calls from the same number.
• The incoming call logs rely on automatic horizontal scrolling to reveal information like time of call and number of calls missed. This means that you have to select a log entry and sit on it for a few seconds while the phone scrolls the information you want into view. I'd much rather have some kind of details/summary view toggle button on the side of the phone. Of the four side mounted buttons, surely one could be for this.
• There's a music editor built in that lets you compose custom ring tones. However, it only lets you work with a fixed set of clips, so it loses its appeal very quickly.

I guess that looks like a lot of complaining, but otherwise the phone is very nice. The last phone I've liked as much is my old Nokia 8260 (and the 6160 before that). The Sanyo 4900 doesn't even come close. I'm happy enough with this phone to consider buying another Sony Ericsson. (The new W800i looks pretty nice...)

I'm writing some content for a future post on the offshoring of jobs overseas, but I want to clear something up before it gets posted: Outsourcing and offshoring are two different and orthogonal concepts. This seems to be something that gets misunderstood a great deal, but simply put, outsourcing is the movement of jobs to a different company and offshoring is the movement of jobs to a different country. Either one can be done without the other.

The scenarios that people tend to get upset about (at least in the United States) are the scenarios involving offshoring, the movement of work overseas. Outsourcing, however, does not necessarily imply that the work gets moved to a different country: it's very common for work to be outsourced to another American business employing American workers. An example of this is hiring a Madison Avenue firm to put together an ad campaign. Sure, it'd be possible to develop the talent in house to do this yourself, but there are many advantages in outsourcing the work to a more specialized vendor.

It never ceases to amaze me how much good material there is online. Here's some more:

• Olin Shiver's History of the T implemenatation of the Scheme programming language.
• Aubrey Jaffer has some interesting material on interpreter performance issues at his SCM site.
• Alan Kay's Early History of Smalltalk
• In 1994, Richard Stallman started a debate (flamewar?) on comp.lang.tcl with a post entitled Why you should not use Tcl. The Guile scripting language was the logical outgrowth of this.
• Kent Pitman has posted a bunch of his writings relating to Lisp and SCheme. Among other things, he edited the Common Lisp Hyperspec, which is an on-line version of the Common Lisp specification.
• Peter Siebel has written a book, Practical Common Lisp, and has gotten permission to put it online indefinately.

PS: Be sure to check out Olin Shiver's philosophy of undergraduate advising. It's an example to be followed. ;-)

I'm in the middle of developing a Scheme compiler for a future release of vCalc. While I've been developing the code, I've peppered it full of debugging print statements that look something like this:

(format #t "compiling ~l, tail?=~l, value?=~l" form tail? value?)

with the output statements in place, the compiler takes about 250-300ms to compile relatively small functions. Not great, particularly considering that there's no optimization being done at all. Anyway, on a hunch I removed the format statements, and execution time improved by a couple orders of magnitude to a millisecond or two per function. That's a lot closer to what I was hoping for at this stage of development.

On the other hand, I hadn't realized that my (ad hoc, slapped together in an hour) format function was running quite that slowly. I think it'll end up being an interesting optimnization problem sooner or later.