For this session we’re going to hack on Opa. Normally we read through a paper, but we think hacking will work better over the medium. The goal is not (necessarily) to write something useful in Opa but rather to understand it’s model for web development. We’re not seeking to advocate Opa, nor are we experts on the language.

As G+ doesn’t yet support organisations, get in touch with me (email noel at untyped, or message Noel Welsh on G+) and ask to be my UU circle. We’ll be online on Friday 9 Sept from 13:37PM (+1 GMT), and will invite everyone in the circle to the hangout. See you there!

Myna is the system described in the blog post, and we’re accepting beta users right now. If you’re interested in content optimisation on your website, and want better results than A/B testing will deliver, do take a look. Obviously getting this surge of traffic from HN is incredibly valuable to us. However I don’t have any suggestions for repeating the event: when I submitted the blog post to HN some months ago it disappeared without a trace. Certainly being active answering questions on HN helped keep it on the front page, and that position netted us a fairly steady thousand hits an hour.

If you’re one of the people who read our blog post, thanks for the interest! It’s very exciting for us to know that our idea for improving content optimisation resonates with so many people, and we’re looking forward to getting Myna out of beta and seeing where it takes us.

The brief was to implement an elegant online phone configuration system. Alex, Director at Loho, provided the vision. We provided two weeks of development time, which was enough to create a working prototype. Alex has asked us to not give away too many details about the system, but I can show you a few screenshots. First up, here’s the main screen:

The very stylish main menu of the VoIP administration tool we've built for Loho.

Doesn’t give away much, does it? A bit more interesting is a detail of editing a configuration:

Also very stylish: editing the configuration of a voice menu

Here I’m editing a voice menu — one of those “Press 1 if you’re interested in giving us all your money” type things.

We think we’ve created a very nice system. Loho tell us they were overwhelmed with interest at a recent tradefair, suggesting we’re not alone in our opinion. While the interface is an important aspect of the work, the backend (which I can talk about!) is just as important. The main task was defining a data model to capture the rich feature set that Loho provide. This turned out to be very similar to designing a programming language and its intermediate representation. For example, we use a continuation-passing style representation to avoid maintaining a stack on the server side. Our representation distinguishes between tail calls and normal function calls to avoid excessive resource consumption on the VoIP side. Relational databases don’t do a very good job of storing recursive datastructures, like the AST of a programming language, so we used Mongo for the data store. In addition to its flexible data model, Mongo is web scale which has given us an immediate status boost at local programmer meetups.

The backend code is implemented in Scala and Lift. There are actually two interfaces to the service. One is the nice interface the users see, and the other is a REST interface that is called by the Asterisk AGI scripts that implement the VoIP functionality. The Asterisk system doesn’t handle all the functionality we represent internally, so the REST interface includes a small interpreter that executes intermediate steps till we arrive at something Asterisk deals with.

What you need to know about the A4 is this: at its core is an ARM Cortex-A9 MP CPU. ARM cores also power the iPhone and about every other smartphone out there. Intel just can’t compete in this market as their chips require too much power. This weakness is, paradoxically, a result of their greatest strength: the Intel instruction set. Even the most modern Intel chip still retains the ability to execute code for the ancient 8086. This ensures you can run just about any program ever written for an Intel machine on the latest CPU, giving Intel an enormous software base to leverage. However supporting this instruction set comes at a cost. The 8086 instruction set is not a good fit for modern CPU designs, and the instruction set has accreted decades of cruft to try and wedge modern features into it. To get acceptable performance all modern Intel chips have vast amounts of silicon devoted to instruction decoding; that is, the process of turning instructions into so-called micro-ops, which are what the CPU actually executes. All this silicon takes power, which is why ARM handily beats Intel on performance-per-Watt.

Now this wasn’t an issue for Intel even a few years ago. But we’re seeing three things that ought to make them worried. The first is the iPad, showing that little devices can grow bigger and perhaps move into the PC market, in much the same way PCs took over from the scientific workstations of Apollo, DEC, Sun and others. The second is the increasing concern for performance-per-Watt from people like Google and Amazon whose huge server farms power the major Internet services. The third is open source software, and particularly GCC’s support for just about every CPU on the market. This means the software can be easily recompiled for a new architecture. Suddenly Intel’s dominance doesn’t seem so assured.

So perhaps in a few years ARM will become the dominant architecture, rather than Intel. Apple have already shown that switching architecture (twice!) isn’t so painful. And as someone who has been writing an Intel assembler for fun I can’t say I see this as a bad thing.

Our Feedburner RSS feed is the preferred way to keep up with the blog.

Did I really just write Folksonomy?

• Y-Combinator tattoo. Ouch! Comments on plt-scheme revolved around the choice of font.
• From the same discussion came a link to Gentium, which is a very nice font and is also free.