In the comments to my post about IronPython and JRuby there were some comments about C libraries for Python or Ruby which would be unusable in in a CLR or JVM based implementation. This is correct, of course, and it is a problem for people trying to port software across implementations.

Earlier this week, Joel Spolsky made some comments about Ruby performance which triggered a bunch of posts, including a lesson from Avi on the 20 year old technique of in-line method caching. David Heinemeier Hansson weighed in with a post titled "Outsourcing the performance-intensive functions", where he argues that one of the benefits of scripting languages is that you can "cheat" by calling functions written in some other language.

Of course, that capability isn't limited to scripting languages. Other languages like Smalltalk, Lisp, Dylan, and others have foreign functions interfaces that let them talk to C code, and SWIG, which is a favorite tool for making it easy to link bind C libraries to scripting languages, also works for those languages. Reusing existing C code is a fine and worthwhile thing to do.

I don't agree, however, that users of dynamic languages should just agree to outsource high performance functions to C. The whole point of using a dynamic language is developer productivity, and that should be the case for performance critical code as well. And it's not like this is an impossible task either. There are implementations of dynamic languages which are very efficient, and applying those techniques to "scripting languages" is worthwhile endeavor, which is being pursued by folks like the PyPy team. As Avi also points out, the StrongTalk VM has now been open sourced, which may make it easier for language implementors to adopt some of the rich body of work that has been done on dynamic language performance.

Will there be cases where even the most advanced implementation techniques won't yield enough performance? Sure. That's why C compilers have a feature called in-line assembly code. But you rarely see it used. Having to rewrite my performance critical dynamic language code in C should be a rarity. The better the VM's get, the more rare those occasions will be, and that's a good thing. Let's not throw up our hands and say "yeah, you're right, we're slow, but it doesn't matter because we can cheat".

Several days ago I alluded (obscurely) to the possibility of 8 core Mac Pro's based on an upcoming quad-core Xeon. Tuesday, Anandtech demonstrated that the existing Mac Pro hardware is capable of the feat (memory bus speed notwithstanding). Their benchmarks also show that many applications are not able to exploit 4 cores very well, never mind 8. Now, where did I leave that Erlang disk image....

[via Kim Cameron’s Identity Weblog » Microsoft’s Open Specification Promise ]:

Today marks a major milestone for Mike Jones and myself.

Microsoft announced a new initiative that I hope goes a long way towards making life easier for all of us working together on identity cross-industry.

It’s called the Open Specification Promise (OSP). The goal was to find the simplest, clearest way of assuring that the broadest possible audience of developers could implement specifications without worrying about intellectual property issues - in other words a simplified method of sharing “technical assets”. It’s still a legal document, although a very simple one, so adjust your spectacles:

This is a big step for Microsoft, and so far the details look good. The OSP covers a raft of web services specs, including a few that are important for digital identity. The promise extends not just to spec implementors but down the distribution chain, which is essential to being open source friendly, and there's no registration or notification of Microsoft required.

In the coming days, I am sure more legally savvy folks will look the document over, but so far Larry Rosen and Mark Webbink [Deputy General Counsel at Redhat] believe (via the Microsoft OSP FAQ) that the OSP is compatible with FOSS community requirements.

People that are aware of OSAF are usually aware of Chandler, not as many are aware of Cosmo. Cosmo started its life as the sharing server for Chandler, but over time Cosmo is going to bring quite a few ideas from Chandler into a web based UI. Our goal is to have both rich desktop client and rich web client access to your Chandler data, so that you have a choice of whichever interface appeals to you the most. The Cosmo project is much younger than Chandler, so it is going to take some time to reach that goal.

Several weeks ago, we found ourselves in need of a new manager for the OSAF engineers working on the Cosmo project, and I agreed to take over those responsibilities. Lots of people who read this blog have talked to me about Chandler in the past, so I wanted you to be aware of what is happening with me and Chandler. You can keep talking to me (and any other contributor to the Chandler project) about Chandler, but you can also talk to me about Cosmo and stuff in the web space.

I also wanted to make you aware that we have two openings for people to work full time on Cosmo. The last time I posted about jobs at OSAF, we got PJE, who has helped tremendously on Chandler, so here I am again. Please use the link if you are interested.

As always, if you are looking to stay up to date on what is happening with Chandler and Cosmo, you should subscribe to one or more of our mailing lists.

The IronPython and JRuby announcements have been making the rounds in the blogosphere. and of course I want to add my 2c.

I think that these announcements are very significant and should be welcomed by people in both the Python and Ruby communities, because I believe that Microsoft and Sun's support of these languages will make it much easier to persuade people to look at Python and Ruby. Today people's biases are still against dynamic languages as whole, as opposed to particular languages, so I think that getting "corporate legitimacy" for either Ruby or Python helps both.

IronPython is already faster than CPython, and JRuby appears to be headed in a similar direction, although we won't actually know until JRuby beats one of the C-based VM's. There is a huge amount of effort being expended on the performance of the JVM and CLR implementations, and if that effort starts to benefit Ruby and Python users, then think that is a good thing too.

I've read some postings speculating on Microsoft and Sun anointing either Python or Ruby over the other, and/or over all other dynamic languages. I don't believe that this is the case. At OSCON in 2003, I attended a BOF organized by Microsoft people who were interested in improving support for dynamic languages on the CLR. If I recall, many of the "major" dynamic languages were represented. Also I know that Microsoft has been talking to folks like John Lam and others who are working on getting Ruby onto the CLR. As for Sun, JSR-223 is aimed at all scripting languages, Sun accepted a JSR for Groovy, and Tim Bray (who helped the JRuby thing get done) also helped organize a meeting at Sun for lots of dynamic language folks. I think that in part, IronPython and JRuby got picked up because the people involved were willing to work with the companies involved.

Other commentary has focused on whether or not Sun or Microsoft is ahead of/behind the other in this area. I suppose this makes sense if you are a partisan of one language over another. It's probably more true if you look at Python, since IronPython's baseline for comparisons is Python 2.3, while Jython is still catching up to Python 2.2. Overall, I think that we are still early in this game, and that neither side has an insurmountable lead over the other. If you look at the pace of VM support, I think that it's not so one-sided. Yes, Microsoft has been at this longer, but they also seem to have a longer cycle time to pick stuff up, since the pace of CLR improvements is gated by releases of Windows. Yes, you can download new versions of the CLR, but that makes deployment a harder deal. Sun still has to get its extensions specified, much less implemented in the JVM, and the cycles on the JVM are also long, but I also think that the window for broad adoption of dynamic languages still has not arrived, so both companies still have time, which also blunts the potential advantage of being first.

I'm happy to see all this going on, but the CLR stuff is far away from me, since my primary platform doesn't really have good CLR support. There's Mono, but it doesn't seem to be getting much uptake on OS X. I am basing this on the amount of buzz and/or actual Mac apps being developed on Mono, not on actual statistics, and I am sure that Miguel will be quick to disprove me with facts... I can at least see a world where I might use something like JRuby or Jython, since I have done a bunch of Java in previous lives.

These announcements also create some interesting points for observation. Here are some things that I am going to be keeping an eye on as these projects march forward:

• Community building around the implementation - I will feel most comfortable if these language implementations are community driven, and not vendor driven. I know from listing to Jim at PyCons that this is a goal, and the JRuby guys have been very clear about this as well. The recent buzz about these two projects gives them that PR bump that might allow them to draw more people into their communities. It will be interesting to see if they can convert attention into participation
• Compatibility - Both Ruby and Python are "open source" languages. By that, I mean that cross platform compatibility has been accomplished by having a single reference language implementation. It will be interesting to see if the JVM and CLR dialects are able to achieve a decent compatibility story or whether they end up essentially forking (or if you are suspicious, embracing and extending) the languages. One possibility is that we end up with some kind of standardization in order to keep this from happening. Of course, standardization doesn't mean compatibility - just look at the situation with Javascript 1.7, where you have a standard, but you have significant uncertainty about whether all browser vendors will implement it, thus reducing its usefulness.
• Performance - The IronPython team has shown that they can beat the performance of CPython. The JRuby folks have yet to do that, and both the Python and Ruby communities have higher performance VM implementations underway. This situation reminds me a lot of the situation with x86, Alpha, Sparc, and PowerPC, where you had different architectural approaches which were supposed to produce performance benefits. But in the end, large amounts of money, process technology and non-architectural considerations produced an outcome that was different that what you might have expected by just analyzing the processor architectures.
• Velocity - Having people who are working full time on these implementations is going to make a difference in the velocity of these projects. The question is how much, and at what expense versus creating a sustainable community?
• Tooling - Much has been made about the JRuby folks being chartered to work on tooling in someway. There's been speculation about NetBeans versus Eclipse, and there are also other Ruby IDE's. I haven't heard much about tooling on the CLR side, but it seems plausible that you could see Visual Studio support for IronPython and/or one of the CLR Ruby's should people at Microsoft decide it was worthwhile.

In the end, I think that having languages like Python and Ruby be "legitimized" by the recognition of big industry players, makes easier it is for me. It gives me one more argument to use when talking to people, which I hope reduces the amount of time I have to spend trying to convince people of the merits. That leaves me more time to work in a language that I like. Then again, we have Erlang, Scala, and Io just around the corner...

Michael McCracken is pondering the merits of laptops

I’ve been thinking of how I’d work if I didn’t have a laptop. One thing’s for sure: I wouldn’t spend as much time rubbing my neck while waiting for builds, for a couple of reasons.

I’m beginning to wonder if a laptop is really any good at all, let alone necessary. Wouldn’t I rather not carry that thing around all the time? Should my hands really sweat when my computer is working hard? Doesn’t having a laptop just give me an excuse to pretend I’ll be able keep working “later”, even though that never really works? Does anyone really gain more productivity from working at a coffee shop than they would using a fast desktop computer?

For years, I have wanted a laptop. It dates all the way back to the Apple PowerBook Duo days. I've always wanted to have one machine, which had everything in it, which could be with me at all times, and which could take advantage of the environment that I found myself in.

Laptops have always lagged behind the performance of desktops, and for a long time this kept me off of them as a primary machine. When I started at OSAF, I needed a laptop because I was going to be traveling, and I switched back to the Mac, which meant that the laptop was my primary machine, although I frequently wished for a desktop machine for performance reasons. I was eagerly looking forward to the Mac on Intel announcements, because I believed that the gap between the desktop and laptop Intel processors was much smaller than the gap had been on PowerPC. For most things, this has turned out to be true. iPulse tells me that there are very few times when I am CPU bound, and I am on the slowest MacBook Pro configuration. Instead, I'm finding that lots of the times that I am spending waiting are due to lots of paging/swappping, for which the solution ought to be "more RAM". Unfortunately, I already have 2G of RAM in the machine, and that's all you can get. I've talked to many people who also would like to drop more RAM into their MacBook Pro's. The other area where performance is a problem is video card performance, because Aperture relies heavily on video card performance and photo manipulation has become the number one performance limited application.

I could probably also get some more responsiveness by installing a 7200RPM disk in the machine (mine is a 5400), but then you have a different problem. I want to take everything with me on my laptop (although having a laptop stolen definitely gives you second thoughts about the wisdom of this idea). The problem is that laptop hard disks are just not big enough, and taking a faster drive means less capacity, hence the stack of external 7200RPM Firewire drives.

Lastly, there's there's the issue of taking advantage of the environment. Most of the time, my laptop is tethered to a large external display and keyboard. I occasionally "undock" it and use it around the house, but I don't do it as much as I'd like to, because once I "undock", I have to spend a ton of time putting the windows into some usable state again. I wrote some AppleScripts to help manage this problem, but it's still annoying enough that I avoid doing it unless I have to go somewhere with the machine. It's quite likely that I'd go mad if I actually had to commute every day.

So when you stack all those things up, a desktop, especially the new MacPro's, starts to look appealing again. Even more so when you ponder the Xeon version of Kentsfield.

to see that my friend Ducky is having problems with her university.

I am so backlogged on posts that I am tempted to declare total blogging bankruptcy. I"m suffering a bit of insomnia, so I'm going to see if I can kick myself back into posting...

Fitz and Ben Collins-Sussman have posted the slides from their awesome OSCON 2006 presentation: How Open Source Projects Survive Poisonous people (And You Can Too). I promised to link their slides when they went up, and I'm only a month late, which just goes to show how deep the backlog goes.