Seeking to Understand » Blog Archive » Birth of a Platform…

I also have a feeling that MacRuby is being lined up as the official 2nd language for Cocoa development (compared to other choices like PyObjC) - the particular point being that unlike other Rubies it can be compiled down to native code. (Etoile’s Smalltalk is interesting too, as that also uses LLVM and the GnuStep Obj-C back end, to make Smalltalk a seamless choice for Obj-C developers).

Ultimately, I can see a point where we should be able to write individual methods using the language of our choice, provided they support a compatible object model (which Obj-C, Smalltalk, Ruby and Python do).

But this is unlikely to be soon, and resource constraints suggest it would be much longer before it arrived on mobile (even Android is having to give native access for games).

Games will also remain a sticking point - most of them are mostly C++, not Obj-C - and games developers will keep them that way. C++ and OpenGL are relatively portable.

> It would be wonderful to see the progress of the web platform as a whole no longer
>hindered by the lowest common denominator browser

But surely it will remain so. IF HTML 6, say, defines a new JavaScript API for sound, similar to CoreAudio - you’re not going to use it until it’s commonly implemented (or there is a Flash-enabled shim).

It will certainly be a great day when we can depend on the lowest common denominator to actually implement standards in a consistent way - SVG in particular.

Then again, I’m not wholly convinced by ‘the web as application platform’ anyway. The App Store tells us that consumers still buy software, and watching non-techy friends with their iPhones I am reminded that it’s data that is the most important part of the web - URLs and HTTP are the most important layer, on which we can build many presentation layers.

Which is why it’s interesting to see people complaining that the App Store is about creating a proprietary web - I think the people who have that view think that the most interesting thing about the web is that it’s created a ’standard client’, not the web of information.

Cappuccino is very clever, but using Cappuccino apps I am reminded of the huge disadvantage of the web - 280 Slides takes an age to load - even after resources are cached locally - and uses up far more resources than Keynote to do the same work.

I can’t see any rational reason why anyone would choose to use Google Docs slideshow software over Powerpoint or Keynote, for instance, other than collaboration.

>Ultimately, I think the entire web may transition from HTML/Javascript/CSS to a kind of standardized >instruction format like a bytecode

There is talk of standardising an intermediate bytecode for JavaScript VMs - although this may be difficult as the different VMs take different approaches to optimising JavaScript - and older versions of IE don’t even use a VM.

I’d also like to see something that would allow us to use different programming languages, other than JavaScript, and a VM bytecode should make this feasible - although it may require a more flexible underlying VM to support other language features.

However, I don’t see the W3C backing anything that would damage the ‘web model’ of strictly separating data (XML), content (HMTL), style (CSS) and behaviour (JavaScript).

TBL’s bigger concern is with the bottom layers (semantic data tagging) rather than application development, which is one reason why the WHATWG went off on it’s own. I think he’s actually right on that one - the latter is an attempt to standardise application programming itself, while ignoring some of the important lessons we’ve learnt over the last few decades.

Another way of categorising it - it’s a bit like having the Cocoa APIs without AppKit to give a fundamental definition of what an application is.

However be very clear that the managed environment has nothing to do whether the language is C, C++ or Obj-C, that’s the magic of LLVM. What it means is that potentially, the compiler can generate intermediate bytecode which is processor independent as is now the case with Java / CLR and thus make distributing binaries to different targets easier than it is now… not that it’s all that difficult now, but it could get messier as time goes on. The analysis dimension means that Apple could use metrics from it’s static analysis suite to refuse dodgy code, and that’s probably a good thing, and I might add totally in the hands of the developers since they have the same tools.

There will never be a day when Apple say to developers they can’t develop in C. This is just silly - The Obj-C runtime is incredibly flexible and cool to develop with, but it’s just crazy slow for things that require tight optimization (i.e. any tight game code, DSP, image processing etc - there’s a good reason why most of the stuff on Mac/iPhone that needs to go fast is done in C or C++. The message passing interface generates a page full of assembly, whereas a c function call is just two instructions (if not one!!), and a C++ vtable is marginally slower. C (and occasionally C++) is the language for system internals and backend engines, Obj-C is the language for applications and frontends, both play to their strengths in those areas.

But that doesn’t mean there won’t be a day when C isn’t generated into an intermediate bytecode… technically, that day could be today. The question for Apple engineers is whether the tradeoff for developers who require bare metal access to the cpu for performance reasons will get the same performance from a JIT or target hosted compiler… it’s too early to say yet whether that will be acceptable to those engineers.

Forcing developers to use documented APIs really has nothing to do with this, that’s just common sense from a quality control perspective. As John Gruber keeps pointing out, if you want an API public, file a radar bug for it, apple listens to that kind of stuff, and you’d be amazed how much code gets opened up as part of the normal development cycle… just look at the camera APIs in 4.0

Seeking to Understand » Blog Archive » Birth of a Platform…

Each of those technologies certainly do have a set of vocal detractors with valid complaints. And, sure, it is undeniably fashionable within the Mac community to scoff at Flash right now. However, neither the transient implementation flaws nor the disgust that web standards advocates might have for those proprietary platforms discount the fact that web-deployed managed bytecode applications are already a part of the web ecosystem. We can only hope they improve or replaced with better solutions.

Re: Sean’s notion of the browser as a container for Canvas with an HTML/CSS layout engine implemented and deployed as a JavaScript library is an interesting scenario where an web standards architecture might achieve what these other technologies have already attempted to varying degrees of success. It would be wonderful to see the progress of the web platform as a whole no longer hindered by the lowest common denominator browser.

To bring it back to Sean’s post, specifically to the idea of the evolution of Apple’s application deployment model - my original point was simply that it wouldn’t be the first time Apple watched others flounder at delivering quality and usability, and come along with a more focused and elegant solution.

This kept on happening, over and over again. Microsoft’s apps broke badly when the OS went from using 24 bits in 32-bit pointers to using all 32 bits, because Microsoft, knowing that there would never be 32-bit pointers, used the other 8 bits for their own purposes. Many apps broke badly when System 7 rolled around, because System 7 had large chunks rewritten from the ground up according to the spec. And the same thing happened with the PowerPC transition, and the Intel transition.

In short, Apple have learned the hard way that developers will prefer “it works, ship it!” over “it complies with the spec, ship it!” in 99 out of 100 development shops. They have also learned the hard way that when Apple changes things that it never committed to in the first place (such as undocumented APIs) that they get blamed even though it’s the developers’ fault for doing something that they should have done. So Apple’s stepping up and enforcing this.