Photo by ybboey

If you don’t have a good idea, no problem, he’ll give you one – as long as you’re awesome. Oh to be Paul Graham. To have teams of shit hot coders fighting to be accepted by you so that they can work on your idea all summer, for minimum wage. He has created the world’s first ultra-high-level compiler. I’m being disingenuous of course. This compiler has (at least two) minds of it’s own, and Paul doesn’t really mind if it doesn’t do what he asks just as long as there’s a fair chance it will make him some money.

Here’s his full pres:

If, as it seems, the iPhone’s software will all come from Apple then all the development fun will happen in the browser, in particular in whatever version of Safari the shiny little device ships with. And it will be fun if Apple give us, as developers, access the right information. I’m talking here about that information coming from the user’s fingers. After all, who wouldn’t want to create the kind of effortlessly intuitive interfaces the Jeff Han showed off in his TED talk?

Will they let us though? There are a few directions Apple could go here.

1. Be scrooges and filter out multiple touches before they get to us, only letting the user interact with web pages one finger at a time, the others controlling scrolling probably. Web Dev Chorus: Booooo!
2. Give us the raw events from all touches but leave it up to us to do the hard lifting of working out which mousedown/mousemove/mouseup events came from the same finger. Web Dev Chorus: Grumble, Grumble, even huger javascript libraries, Grumble
3. Generously preprocess the input data for us and label mouse* Events with unique “device” identifier. Web Dev Chorus: Yaaay!! Go Apple!

The iPhone definitely has javascript (and may have flash), but that’s not enough. Javascript’s current way of getting information from pointing devices like a mouse, what’s called the DOM API, has no way of distinguishing between clicks from multiple sources (nor does Flash for that matter). Neither DOM 3 nor Web Apps 1.0 has added any properties to the event object to deal with multiple pointing devices. At a minimum it would be nice to standardize on a new field of the event object that uniquely identifies the input device for the duration of a mousedown/mousemove/mouseup cycle.

I would imagine Apple will not be that pushed to let javascript know about multi-touch. It will only detract from their own installed apps and introduce potentially low standard interfaces that would nonetheless be associated with their brand. However the problem will certainly come to the fore as other companies follow Apple into the multi-touch field. We might as well think about what we’d like now.

Update: Dave Hyatt from the Safari team replies…

I’ll have much more to say about this in the coming months.

…which makes me cautiously optimistic. It must be pretty exciting to be him right now.

UPDATE: The new TextWrangler 2.2 has Ruby highlighting. Yay!

Coding Ruby in Xcode on a Mac? Like the built-in syntax highlighting but wondering why the apple+/ shortcut makes C comments, not Ruby comments? The following might save you a few minutes digging.

Find and open this file:

/Library
  /Application Support
    /Apple
      /Developer Tools
        /Scripts
          /10-User Scripts
            /30-Comments
              /10-un_commentLines.pl

Replace this...

...with this...

Restart Xcode. Now commenting should work properly.

Have you ever wondered why programming languages that have good regular expression support (Perl, Javascript, Ruby, etc.) nevertheless omit syntax for negation or conjunction within regexes? I'm sure there must be a good reason for this. Has it been found that people just don't intuitively get what negation does to a regex? Are language designers unwilling to complicate their syntax? Are they avoiding the processing it takes to complement or intersect finite state machines? They do compile to finite state machines, right?

Let me give you an example of where negation would be useful. Say I'm scanning through some text for some sub-sections which have been explicitly quoted. If the delimiting characters are angle brackets then I can write /<([^>]*)>/. The bit in the middle [^>] matches any character which is not a '>'. This is a limited form of negation on a single character. Taken as a whole the expression says: Find me the strings of non-'>' characters which are surrounded by a '<' on the left and a '>' on the right. So far so good.

But what if the sub-sections I'm interested in are bounded by multi-character strings? '<<<' and '>>>' for argument's sake. In analogy to the example above I want to be able to write /<<<(?^.*>>>.*)>>>/. I've invented some syntax for negation here: (?^R) means match anything that the regex R doesn't match. The R in my example (.*>>>.*) matches any string that contains the sequence '>>>' so the expression as a whole says: Find me the strings that do not contain '>>>' that are bordered by '<<<' on the left and '>>>' on the right. Now, in this example, the same can be accomplished with a "lazy star" (if your programming language supports that) which just makes the regex non-greedy within the bounding strings: /<<<(.*?)>>>/. But I would much rather state the patterns I'm looking for declaratively than change the ambiguity-resolution mechanism of the processor. Why can't I?

Any finite-state toolkit with regex support has syntax for negation and conjunction. Do you know of any programming languages that do? If not, why not?