Make Distributed Programming Fun Again

Printer-friendly version
  • A working knowledge of distributed programming
  • An interest in programming languages and their implementation

Distributed programming is hard for a number of reasons. First, it requires one to construct a mental model of the envisioned system in which the system acts as a coherent whole while parts of the system reside on different autonomous machines. Second, failure of distributed components is the norm rather than the exception (as is traditionally the case for non-distributed systems). As such, when writing distributed programs one needs to continously make sure that the failure of a single component does not hamper the overall performance of the distributed system. Finally, good distributed design is inherently asynchronous. While earlier technology relied heavily on synchronous communication (e.g. Java RMI), current technology has stepped away from this model to favour a asynchronous one (e.g. Javascript/Node.js). In order to deal with this asynchrony one traditionally relies on callbacks which are invoked as the result of externally produced events (e.g. message sends). However, these callbacks significantly complicate the writing and comprehension of code. One can no longer lexically determine the order in which statements will be executed since this order depends on the ordering of incoming events. Furthermore, callbacks are non-composable which entails that combining results from different callbacks is achieved through the use of global variables (which is usually regarded as a big no-no in software engineering).

The so-called callback hell (i.e. reasons why distributed programming is hard 3) has recently been solved by a new paradigm called reactive programming. This paradigm allows one to explicitly deal with asynchronously time-varying values in a declarative way. A traditional example of this is the following expression: (define minutes (/ seconds 60)) . Such a reactive expression will be re-evaluated by the language runtime as soon as the time-varying value on which it depends (i.e. seconds ) changes. Although reactive programming has proven to be a powerfull paradigm, it has yet to be applied in a distributed context.

Goal & Research Activities: 

In this thesis you will investigate whether reactive programming can solve the remaining two issues with distributed programming (i.e. the complex mental architecture and handling distributed failure). To do this you will design and implement your own distributed reactive language. This will require you to both extend the existing non-distributed reactive paradigm to a distributed one as well as introduce new reactive native constructs (e.g. constructs to deal with partial failure of a distributed component).

Concretely we foresee the following steps as a high-level roadmap:

  • A literature study on reactive programming
  • The adaptation existing reactive programming language constructs to deal with distribution
  • The creation of new reactive constructs to deal with distribution-specific aspects (e.g. partial failure)
  • The design and implementation of a full-fledged distributed reactive language (you can choose any existing distributed technology as a runtime for your language)
  • A study assesing the advantages and drawbacks of your language compared to a traditional distributed language
  • Bainomugisha, E., Carreton, A. L., Van Cutsem, T., Mostinckx, S., & De Meuter, W. (2012). A survey on reactive programming. In ACM Computing Surveys.
  • Czaplicki, E., & Chong, S. (2013, June). Asynchronous functional reactive programming for GUIs. In ACM SIGPLAN Notices (Vol. 48, No. 6, pp. 411-422). ACM.
  • Salvaneschi, G., Drechsler, J., & Mezini, M. (2013, June). Towards distributed reactive programming. In Coordination Models and Languages (pp. 226-235). Springer Berlin Heidelberg.