If you’re looking for a non-sucky Bluetooth adapter, the D-Link DBT-120 seems like one of the best ones out there. It appears to have good Linux support and Mac OS X support, and its Windows drivers are actually half-decent. (Perhaps Windows XP SP2 might standardise on a Bluetooth stack, but I wouldn’t trust that to make the dismal state of Bluetooth on Windows any better.)

Quote from Tidbits:

Now here’s an odd marketing campaign — so odd, in fact, that I wonder if I’m missing a level or two of self-mocking irony. Microsoft is running a sweepstakes to promote Microsoft Office 2004 for Mac based on the slogan, “Get in touch with your inner suit.”

Raymond Chen on more herculean efforts to retain backward compatibility in Windows, this time related to virtual memory management:

In Windows†95, the memory manager was completely rewritten and the above coincidence was no longer true. To conserve kernel-mode virtual address space, physical memory was now mapped linearly only as necessary. Of course, the drivers that relied on the old behavior were now broken because the undocumented behavior they relied upon was no longer present. As a result, when it starts up, Windows†95 looks around to see if any drivers known to rely on this undocumented behavior are loaded.

Wow. (Pun intended.)

So here’s the scenario: You’re out at a bar, riding transit, or even just walking down the street, and some bozo who desperately wants into your pants starts up a conversation with you. Rather than make a scene or make them upset, you’re polite and at least nod at the proper times. Then, of course, they ask you for your number. Except this is 2004, so maybe they ask for your email address instead. That’s where Paper Napkin comes in.

iPhotoToGallery totally rules. How much simpler can you make exporting things from iPhoto?

Aww, who says Apple don’t sprinkle easter eggs in their code anymore?

Only funny because it’s true.

A quote from a nice comment from Dave Benjamin on Lambda:

… I really wish Python had gotten a ternary operator; having to abuse “and” and “or” just to embed a conditional in an expression is tacky. I don’t care what the syntax is! Pick one! I feel like that feature died because of the noise, because nobody could agree on anything, and if that’s the direction of Python’s future, it’s a little bit scary.

Look, we’re not all going to agree on anything. I thought that’s why Guido was chosen as “Benevolent Dictator for Life”. Lately, his strategy has been to say something like “Well, I don’t care if we add the feature, and I don’t care if we don’t, but if you all can decide on a syntax, we’ll do it.” I think that this approach is killing progress. Of course we won’t all agree. We’re a bunch of opinionated hackers, and we like things our way. That’s why you’re dictator, Guido. Dictate!

Language is the one concrete dependency that we never seem to be able to abstract away. Changing a language affects more people the more successful a language becomes. Is it the destiny of every language to eventually grind to a halt, for no other reason than people’s inability to agree on the next step for growth? I hope not, but I’m glad we have lots of other languages that are not so constrained.

Totally agreed. Design by committee rarely turns out elegantly.

A snippet from a post by Guy Steele on the ll1-discuss list:

And you’re right: we [the Java language designers] were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren’t you happy?

Spotted this little gem in a thread about programming languages and software engineering, on (where else?) Lambda the Ultimate:

John Reynolds told me that he once described a correctness proof for XORing together pointers in a doubly-linked list to someone. This person asked why he would ever want to prove such a disgustingly nasty hack correct, to which he replied that it was no longer a disgusting hack, because he had a clean proof of correctness for it.

Patrick Logan talks about Yet Another Python implementation named pycore, a Python VM implemented in Smalltalk. Yawn, you say? Well, right now it’s completely unoptimised, and seems to benchmark better than CPython. I can see this giving the much-more publicised IronPython a run for its money. Isn’t it great how Smalltalk can still compete well with today’s modern VMs?

By way of Joel Spolsky, a good article on Great Hacker != Great Hire. (And in case you haven’t guessed yet, I agree with the article by the simple action of linking to it from my blog ;-).

Matthew Thomas writes about the lack of usability advancements in the past two decades in this excellent blog entry. Why, indeed, do we still make people use filepickers at all? (Though, I should note that KDE’s File Open dialog box is actually a fully-embedded Konqueror view, which is a step in the right direction.)

Lambda the Ultimate has some pretty interesting discussion about compile-time checking for taking the tail of an empty list, which is generalisable to compile-time checking of any partial function (functions which are not defined for their domain, i.e. their input values). Some particularly interesting comments I found in that thread:

• “I see the empty list as being like null, which Nice has static checking for”. Wow, impressive (probably not impressive from the type theory angle, but particularly impressive from a practical viewpoint: all NullPointerException exceptions detected at compile-time? Cool indeed. Something tells me I should have a closer look at Nice. Maybe for my Ph.D, I can write a type inference engine for Objective-C. Nehhh …
• [On modifying the tail function to return Maybe [a] instead of just [a]]: “Using Maybe for this is like saying - let’s turn this partial function into a total one by lifting its range to include Nothing. It became total by obtaining permission to return something I have no use of.”
• “My point is that [the] Hindley-Milner type system is not expressive enough to allow two (or more) consent programmers to state their mutual expectations. As an author of tail function I can’t promise to always return list given non-empty list and expect the compiler to reject all programs that try to call tail on empty list. I suspect it’s possible to stretch Haskell a bit to encode this particular constraint, but as you said, dependent types are way to go for those who seek more static expressiveness.”
• “In Epigram type checking is decidable, because all functions are total. Conor McBride plans to add general recursion, but its use would be tracked by the system so that types can only depend on terms from the total fragment.”

And of course, the obligatory type wizardry post from Oleg:

• “I’d like to point out that it is possible in Haskell98 to write non-trivial list-processing programs that are statically assured of never throwing a `null list’ exception. That is, tail and head are guaranteed by the type system to be applied only to non-empty lists. Again, the guarantee is static, and it is available in Haskell98. Because of that guarantee, one may use implementations of head and tail that don’t do any checks. Therefore, it is possible to achieve both safety and efficiency. Please see the second half of the following message: http://www.haskell.org/pipermail/haskell/2004-June/014271.html”.

Wolfgang Thaller’s been working on bringing the Glasgow Haskell Compiler into the 1990s:

Yes. In fact, I already have a “Hello, world” program linked against dynamic libraries libHSrts.dylib, libHSbase.dylib and libHShaskell98.dylib on Mac OS X, and another one doing the same thing on PowerPC Linux.

All I can say is: thank God! Wolfgang, you rule. I can’t wait for this to hit the GHC stable tree!