Polygot Programming analogy

I have been following a short email thread at work on Polygot programming (developing applications in more than one language). In its simplest form it is unlikely that an application contains a single language. Most applications involve some sort of XML :)

While reading the thread and a side note on construction I was struck by the thought that one could draw an analogy between a computer language and a construction material.

When putting together a car for example the designers choose materials that are suited to the job at hand. Each material chosen for its properties and application. A car made entirely using a material with a small set of properties (e.g. metal) would at the very least be very uncomfortable (steel tires).

With this thought it mind it is surprising that people continue to maintain the premise that a software application should be written in a single language. At best you get an explosion of code around the areas where the chosen language is not that good. At worst you see huge frameworks to get around the limitations.

Getting different languages to behave nicely together is not easy. Recent developments in leveraging runtime environments (JRuby, IronPython) make this interoperability simpler to manage but the problems rarely go away. The analogy with car manufacture works quite well - it is usually the interfaces between one material and the next where problems turn up.

Pushing the analogy even further it has been some time since carpenters have joined pieces of wood using wooden pegs preferring in the main to use screws. Steel screws are stronger than brass but brass is preferred for wooden boats because it resists the effects of sea water (as well as being more aesthetically pleasing).

Going back to automobile analogy the instrumentation systems use many different materials to delivery the required user interface, whilst the business end (engine) uses a more constrained list of materials (although in recent years this too has been growing). You could consider the instrumentation to be the equivalent of JavaScript on web applications whilst the engine corresponds to the back end systems (just a thought).

Subversion missing tools

Recently our team source code repository developed a problem. To be fair I don't believe that the problem was with subversion but with a disk fault but the effect was the same - subversion had a problem with one of the revision files.

After talking through the options we thought that we could replay the revisions using the svnadmin dump command and pipe the output into a new repository. Once for all the revisions up to the faulty one and again for those past the problem to HEAD. This did not work the receiving repository did not like having discontinuous build numbers.

I tried various utilities that reported they could fix fsfs format svn databases but non found or fixed the problem.

I ended up copying the previous revision over the faulty one - giving me nightmares about that missing revision. Now time to start digging through the backups for a good version of that file.

If anyone knows of a good tool that can dig into the svn filesystem to allow hand patches of revisions please let me know.

Starting out with Numbers

I managed to hold out for quite some time (for me some time is past the launch date) before splashing out on a copy of iWork.

I have been using Excel on my Mac but wanted to know if Numbers (part of iWork) gave a fresh perspective on how a spreadsheet should work.

I have to confess I have not spent a lot of time with Numbers yet but so far I have not been disappointed.

Key features that work for me

• Column and row headers as explicit items but still addressable
  
• Inline computation of results as a formula is filled into other columns
  
• More intuitive insertion of newlines in cells (got it on the 2nd try)
  
• Simple menus and text wrapping as an option on the toolbar
  
• Sheets start small and grow as the data grows.
  
• Easy import of my existing spreadsheets
  

It is still early days but so far very pleased :)

The beauty of small applications

A great colleague of mine just posted an article suggesting the Death of Enterprise applications.

I like the post it has a lot in common with the approach taken on for command line UNIX applications. Each command line app has a well defined responsibility, the OS provides a simple set of capabilities that allow these applications to communicate with one another. Using the applications and the 'glue' provided by the OS users can perform far more complex tasks. Adding in the shell means that applications can be developed just using the existing applications and OS communication.

In the world of web applications Sitemesh provides the glue roughly equivalent to the OS glue provided by the command shell. By developing applications in the progressive enhancement style allows web applications to be glued together to provide a cohesive web experience to the user.

Other benefits

* Each web application is partitioned into its own space. (loose coupling)
* 3rd party applications can be incorporated into the user experience more easily

Virtuosity

For some time developers writing applications for managed virtual environments have been enjoying the benefits of being able to interrogate and control the and generate code at runtime. When used appropriately these additional elements have delivered significant advantages - particularly in the tools world. Mocking libraries would not be easy to implement in a non-managed environment.

In the world of build management we have seen an explosion of tools that make it easier to deliver components and applications into a production environment.

One element of the picture that we have not seen a lot of progress on is environment control and deployment. Currently there seems little support for automated environment setup or deployment testing.

Sloth Development

Sloth Development Update
========================

So I have been working on [Sloth](http://sloth.sourceforge.net) for a few weeks now - mostly on the back-end compiler and execution engine. The journey has been quite interesting so far. A model for Functional Integration Tests is evolving in the code base and this is making the testing and Jave code generation easier. Since the test will need to be stored somewhere (initially in the FitNesse wiki format) the engine needs a way of loading and saving the pages. This has been extracted into storage specific repositories that are responsible for mapping to and from the storage system to the model.

Essential Software for a Cooler Mac

I moved over to a Mac early in 2006 and have been impressed. It has done everything I have asked of it and more. It has become an essential part of my life both as a work tool for software development and in my personal life for music and photo management.

But one irritation is how hot it runs. I know that this is a generally a problem with laptops but I had hoped that my MacBook Pro would have solved this issue.

So after a couple of years of having a warm lap a colleague of mine put me on to smsFanControl which allows control over the system fan's minimum speed. The default 1000 rpm means that I get a hot lap. Pushing this up to 2500 or 3000 rpm really makes a difference and to my ears does not make that much more noise.

One very happy chap and would really recommend giving the app a try.