UPDATE: I’ve uploaded a preliminary proof-of-concept Rebmu implementation to GitHub. See http://hostilefork.com/rebmu/ for details.

StackOverflow has a tag for so-called “Code Golf”, which has the goal of attempting to perform a programming task with a program that has a minimum number of ASCII characters.

There are several loopholes:

1. You can obviously define a language which specifically performs only the one task, and uses a single-character program to do it (e.g. if the task is to print “Hello World”, you can make a fictitious language in which the single character program h will do it)
2. You can compress your program into a form where it is no longer the sort of thing a human can reasonably read or write (e.g. the hexadecimal representation of assembled machine code)

But a real Code Golf language needs to be Turing complete. Furthermore, I feel that you should be able to give an arbitrary challenge to a programmer they could write a working program without machine assistance. It should also be feasible to make minor adjustments to the program’s behavior without using some kind of tool. My opinion is that in this respect, Rebol has potential to be the most impressive language for Code Golf ever created.

However, Rebol has striven for a verbose English-like wording scheme. So out of the box, its ability to compete is hampered against less ideal languages that have been purposefully shortened for this purpose (like GolfScript) Yet I began to wonder if the language could be configured in a trivial way that preserved its basic character (so it still passed the language parser) but that made it more terse.

I’ve decided to call my idea “Rebmu” (REBμ) the Microsocopic Rebol Dialect for solving code golf challenges! You can find a proof-of-concept source file on GitHub which has some documentation, but this post goes into some detail as well…

http://github.com/hostilefork/Rebmu/blob/master/rebmu.r

(more…)

Jeremy Friesner brought this site about analog literals to my attention. It provides the long-needed ability to represent integer constants in C++ not as numbers (like 42) but rather as 1-D, 2-D, or 3-D shapes whose length, area, or volume correspond to the number’s quantity. So for instance:

assert( ( o-------------o
          |L             \
          | L             \
          |  L             \
          |   o-------------o
          |   !             !
          !   !             !
          o   |             !
           L  |             !
            L |             !
             L|             !
              o-------------o ).volume == 
 
( o-------------o
  |             !
  !             !
  !             !
  o-------------o ).area * int(I-------------I) );

That’s great! As the inventor of Arecibo ASCII, I fully support this visual double-check with our intuitions about numbers! What if aliens are trying to read our code, but don’t know about our arbitrary choices of digits and numeric base?? This could bridge that important gap!

But there’s one nagging concern I have, which is that I don’t think the 1-D numeric values are very intuitive. Look at these examples from the site:

assert( I-I == 0 );
assert( I---I == 1 );
assert( I-----I == 2 );
assert( I-------I == 3 );

I’d prefer it to more consistently depict the historic concept of zero, and be less arbitrary with the “2N+1″ formula of dashes to implement value N. So why not overload dereference and multiply, and define “II” to be the constant value zero? This way you can get:

assert(II == 0);
assert(I*I == 1);
assert(I**I == 2);
assert(I***I == 3);

The implementation is relatively straightforward from the proposal. But I went ahead and wrote it, and it is complete enough to give errors when compiling invalid literal specifications:

int test1 (I); // compile error!
int test2 (*I); // compile error!
int test3 (I*); // compile error!
int test4 (*I*I); // compile error!
int test5 (I*I*); // compile error!

I hope this makes it more practical for people to apply analog literals to real-world situations! Source below…

(more…)

On a plane flight, the only reading material I had available was someone else’s copy of Joel Spolsky’s User Interface Design for Programmers. It’s very short… and took about an hour to read:

I’m afraid I have to mostly side with the less positive reviews on Amazon. When people buy texts on user interface instead of reading “some guy’s blog,” it’s usually because they are looking for well-vetted and researched ideas they can apply. But anyone experienced enough to properly take action based on this book’s glib advice (like “users don’t read!”) is probably smart enough to make all the necessary realizations on their own.

Joel nevertheless has an entertaining and frank way of talking about his personal experiences in the software industry. So I think it would come off better with a less ambitious title…like Joel Spolsky’s Top Anecdotes About User Interface. The cover could have Joel at a party with a martini, with his hand over the shoulder of a nervous bespectacled guy who’s about to get another earful about some Windows dialog box that sucks.

I’m not saying that kind of presentation is not useful or fun. In fact, most of my software development conversations are little more than me ranting in that fashion. Then again, I don’t charge anyone for it! (To be fair, Joel only charges for “about half” of the book, the rest is free on his website.)

Rather than debate the merits of the book any further, I decided to just write down a few things that reading it got me started thinking about. So begin <rant>…

(more…)

(UPDATE 26-Jun-2009: A fuller development of the Arecibo Ascii code is now available at http://hostilefork.com/uscii/)

Every programmer who knows English is aware of the ASCII code, which declares that 65 means “A” and 66 means “B”, etc. Yet there is nothing intrinsically “A-like” about the number 65 (binary: 1000001), nor anything B-like about the number 66 (binary: 1000010). To see that, just imagine living in the 1800s and this fell from the sky on a piece of paper:

1000001100001010000101000001

Even if you knew it was supposed to represent text, I think it would be impossible to read that as “ABBA” with any degree of confidence. You might be able to get a clue that 7-bit sections were significant if you had a large body of data and realized they were always multiples of seven in length, but any single signal like this would not be enough. You’d be in an especially bad position if you didn’t know anything about alphabetical order (which isn’t a strict prerequisite of being able to read or write English successfully)!

To address this, I created something called “Arecibo ASCII”. It’s named after the infamous Arecibo message—a binary sequence transmitted into space that tried to explain some things about humanity. The goal was to make as few assumptions about the receiving aliens as possible…only that they had an understanding of physics and math (and obviously, the ability to detect electromagnetic waves).

When Carl Sagan and Frank Drake composed the message, they took it to Richard Feynman without explaining to him what it was. They figured if Feynman couldn’t decode it—given his upper hand of already knowing Earth science—then the aliens wouldn’t have a chance! Luckily, Feynman got pretty much all of it.

In the spirit of that test, I’ll send you an “Arecibo ASCII” message before I tell you how it works!

11111​11111​11111​11111​11111​11111​11111​01111​11111​11111​11111​11111​11111​11111​10111​11111​11111​11111​11111​11111​11111​11011​11111​11111​11111​11111​11111​11111​11101​11111​11111​11111​11111​11111​11111​11110​10001​10001​10001​11111​10001​10001​10001​00000​00000​00111​01000​11000​11000​10111​00000​00000​00011​11100​00011​10000​01111​10000​10000​10011​11100​10000​10000​10100​01000​00000​01000​00000​01000​01000​01000​01000​01100​00100​00100​00100​00100​00100​01110​00000​00000​00111​01000​11111​11000​00111​10000​00000​00000​00000​00000​00000​00000​00011​11110​00010​00011​11010​00010​00010​00000​00000​00000​11101​00011​00011​00010​11100​00000​00000​10110​11001​10000​10000​10000​00100​00100​00100​10101​00110​00101​00100​10111​11111​11111​11111​11111​11111​11111​11011​11111​11111​11111​11111​11111​11111​11101​11111​11111​11111​11111​11111​11111​11110​11111​11111​11111​11111​11111​11111​11111​01111​11111​11111​11111​11111​11111​11111​10111​11111​11111​11111​11111​11111​11111​11011​11111​11111​11111​11111​11111​11111​1110​

Want to test your alien-codebreaking-savvy? See if you can figure out what that says before you read the rest of the article! Otherwise, just read on as I spill the beans…

(more…)

Programmers typically assume that a MouseUp() message won’t happen unless they had previously received a MouseDown()… and that these signals will come in precise pairs. Yet in almost every modern system that runs multiple applications at once, you will hit edge cases that send your program a MouseUp() when no MouseDown() ever happened—or two MouseDown() messages in a row.

There is no well-studied example of how to write your mouse handling code in a way that accounts for these cases. As a consequence, merely task-switching while still in the middle of a mouse operation will send a lot of applications into unexpected conditions! Many will crash or assert when you return… and those that don’t crash often do something bizarre. So I thought I would make a screencast of a prototype I made in 2002 which insulates programmers from these concerns. Even if you’re not a programmer and don’t want to read the whole article about the implementation, you might think the feature itself is unique, so check it out!

(Note: I use alt-tab to take the focus away in mid-mouse stroke, because that was easy to choreograph. But of course the technique is more compelling when an application in the background jumps forward and “steals” the focus. )

As you can see, my library took control of the mouse message pump and reduced the concerns of the programmer. If a mouse gesture was interrupted somehow I didn’t cancel the operation (nor did I just pretend the mouse button had been released and commit it). Instead, the library put the application into a suspended state with a placeholder icon at the last known mouse position. Clicking inside the placeholder restores your cursor to the previous coordinates and resumes the mouse operation, while pressing escape lets you abort.

Use Command objects that only run on MouseUp

In the past I’ve written about the importance of designing your program’s command processor in such a way that undo and redo operate consistently. One of the rules I mentioned was that your command processor shouldn’t be modifying the user’s document on MouseDown() or MouseMove(), but should accumulate the state in a Command object that is only submitted to your Undo/Redo queue when the MouseUp() is finally reached.

The good news is that if you’ve done that part right, then most of the necessary support work for this feature is already done!

A Command object not only makes things clearer for undo and redo—it also gives you a fantastic way of holding a mouse operation in “suspended animation”. The counterintuitive aspect is that pending commands must participate in the rendering process—since the document’s state alone is not enough to draw the view.

Build on Drag&Drop APIs, not mouse messages

One issue that I really had to grapple with was how to retain some control of the mouse cursor even when it had left my application. Sadly, running SetCapture() on Windows still means that the cursor will turn into the default arrow after the focus is lost. The way I found to work around this on Windows was with the Drag&Drop APIs—which turned out to be “tighter” than the default mouse API.

On Windows and other platforms, the Drag&Drop methods are precise analogues to the mouse messages we are familiar with:

1. DragStart() = MouseDown()
2. DragOver() = MouseMove()
3. Drop() = MouseUp()

(more…)