The type wheel turns again

It's slightly spooky when you're discussing a topic and evidence for (or against) your position seems to spontaneously appear. The fashion for strong versus weak type systems seems to change on a cycle of about a decade. It might be turning again.

On Monday I was talking with a student who's doing a project using node.js, looking at using it as the basis for doing elastic concurrent programs. It's the sort of project that could underpin some kinds of low-end cloud computing, letting designers use JavaScript end to end.

The discussion turned to type systems, and how Javascript's very weak view of types makes things more difficult for his project, as he will have to constantly protect against having the wrong methods called. On the other hand, it makes other things easier by letting him create proxies and other structures freely. The question is then whether strongly-typed languages are preferable to weakly-typed ones.

In a strongly-typed language, every denotable value has a type, the language ensures that all uses of those values are type-correct and generates a type error if not. A strongly statically-typed language does this purely at compile-time, and it's generally recognised by those who advocate these approaches that it's preferable to catch as many errors as possible as early as possible. It's also recognised that this isn't always possible (think Java class loaders), and so some run-time structures are also needed -- but these can be provided so as to catch problems as early as possible (when code is loaded). (See Dobson and Matthews. Ionic types. In ECOOP 2000 – object-oriented programming, pages 296–312. Elisa Bertoni (ed). Volume 1850 of LNCS. Springer-Verlag. 2000.)

For some people, static typing feels too rigid: the compile will often prevent things that the programmer "knows" to be possible. In this case a looser type regime is often preferred. Strong dynamic typing checks at every operation to make sure that the values being manipulated are type-correct; weak dynamic typing does fewer checks, often only detecting problems very late; untyped or monotyped languages do few or no checks and will apply any operation to any piece of data at the programmer's instruction.

I tend to fall into the strong static typing camp -- which is slightly ironic, given that I'm currently working on untyped extensible virtual machines. Programmers' beliefs that they know better than the type-checker are often erroneous, the more so as code gets more complicated.

The fashion for type systems seems to follow a cycle. People are using a language with strong typing when a new kind of programming comes along, often driven by some new technology. The strong types are restrictive for this new domain (having been designed for a different world) so programmers invent or re-discover languages with dynamic typing that allow them to write the code they need to write without the difficulties of fighting a type system. In large-scale systems, programmers also like being able to evolve the data structures gradually, without having to update every user. (Doing so in the presence of strong types often doesn't work, although with care it's possible.) This leads to a widespread belief that type-checking is unnecessary, difficult, for losers, etc, and that dynamic languages are the only way to go.

Then, as programs get bigger and more complicated, problems start to emerge. Typically these revolve around different parts of the system not agreeing on the exact data representation, so everyone has to check the data they receive because the language offers no guarantees that it'll be correct. (This is the down-side of being able to evolve the representation piecemeal.)  Such checks rapidly become untenable, and so programmers start thinking about whether there are automated mechanisms to improve checking -- and re-discover strong type systems.

Having been discussing this in the context of Javascript, I then stumbled across TypeScript, a Javascript extension that allows type annotations. These aren't exactly a strong type system -- they're optional, for a start -- but definitely mark a change in the way Javascript would be used, as a system with defined type structure rather than as a type free-for-all. Since Javascript occurs in a lot of systems these days -- on the front-ends, but also increasingly server-side -- this is a welcome departure. I find it hard to believe that large, long-lived component-based systems can be built in a dependable fashion using only a dynamic approach to typing. It relies too much on programmers' willingness and ability to check everything, every time.

Actually there are strong arguments for the need for non-static run-time checks, most notably in distributed systems when you can't be sure the data you receive will be type-correct even if the compiler that generated the code thinks it is, since you generally don't have complete control over all the components and their evolutions. But this isn't an argument against strong typing in general: it still helps, even if there are small holes. Instead one perhaps needs to check types at the component boundaries so that, once admitted, you have confidence in their type-correctness. This in turn places demands on the transport protocols to be self-describing in terms of their payloads' types, and doing so supports other constructs (like type-driven computation) for free without sacrificing the benefits of the strong checks. Having some dynamism (and room for run-time failure) within a generally static seems like a decent compromise.

What's new for awareness researchers?: an interview

I was interviewed at SASO as part of collecting what people thought were the ways forward and important topics for pervasive systems.

The Aware project co-ordinates between a collection of EU projects into self-awareness and adaptive systems. As part of its remit it collects the evolving opinions of the research community to try to decide where the research is leading, and in particular what are the emerging questions that might be supported by future EU initiatives. Interviewing researchers is a new departure that I haven't seen before, and they interviewed several people with diverse backgrounds to get a broad sweep of the area.

I focused on how little we understand how to model what people actually do in the course of their lives, and consequently how hard it is to explain these processes to computers and build computer-mediated analysis and support.

(Sorry about the noise in the background, we were standing in a corridor....)

Response to Science Foundation Ireland's consultation on its strategic plan

Science Foundation Ireland (SFI) recently launched its strategic plan for the coming years. This is my contribution to the consultation process.

It's quite unusual for there to be a consultation process, of course: many such documents are drafted by governments and their agencies without reference to the opinions of outside stakeholders, so it's gratifying that SFI is confident enough to put its thoughts out for public comment. It's also gratifying that the aims and aspirations embodied by the document are so forward-looking and ambitious, given the parlous state of the country's finances: the straightened times only make government investment in science more important, as a route to improving the country's position.

There are however some issues that I think merit further consideration. These include:

  • the orientation of basic research;

  • the demands on staff from different phases of the research lifecycle;

  • the career trajectories of PhD students;

  • the significance of capacity-building, especially in the area of spin-outs and other indirect benefits; and

  • the possible extended leveraging of the expertise present in Irish science as part of the organisation.

What follows is abstracted from the letter I submitted to the consultation. I've removed some of the extraneous detail and generalised slightly to make the content less Ireland-specific, as a lot of the issues will be faced (or indeed are being faced) by funding agencies elsewhere.

Orientation of basic research. The orientation of research suggests that one can create a clear vision of what is going to be successful and impactful. This is clearly not the case: many areas that have changed the world in the long term had little or no short-term applicability when they were first investigated (for example lasers and hypermedia). The notion of government funding as “sowing seeds” therefore needs to be regarded with caution, and the history of (for example) Silicon Valley is notable mostly for the lack of directed and co-ordinated government investment and a focus instead on capacity-building (see below).

To maximise the chances of breakthroughs, one must allow experimentation that cannot be justified in terms of its known or predicted impact. One hears a lot about the “impact” and “spillover” of “basic” research into more “applied” areas. It is worth noting that such a hard distinction between “basic” and “applied” research is now largely discredited: a more accurate characterisation might be between “applied” and “not applied (yet)”. This is important, as it implies that any calculation of the value for money of any piece of research is often more a matter of timescale than of any intrinsic property of the work or field. Much of the mathematics that now underlies on-line cryptography, for example, was developed decades before its was practically applied, without such number theory having any obvious applications.

The basic difficulty with orientating basic research is that it is almost always a backward-facing activity, in the sense that one can only generate evidence in support of areas that have already demonstrated relevance and/or which already have a significant local industrial presence. Unless care is taken this can exclude promising areas for which there is currently no market but which have the capacity for enormous impact going forward. (3-D printing is the technology that springs most to mind here.) Setting a limit on the funding that will go to non-prioritised areas seems unlikely to provide for a broad exploration of speculative areas.

Phases and skills. It is important to recognise that excellent research scientists are often not the appropriate individuals to commercialise their own work. When one is speaking of the research lifecycle, it is clearly true that the translation phase is as creative and exciting as the discovery phase. However, it must be recognised that the skills required in these two phases are very different. While some exceptional individuals are able to muster excellence in both discovery and translation, this is extremely rare, as evidenced by the tendency of the founders of research-led start-ups to leave (or be eased out) as their companies grow: most scientists function better in one regime or the other. Put another way, excellent research scientists will be more productive overall if they are not forced into an inappropriate role. It would therefore be appropriate to generate structures whereby research can be ”handed off” between groups, and that recruitment and funding structures be introduced to ensure that scientists in each phase are treated equally and fairly – although not necessarily identically, to reflect their different motivations.

PhD careers. The decision whether to go into industry or academia is a complex one, driven by an individual's temperament and interests. I believe that care is needed in aspiring to move some given percentage of PhD graduates into industry. It would be a mistake to attempt to direct such career decisions, since trained researchers wanting to pursue academic careers that are not available locally will not generally take up industrial posts as an alternative: they will simply move abroad. This cohort of researchers is highly mobile and motivated, and only by providing matching opportunities will their skills be retained.

Capacity-building. While there is clearly enormous potential value in direct commercialisation of research products, there is far more value in the ICT space from simply building capacity. I have been struck by the number of start-up companies in Dublin formed by former PhD students (including several of my own) – but I have been further struck by the work these companies are doing, which often does not relate to the research topics of their founders. Indeed, in most cases the companies' work could not have led to a PhD.

This I think underlines the importance of intellectual capacity-building, and a corollary is that what is important is that the system generate researchers, rather than being solely concerned about the actual research done in training these individuals. Brilliant, educated minds will go on to do good work: if attracting the best minds is best accomplished by supporting them in basic research for their PhDs, this will be a good investment. It is noticeable that many staff in Silicon Valley companies have PhDs from local universities in very foundational topics.

Another aspect of capacity-building that often goes unmentioned is the progression of staff in post: the recognition that the excellent researchers need to have their career aspirations met and respected. There is ample evidence that this function is not properly dealt with by many institutions within their current structures: the exclusive focus on importing “iconic” and “prize-winning” staff can be demoralising to local staff, who can then become demotivated or induced to emigrate.

I believe the evidence supports the notion that staff in post will overall be more motivated, and more committed, by promotion than many high-flying individuals who may regard their appointment as a temporary base or a prelude to retirement, and may not continue to do the world-leading work that underpinned their recruitment.

Integrating expertise. SFI aspires to be a “model” department in terms of supporting scientific activity. One approach that might be beneficial is that pursued by the NSF, to second scientists into the organisation as programme officers. This approach – which I believe is currently unique to NSF – seems to deliver very well-managed programmes, gives the organisation access to a range of scientific talent, ensures that the staff in charge of programmes are up-to-date with the latest science, and also immensely benefits the management skills of the scientists involved. It is true that  it can be challenging to manage conflicts of interest, but the research community in the US is also “a small country” in this sense, so I am sure that mechanisms can be found. Providing seconded individuals with a funded postdoc ex officio (as we do in St Andrews for Heads of School) might allow their own research to proceed in their absence.

It'll be interesting to see what happens to the strategic plan as a result of the consultation, but whatever the result it's a creative and constructive exercise to test the plan against an outside audience. I'd like to think this can only improve the process of governance for State-supported science.

Distinguished lecture on artificial life

Our most recent distinguished lecture was the best I've heard so far, and on a fascinating topic I'd like to know more about.

We run two distinguished lectures each academic year, inviting an academic in to teach a four-hour course on some topic that often we don't really have expertise with in St Andrews. It exposes undergraduates, grad students and staff to new topics and ways of thinking about research. The series goes back to 1969 and includes some of the best-known names in computer science.

Last semester's speaker was Larry Yaeger from the University of Indiana (on sabbatical at the University of Hertfordshire), who talked about artificial life: using computers to study the processes of evolution, speciation and adaptation. It's a topic that sits on the boundary between novel computing and theoretical biology.

Artificial life sounds too much like science fiction to be "real" computer science: do we understand enough about life to be able to study it in the abstract?, and, if not, can artificial life have any scientific content. If you confine yourself enough, of course, then the answer to both questions is a qualified "yes", but the question then becomes, does it tell you anything meaningful about anything? Larry's talk showed that even quite abstracted artificial life scenarios still give some high-level information about the potential for systems design, especially for very dynamic adaptive systems in changing environments.

Larry's work has focused on building multi-agent simulations of processes, seeing how simple rule sets can give rise to complex behaviours. This has culminated in a system called Polyworld, that lets users set up "genetically" based  behaviours for agents. (There are some very cool movies of it all working.) The genetic basis -- completely synthetic and higher-level that real genetics -- means that agents can evolve through mutation and cross-over.

The part I found most interesting was the way that these systems -- like the natural systems they're abstractions of -- tend not to do optimisation per se. Instead they find, and stick with, solutions that are "good enough". You get to a balance between evolutionary pressure not being strong enough, and the benefits not being great enough, for further changes to take place. The difference with traditional engineering is quite profound, both in this satisfaction with the sub-optimal but also in the fact that the selection is dynamic, so if the chosen approach ceases to be "good enough" as the environmental pressures change it will shift to another process as a matter of course. You get this dynamism all over chemistry, too, where chemical equilibrium remains a dynamic process with lots of reactions going on all the time without changing the macroscopic concentrations of the reagents involved. It's easy to mistake this for a static system, which it most definitely isn't: I think this is a mistake a lot of scientists and engineers make, though, and it's something we probably need to address when designing adaptive systems or sensor networks that need to operate against or within a complex environment. To do this we'd need to give up a lot of intuitions we have about design, and the possibility of a single "correct" solution to a problem, and think instead of a design space in which the system is (to some extent) free to explore -- and make this design space, and the exploration of it, concepts that are propagated to run-time.

I think this kind of approach makes sense even if you don't embrace the genetic algorithms style view of the world (which in the main I don't). In some ways this is a measure of the success of artificial life research: it's illuminating concepts that are of general utility outside the context from which they're being drawn, that can be used to influence other approaches to systems design without our having to junk everything we already know, which we're clearly not going to do. These sorts of incremental changes are far more useful than revolutions, in many ways, but they come about from thinking that's more-or-less divorced from mainstream thinking. It's a good illustration of why blue-skies research is important, and that knowledge really is all one piece with interconnections and interactions that we can't predict.

Forth, 2^5 years ago

2^5 years ago this month, Byte magazine devoted an issue to the Forth language.

Byte ("the small systems journal") volume 5 number 8, August 1980, was largely devoted to Forth. I only discovered this by accident, researching some background for a paper I'm writing on extensible virtual machines. What's even more remarkable is that you can download the issue -- along with a lot of others -- as a PDF.

That the premier hobbyist/hacker magazine of its day would give over most of an entire issue to one language tells you something about the way people thought about programming their machines back then. There was a premium on compactness: one of the first adverts in this issue of Byte is for a Cromenco Z-2H with 64Kb of RAM and 11Mb of hard disc, and proudly claiming that it  "is under $10K".

One article is a history of Forth, one is a tutorial, and two are deeply technical programming pieces aimed at people comfortable with the idea of writing their own software pretty much from scratch  -- and indeed, keen to get on with it. What's more, they could write software as good or better as that which they could buy (to the extent that there was any hobbyist software to buy). That's not something we've been able to say for at least the last 2^4 years: hobbyist software hasn't competed with commercial offerings in most domains for a long time.

I think there were a number of things going on. The simplicity of the machines was obviously a bonus: one could understand the hardware and software of a personal computer in its entirety, and contemplate re-writing it from the ground up as an individual or small group.

Expectations were lower, but that works both ways: low expectations coupled with low-performance hardware can still lead to some impressive software. But it's certainly the case that one of the main barriers to software development from-the-ground-up these days is the need to interface with so many devices and processes in order to do anything of interest: any new system would need to talk to flash drives and the web, which probably means writing device drivers and a filing system. You can get round this using hardware packages, of course: Zigbee radios have simple programmer interfaces and encapsulate the software stack inside them.

Another factor, though, was a difference in ambition. A hobbyist in the 1980's only had herself and her friends to impress (and be impressed by): the horizon was closer. I'm sure that led to a lot of re-definition and duplication that the internet would allow one to avoid somewhat, but in some senses it provided a better learning environment in which a sequence of problems needed solution from a programmer's own creativity and resources. That's a significantly different skill set than what's required today, where we place a value on compliance, compatibility and re-use at least as high as we place on creativity and innovation.

I'm not advocating a return to the past -- although programming in Forth for sensor networks does give me a tremendous sense of pleasure that I haven't felt in programming for a long time, at least partially derived from the old-school nature of it all. However, I would say that there's also value in this old-school style even today. The hackers who read Byte wouldn't settle for sub-standard tools: they wouldn't think twice about re-coding their compilers and operating systems (as well as their applications) if they were sub-standard. That power brings on a sense of power -- the ability to change what's perceived to be wrong in something-- that's to be celebrated and encouraged even today, amongst programmers who sometimes seem to be constrained by their toolchains rather than freed by them.

MSc/PhD positions available in wireless location systems

UCD Dublin is looking for potential PhD students interested in wireless location systems.

Ph.D. and M.Sc. Studentships in WiFi Location

UCD Dublin is currently potential Ph.D. and M.Sc. students in the Complex and Adaptive Systems Laboratory and the School of Computer Science and Informatics, University College Dublin (UCD), Ireland. The studentships are part of a collaborative international project to research and develop novel algorithms, solutions and applications for indoor localization based on WiFi.

The successful candidates will have obtained, or will expect to obtain, a 1st class or 2.1 Honours degree in Computer Science, Electronic Engineering, or a related discipline. For the Ph.D. position, a Masters degree or commercial experience in a relevant area is an advantage. Preference will be given to applicants with expertise in one or more of the following areas: Digital Signal Processing, Location Estimation, and Wireless Communications.

We expect that the Ph.D. positions will be funded for 4 years while the M.Sc. position will be funded for 2 years. All positions are full-time. The positions will include payment of a tax-free student stipend and fees. The anticipated starting date for the positions is 1st October 2012, or as soon as possible thereafter.

Enquiries should be sent to Dr Chris Bleakley, Complex and Adaptive Systems Laboratory (CASL), School of Computer Science and Informatics (CSI), University College Dublin (UCD), Belfield, Dublin 4, Ireland; email: chris.bleakley@ucd.ie; tel: +353 1 716 5353.

http://www.csi.ucd.ie/vacancy/phd-and-msc-studentships-wifi-location

[Updated 13Aug2012 with final confirmation of the grant.]

Scholar positions for Erasmus Mundus MSc in Dependable Software Systems

We have some short-term Scholarship positions available in dependable systems.

The University of St Andrews and NUI Maynooth have the first edition of the new Erasmus Mundus MSc in Dependable Software Systems (DESEM) starting in September. There are EMMC Scholar positions available on this programme. These scholars will engage in teaching and help with the evaluation of student project work among other duties.

Positions have to be held for a minimum of 2 weeks. The Scholarship value is € 2,400 for a two-week stay with a maximum of € 14,400 for a three-month stay. We have the equivalent of 17 two week scholarships available for 2012/13.

Applicants have to be associated with a third country (non-European) HEI.

Details are available from: http://erasmusmundus.nuim.ie/courses/desem/node/53

Call for papers: Midsens 2012

The Seventh International Workshop on Middleware Tools, Services and Run-time Support for Sensor Networks (MidSens’12) will be co-located with Middleware 2012 (December 3rd - 7th, 2012) in Montreal, Canada

The aim of MidSens'12 is to stimulate research in the specific domain of middleware for sensor networks. The particular focus of MidSens'12 is the realization of multi-user, multi-purpose and federated sensing platforms that are capable of supporting next-generation application scenarios such as smart cities. Along with the core topic of middleware architectures, services and tool support, MidSens'12 will also seek papers describing novel programming languages, run-time support and relevant experience reports. MidSens'12 will investigate how middleware support can relieve developers from low-level, platform specific concerns, while enabling the optimal exploitation of heterogeneous resources to create sensing infrastructures of massive scale.

Effectively developing, deploying and managing sensor network platforms requires supporting middleware services, tools and run-time support. MidSens'12 welcomes papers on the following research topics:

  • Middleware Tools and Architectures:
    • Software architectures for sensor networks
    • Novel programming abstractions for large-scale sensor networks
    • Architectures to combine mobile devices and sensor motes
    • Lightweight autonomic middleware for embedded systems
    • Testing and simulation tools for sensor network middleware
    • Fault identification, diagnosis and repair
  • Middleware services:
    • Location tracking, localization, and synchronization.
    • Support for real-time and safety-critical systems.
    • Data management, aggregation and filtering.
    • Energy-aware middleware mechanisms.
    • Fault tolerance, reliability and quality of service.
    • Privacy and security services.
    • Virtualization, sharing and trading of resources.
  • Run-time Support:
    • Overlay and topology creation, maintenance and management.
    • Resource/Service discovery and management.
    • Support for reconfiguration and adaptation.
    • Effective naming and addressing schemes.
    • Support for modeling and enacting safe software reconfiguration.
  • Management and Experiences:
    • Managing heterogeneity and network dynamism.
    • Integration of embedded systems with web services.
    • Experience and evaluation of middleware platforms.
    • Support for the unification of various embedded platforms.
    • Shared infrastructure embedded systems.
Submitted papers must be original work in English without substantial overlap with papers that have been published or that are simultaneously submitted to a journal or conference with proceedings. Submissions must not exceed 6 pages, must strictly follow the ACM conference proceedings format, and must be submitted in PDF format.

All accepted papers will appear in the ACM Digital Library and will be indexed in DBLP.

Important Dates:

  • Paper Submission deadline: August 15, 2012
  • Acceptance notification: September 21, 2012
  • Author registration deadline: October 5, 2012
  • Camera-ready version due: October 5, 2012
  • Workshop: December 3-7, 2012

Workshop on naturally-inspired service ecosystems

The Sapere project (of which I'm a member) is running a workshop at SASO 2012 in Lyons on new ways to design service ecosystems.

Emerging distributed computing scenarios (mobile, pervasive, and social) are characterised by intrinsic openness, decentralisation, and dynamics. According, the effective deployment and execution of distributed services and applications calls for open service  frameworks promoting situated and self-adaptive behaviours, and supporting diversity in services and long-term evolvability. This suggests adopting nature-inspired and/or socially-inspired approaches, in which services are modelled and deployed as autonomous individuals in an ecosystem of other services, data sources, and pervasive devices. Accordingly, the self-organizing interactions patterns among components and the resulting emerging dynamics of the system, as those of natural systems or of social systems, can inherently exhibit effective properties of self-adaptivity and evolvability.

Although many initiatives (like those named upon digital/business service ecosystems) recognise that the complexity of modern service systems is comparable to that of natural ecosystems, the idea that nature – other than a mean to metaphorically characterise their complexity – can become the source of inspiration for their actual modelling and implementation is only starting being metabolised.

The goal of this workshop is to bring together researchers and practitioners, with the aims of unfolding the many challenges related to the modelling, design and implementation of adaptive service ecosystems in natural and social terms, and identifying promising approaches and solutions.

Topics of interest include, but are not limited to:

  • Software architectures for  emergent distributed systems.
  • Bio-inspired self-organising patterns design patterns.
  • Coordination models and languages.
  • Middleware platforms
  • Dynamic services composition.
  • Adaptive coordination models and patterns
  • Self-organisation and coordination
  • Coordination in systems of feedback loops
  • Middleware for adaptive coordination
  • Multiagent systems
  • Methodologies for adaptive and self-organising system engineering
All accepted papers will be published by IEEE Xplore following the workshop.

Submission deadline is 4 July 2012. For more details please see the workshop web site.

UPDATE: Fixed typo in the submission deadline

Layered abstractions and Russian dolls

The layering of abstractions has served us well, but it's now generating the sorts of complexity it was designed to solve. Time for a re-think?

Anyone who's built a large piece of software knows that much of the effort is in managing the complexity of the project: which other software a piece of code relies on, how to keep the various aspects separate, how to manage changes and upgrades, and so on. This isn't something that's got easier over time: it has for a given code size and style, as we've understood build processes and dependency management better; but the code sizes have relentlessly increased to compensate for our improved understanding; and modern practices don't make life any easier. Downloaded code, dynamic modules and classes, client-server and the like all generate their own intrinsic complexity.

One of the biggest sources of complexity is the use of multiple applications, especially in enterprise systems. A typical e-commerce system, for example, will make use of a web server to present pages (which themselves might contain embedded JavaScript for client-side processing), a database to track orders and inventory, a procurement system to fulfil orders, and possibly a supply-chain management system to order new inventory. That's the application. Then there'll be the operating system, a logging facility, a facilities management system, and a load of administrative tools and scripts. And the operating system may itself be virtualised and running as a guest within another, host operating system and hypervisor, which needs its own toolset. The interactions between these tools can be mind-boggling.

Someone once asked: who knows how to work the Apache web server? It sounds like a simple question -- any competent web manager? the main developers? -- but the sting in the tail is that Apache is very configurable: so configurable, in fact, that it's pretty much impossible to work out what a given combination of options will do (or, conversely, what combination of options to use to achieve a given effect). The interactions are just too complicated, and the web abounds with examples where interactions between (for example) the thread pool size, the operating system block size, and the Java virtual machine parameters conspire to crash a system that looks like it should be working fine. If you can't work one server properly -- one component of the system -- what hope is there to get a complete system humming along?

Al Dearle and I have been talking about this for a while. The basic issue seems to be an interaction between decomposition and dependency. In other words, the complexity comes at the "seams" between the various sub-systems, and is magnified the more configurable the components on either side of the seam are. This is important, because systems are becoming more finely decomposed: the move to component software, software-as-a-service and the like all increase the number of seams. Al's image of this is that modern systems are like Russian dolls, where each supposedly independent component contains more components that influence the size and complexity of the component containing them. You can only simplify any individual piece so far, because it depends on so many other pieces.

Actually a lot of the seams are now unnecessary anyway. Going back to the e-commerce example, the operating system goes to great pains to provide a process abstraction to keep the components separate -- to stop faults in the database affecting the web server, for example. Historically this made perfect sense and prevented a single faulty process in a time-sharing system affecting the processes of other users. Nowadays, however, it makes considerably less sense, for a number of reasons. Firstly, all the components are owned by a single nominal user (although there are still good reasons for separating the root user from the application user), so the security concerns are less pronounced. Secondly, all the components depend on each other, so a crash in the database will effectively terminate the web server anyway. (We're simplifying, but you get the idea.) Finally, there's a good chance that the web server, database and so on are each running in their own virtual machine, so there's only one "real" process per machine (plus all the supporting processes). The operating system is offering protection that isn't needed, because it's being provided (again) by the hypervisor running the virtual machines and perhaps (again) by the host operating system(s) involved.

We also tend to build very flexible components (like Apache), which can deal with multiple simultaneous connections, keep users separate, allow modules to be loaded and unloaded dynamically -- behave like small operating systems, in other words, replicating the OS functionality again at application level. This is despite the fact that, in enterprise configurations, you'll probably know in advance the modules to be loaded and have a single user (or small user population) and fixed set of interactions: the flexibility makes the component more complex for no net gain during operation. Although it might simplify configuration and evolution slightly, there are often other mechanisms for this: in a cloud environment one can spin-up a replacement system in an evolved state and then swap the set of VMs over cleanly.

It's easy to think that this makes no difference for modern machines, but that's probably not the case. All these layers still need to be resourced; more importantly, they still need to be managed, maintained and secured, which take time to do well -- with a result that they typically get done badly (if at all).

Can we do anything about it? One thought is that the decomposition that makes thinking about systems and programming easier makes executing those systems more complex and fragile. In many cases, once the system is configured appropriately, flexibility becomes an enemy: it'll often be too complicated to re-configure or optimise in a live environment anyway. There may be a reason to have Russian dolls when designing a system, but once designed it's better to make each doll solid to remove the possibility of then opening-up and falling apart.

So it's not decomposition that's the issue, it's decomposition manifested at run-time. When we add new abstractions to systems, we typically add them in the form of components or libraries that can be called from other components. These components are often general, with lots of parameters and working with multiple clients -- sound familiar? This is all good for the component-writer, as it lets the same code be re-used: but it bloats each system that uses the component, adding complexity and interactions.

So one thought for tackling complexity is to change where decomposition manifests itself. If instead of placing new functions in the run-time system, we placed it into the compiler used to build the run-time, we could use compilation techniques to optimise-out the unnecessary functionality so that what results is optimised for the configuration that it's actually being placed in, rather than being general enough to represent any configuration. There's substantial work on these ideas in the fields of staged compilation and partial evaluation (for example MetaOCaml, Template Haskell, Flask and the like): the flexibility is manifested at compile-time as compile-time abstractions, that in the course of compilation are removed and replaced with inflexible -- but more efficient and potentially more dependable -- specialised code. Think taking the source code for Linux, Apache and MySQL, accelerating them together at high speed, and getting out a single program that'd run on a bare machine, had nothing it didn't actually need, and had all the options for the various (conceptual) sub-systems set correctly to work together.

Don't believe it's possible? Neither do I. There's too much code and especially too much legacy code for this to work at enterprise (or even desktop) level. However, for embedded systems and sensor networks it's a different story. For these systems, every extra abstraction that makes the programmer's life easier is a menace if it increases the code size hitting the metal: there just isn't the memory. But there also isn't the legacy code base, and there is a crying need for better abstractions. So an approach to the Russian dolls that moves the abstractions out of the run-time and into the languages and compilers might work, and might considerably improve the robustness and ease of use for many systems we need to develop. It also works well with modern language technology, and with other trends like ever-more-specialised middleware that remove bloat and overhead at the cost of generality. Keeping the former and the latter seems like a worthwhile goal.