The Elegant Chaos Blog

In the past, Apple has flip-flopped between two positions:

1) We provide the APIs, you (the developers) write the applications.

We don’t want to tread on your toes by writing products that compete with you, so we will provide only trivial applications, and sometimes we’ll even suppress our own internally developed applications, because they are too good.

This is what did a lot of harm to technologies like AppleScript, and PowerTalk. Apple allegedly had a great Mail client for PowerTalk, and a great editor for AppleScript, but didn’t want to release them for fear of offending the competition.

2) We want this platform to kick ass, so we’ll write some kick-ass applications.

We don’t really care about treading on your toes, because frankly we are the only people who have the whole picture. We know the system inside out so our applications can really integrate with it, and each other, resulting in a really nice user experience.

We don’t want to stop you from developing, but you’d be better off not developing anything too good otherwise we’ll have to do our own version and give it away for free.

Position (2) seems to be the default with OS X, and in some ways it’s hard to knock it. Admittedly some people get hurt along the way (Watson? Konfabulator? Come to think of it, anything that Arlo Rose was ever involved in), but all’s fair in love & war, and to be honest, an out-of-the-box Mac running the stock applications is really quite a nice tight ship these days, so it’s hard to argue with it from a user’s point of view.

It occurred to me today that there is a third way! It’s something that Apple is already doing in many ways, but they should definitely be encouraged to do more of it, and perhaps it should be formalised in some level of the Apple echelons of power.

Basically it’s the WebKit approach. WebKit is the rendering code that Safari uses. What Apple did when they developed Safari was to factor out the actual rendering code, put it into a reusable Framework called WebKit (something that other developers can use), and then build Safari on top of it.

Apple still gets to make a nice tight application that is well integrated with the OS and with other applications, but they also make a large chunk of the “heavy lifting” code available to everyone else. So someone like Omni can come along with their competing browser, and recode it to use WebKit. Now Omni can concentrate on adding the features that make OmniWeb better/worse than Safari (depending on your point of view), whilst offloading all of the support headache of the web rendering code onto Apple.

This approach is great for lots of reasons.

It encourages Apple to push the envelope, because they are doing something that benefits all developers. This is good because there are an awful lot of talented engineers at Apple. They might be working on Fireware Hard Disc drivers in the daytime, but they might well also have a great idea for an improved email client. It’s probably a good thing if those ideas can be expressed within Apple.

It also allows Apple to provide well integrated out-of-the-box solutions for whatever they deem to be the core tasks that an average user wants to perform, which, let’s face it, benefits us all if it means that more people buy Macs.

It lowers the entry point for Application development, which gets more talent into the Mac development space. It’s now feasible for me to write a customised web browser with WebKit. I might not do something very polished without a lot of work, but it might allow me to show you my great idea for browsers, which someone else may then run with.

It also encourages (forces even?) developers to focus on the added value (sorry) that their application is bringing to the domain they are working in, and they’ve got more time to focus on that code. The result for the user should ideally be an application that raise the bar another level past Apple’s default one, rather than just doing the same thing in a different way.

As I’ve said, this has already happened with WebKit, and because of the modular way in which a lot of software is developed these days, it is happening in other areas of the operating system - I suspect as a result of code which Apple engineers develop first for their own benefit, then realise that they can generalise for public consumption.

I suggest, though, that Apple make this a policy at some level. Yes, we will develop a mail client, web client, address book, music player, etc, etc, but each time we do so, we will ensure that the core ‘engine’ is provided as a public framework or API which other OS X developers can use. This will be good for them, and great for us.

more...

My store-code-as-a-database plan is not an original one, and it wasn’t even original years ago when I first started thinking about it - something like Apple Dylan was doing a version of it ten years ago, based no doubt on earlier work by others.

It’s amazing, however, how few people are doing it today. I’m not entirely sure why, but I think it’s a mostly a problem of inertia.

As programmers we invest an awful lot of time in learning to use our tools well. The good programmers do anyway - the lazy ones who just learn enough to enter code and compile it tend to be just as lazy when it comes to designing and implementing code, and about learning more about their craft in general; which I guess is what stops them from being good programmers in the first place.

This investment really bumps up the cost of moving to a new coding environment. It’s hard to justify switching from tool A to tool B just for one or two new features, if it means that you’re going to have to relearn a bunch of stuff that you currently feel very comfortable with. Even when those features are really cool and you can see the massive long term benefits.

And even if we are brave (foolish?) enough to switch to a new IDE/framework/language, most of us have to work with other people, who aren’t so brave, or have their eyes on other short term goals. So most of the “day job” work tends to stay being done with what we know, which of course increases the amount of time and investment in that environment, and reinforces the whole problem.

I don’t think that there are any easy solutions to this, but I guess it does illustrate that any new programming environment which goes down this path needs to do it’s best to support interoperability with existing tools (and by extension with colleagues who are still using them).

I suspect that what this means, perhaps, is that we have to start by creating an environment which acts as a kind of glue to tie together existing stuff, rather than starting from scratch.

Much as I’d like to build something which worked with a nice shiny new dynamic, reflexive, introspective, all-object language, maybe I’d be better off working out a way to wrap up C++ and Java in XML.

Much as I’d like to force everyone to use my system, perhaps I’d better figure out a way to get raw C++ files in and out of the system intact.

Much as I’d like my new tool to act as a it’s own version control system (each code block is an object in the database, so you can do seriously fine-grained version control), perhaps I’ll have more joy if I make something that just works with subversion.

Much as I’d like to make something that allowed truly collaborative programming, maybe I should just make the thing play well with SubEthaEdit!

All of this goes against the grain for me, in the sense that I have some sort of unformed idea in the back of my head of what this new system will be, and whilst I can’t quite figure out the exact shape, I know that it’s supposed to be clean and elegant, not a kludgy mess of glue on top of old tools.

Going down the interoperable route is probably more realistic though, and more achievable. If I start with stuff that already exists, I might even get something working within my lifetime…

more...

March 28, 2005

Just on the off-chance, I thought I should mention that I’m looking at the moment.

Ideally something that I can do from London, and something fairly short term (3 months or less), but I’m flexible.

If it was Mac based and Cocoa, Python, Java or similar, that would be great. If it was C++ that would be ok. If it was Windows based that would be ok… probably… if the money was good ;)

more...

Nice interview with Jonathan Rentzsch in DrunkenBlog

more...

For a long time I’ve been wanting to develop an authoring environment which stores code as some sort of structured database, rather than just a bunch of text files.

Imagine if the program is stored as XML, for example. Perhaps not optimal from an implementation point of view, but it’s a good way to visualise what I’m on about.

Obviously it’s easy to extract the raw source code from the XML if that’s what you want/need to do.

But it’s also possible to extract the actual relationships between program elements, as long as you have some basic knowledge of the object model being used to represent a program.

Suddenly it’s a lot easier to analyse the code. It’s also easier to transform it, so refactoring becomes much simpler.

If you have another language with a compatible representation, you can even automatically translate the code.

Finally, and perhaps best of all, you can add arbitrary meta-data to your code. This could be textual documentation (much more sensible that trying to embed documentation into comments a la JavaDoc), diagrams, optimisation hints, test data for unit tests, whatever.

Anyway, what triggered this particular post was that I came across a reference to an article on the Dylan list, which touches on some of these ideas.

more...