waffle

Microsoft continues to make inroads: Remote Desktop Connection 2.0 beta is written in Cocoa.

(Scott Stevenson coyly adds: “Excellent. The Jedi mind trick worked.” Indeed, Scott. Indeed.)

Larry Wall:

Right at the beginning we said, “There is never time to do it right, but there is always time to do it over”. So we’re just gonna take the time to do it right. You’ve heard this saying “Good, Fast, Cheap. Pick two.”. Well, this is Open Source. We have to do it cheap. Therefore, it reduces to a problem of “Good or Fast. Pick one.” We chose Good. We did not choose Fast. You may have noticed this.

Perl 6, to me, is good not because it becomes more like Ruby. (I’ve said that Ruby is my Perl 6 until Perl 6 becomes Perl 6. I meant that Ruby is sufficiently close to Perl and sufficiently modern to be an improvement over Perl 5, and sufficiently different from Python to keep me from running away as fast as I can from it.) Perl 6 is good because it’s really something uniquely Perl. Many features of contemporary Perl were pioneered in Perl. Many features in Perl 6 will be pioneered in Perl 6 (junctions, language-integrated regexes, roles).

A lot of people run away from Perl because it’s just so different from everything else. Some people will point to Python 3000 or Ruby 2 and say “this is a diligent, responsible upgrade that doesn’t waste seven years of everyone’s time”. These people have points, and as someone who occasionally meets deadlines (hi, Jeff!) I’m sometimes inclined to agree. But an upgrade won’t do it for Perl. Perl 6 is a complete reworking on the language.

Perl 5 was different, but freaky enough that if you just patched it to work like people who had discovered closures and object orientation would have liked, existing Perl 5 users would be skittish and uncomfortable (”okay, I can adjust to this, but what about the next minor upgrade?”) and the rest wouldn’t have used it anyway because it’s still Perl 5, just with closures and object orientation.

I am inclined to believe that Perl 6 is the right step to take. Tear it down, build it up, almost the same but rethinking every step of the way. It’s still Perl, but it’s not Perl 5, and it is reasonably modern.

maccode is a project that gets entirely too little attention – a Google Code project where several related Mac component projects can host their code. The idea is that a community will grow around it and will help out on several projects.

I just had a heated discussion with Chris Forsythe (after having proposed the Resolution Independence project I started be pulled in via svn:externals) and I have a feeling we both misunderstood each other. I want to explain why I’m not considering hosting everything in my project directly inside maccode.

• Low level of control over committing. Everyone committing code to one component can commit to any other component. I am not considering that people will do good work on one component yet be belligerent on another, but as maccode gets more successful, it gets less and less practical to understand who does what, where, and that stands as a hindrance both to administrators and members of maccode as well as people trying to contribute finding people to which to talk about doing so.

• Low level of control over Google Code features. Google Code allows control over various fields and values in the built-in issue tracking. There’s two things that can be done with a maccode-like project: forgo details completely, or grow a complicated tree of details that makes, say, filing issues harder for everyone.

• Low level of focus. maccode doesn’t prevent people from adding wiki pages, but say a particularly challenging component was added that needed 10 wiki pages of documentation. Once maccode encompasses enough projects, or enough challenging projects, it will be harder than should be necessary to maintain a relevant structure of wiki pages.

I don’t mean to spread so-called “FUD” around people hosting their components inside maccode (I encourage everyone to evaluate the benefits and downsides and come to their own conclusion), and I don’t even wish to be the Benevolent Dictator for Life of ‘my’ project; I’m just explaining why I think doing so would bring disadvantages, and what those disadvantages are. If there was a way to move ‘my’ project under maccode in the Google Code project hierarchy without losing its current setup, I would do so in a heartbeat.

My own contribution to the Mac OS X Resolution Independence project is called Rectiffy. It came from an idea proposed by Rory Prior to write a small app that lets you add and remove images from a TIFF file. TIFF files can hold multiple representations of the same image, like icon files, but the representations can be any size and have any DPI setting.

Rectiffy has functioned as a viewer for a while but today I checked in my first three-hour rush job shot at editing the representation list (adding and removing) as well as outputting the final TIFF. If you’re interested you can check out the Subversion repository (it’s experimental but it seems to work) as long as you understand that it’s not really pretty yet, but it does do things like check the images you add for having the same aspect ratio. And if you want to check some of these TIFFs out, Coda’s TIFF resources are mostly (if not all) multi-representation TIFFs.