Kevin Reid's blog

When Larry Wall was designing Perl 6, he started with lots of community proposals, from which he made the following observation:

I also discovered Larry's First Law of Language Redesign: Everyone wants the colon.

When I was recently trying to redesign E, I found that this holds true even if only one person is involved in the process. One of the solutions considered was having “: ” and “ :” be two different tokens…

1. Premise: Any attack on a password — whether online (login attempts) or offline (hash cracking) — will be designed so that the more likely a given password is, out of the space of all possible passwords, the less work is required to recover that password (unless a trivial amount of work is required to discover any possible password).

2. From (1), there exists a probability distribution of passwords.

3. Premise: There is a (practical) maximum length for passwords.

4. From (3), the set of possible passwords is finite.

5. From (2) and (4), there is a minimum probability in that distribution.

6. Use one of the passwords which has that minimum probability.

(There are at least two ways this doesn't work.)

These may be three different things:

• The answer to the question you asked
• The solution to the problem implied by the question you asked
• The solution to the problem you actually have

I was reminded of this yesterday when, noticing that my code for Cubes was using an arbitrary constant for the near clip plane, I asked how to calculate it in a principled way.

Do not sort the category “Other” under “O”.

In the unlikely event that you haven't heard of it already, the barber paradox is:

The barber [who is the only barber in town] shaves every man who does not shave himself. Does the barber shave himself?

Now, this can be considered just logically contradictory, or a gotcha (“the barber is a woman”). But how about considering it as a poorly-written specification? Under this principle I propose a correction:

The barber shaves every man who would not otherwise be shaved.

I've several times seen the complaint that URL shortening services (tinyurl.com, bit.ly, etc etc) eliminate the ability to see where you're going by viewing the “real” URL and that this is dangerous.

In my opinion, if it is unsafe (except in the “seeing something you'd rather not” sense) to not know what the destination site is, then there's something wrong with the system. After all, you visit unknown sites all the time whenever you're learning about some new-to-you topic; it shouldn't be necessary to trust them.

The info visible from the URL is useful as a time-saving hint — “oh, that info is being presented as a video on YouTube — I don't have time to watch that now” or “I've seen that already” or “that site requires an account to do anything useful with”, but if it's neccessary to check it, then something needs fixing. I'm not saying you need fixing — it might be “the design/defaults of current web browsers” (e.g. that any web page is permitted to play sound by default) or “such-and-such protocol or plugin” — but something needs fixing.

That said, I don't actually approve of URL shorteners — because they do remove that helpful hint, and they create opportunities for links to break in the future.

 +----------------------------------------------------------------------------+
 |                                                                            |
 |                                 A thought                                  |
 |                                 ---------                                  |
 |                                                                            |
 |  |\  /|onospaced text  documents were the first  WYSIWYG-edited documents. |
 |  | \/ | One can create paragraph formatting and headings, special layouts, |
 |  |    | integrated diagrams, decorations --  all interactively with exact  |
 |  immediate feedback  upon just how it  will appear (outside of  choice of  |
 |  font) on screen, paper printout, someone else's email client -- anything  |
 |  whatsoever that displays this medium.  Though,  font characteristics can  |
 |  affect the quality of diagrams and decoration; for example, how high the  |
 |  “~” or “^” symbol is,  and how much of a character cell is filled by the  |
 |  character shape.                                                          |
 |      This, however, is a minor disadvantage,  and I have even today found  |
 |  uses for this style of document preparation;  for example, certain class  |
 |  assignment submissions.  The usual tool is Microsoft Word documents; but  |
 |  I do not own a copy of Word,  and while OpenOffice (dot org) is adequate  |
 |  for reading, its rendering is often different from Word's  -- and I have  |
 |  even encountered data loss bugs: “Hey! Where'd my table go?”  After that  |
 |  incident, I resorted to plain text for the assignment (which was essenti- |
 |  ally tabular in structure) and have used such formatting since for those  |
 |  things which are amenable to the format.  I could have used HTML, or sub- |
 |  mitted a PDF rendered from OpenOffice-on-my-computer or a LaTeX document, |
 |  but I wanted to choose a format  which I was confident would seem a reas- |
 |  onable type of document to the recipient,  and plain monospaced text fit  |
 |  that role well.                                                           |
 |      It can even be fun  to lay out your document  completely by hand, if  |
 |  it is not too long  -- and rather than fiddling with margins,  tab stops, |
 |  table editing tools, etc.,  you can just  *write what you want* directly, |
 |  just as much as if you were writing on paper, with all the advantages of  |
 |  an electronic document. Unless you want graphics that are no bigger than  |
 |  a character.                                                              |
 |                                                                            |
 |   |/    .    /)  . /                                                       |
 |  /\_Ø\///\  /\_Ø/(/.                                                       |
 |                                                                            |
 |  P.S. If you want to reply in like style,  use the <pre>...</pre> element  |
 |  and click the “More Options...” button to get to the “Don't auto-format”  |
 |  option.                                                                   |
 |                                                                            |
 +----------------------------------------------------------------------------+

The people who have come to rely on features that are actually implementation errors are called ‘mistakeholders’.

Photo taken by me in a Staples store. Text added with Zach Beane's roflbot.

I've been having a lot of thoughts lately I'd like to publish, but seem a little bit too short for A Blog Post. Some options

1. Considered signing up for Twitter. Pro: short stuff is expected there; participating in the hot new thing; people interested in short-form will be on twitter and using the follow feature. Con: Reliability problems; YA thing to manage credentials and backup for; no hyperlinks; my favorite username is taken.
2. I could post stuff here. Particularly, LJ supports titleless posts.
3. I could use some other site, or build my own publishing system. [er, why?]

On reflection, I'm thinking to just post the stuff here and not have yet-another-distinct-place/site.

Readers, what would you prefer?

(This post is tagged “lisp” solely so that Planet Lisp will pick it up.)