Reading Summary 2019.06.05

· by Aldrin Montana

Logic and Lattices for Distributed Programming

Overall Evaluation

This paper discusses extensions to Bloom to accommodate lattices in multiple domains. The paper then describes the various details to be accounted for as part of the extension: how does CALM extend to lattices, how are lattices defined and used in set-oriented logic, how do built-in lattices work, etc.

In general, I like this work because it provides compelling extensions to a language in a very concise way. There are certainly directions in performance available, but I also think the utility of datalog and datalog-like languages are still increasing and expanding to more domains.

Strong Points

1. I feel like this point is not discussed in detail, but the semi-naive evaluation strategy discussed in 4.1 seems to naturally lend itself to be easy to garbage collect. While I think it would have been interesting to discuss this point and what pitfalls may exist for more aggressive garbage collection strategies, I think that this is an indirect benefit of this evaluation strategy. With regard to the evaluation included in the paper, perhaps even showing performance of garbage collection strategies would be really nice, since many other distributed systems papers do not discuss this metric.

2. 3.

Weak Points

1. I felt that figure 5 and the discussion of performance wasn’t particularly satisfying. It is already claimed that BloomL is a relatively minor change from Bloom, and the Bloom paper (Consistency Analysis in Bloom) does not have much runtime evaluation itself. Of course, I appreciate that some performance metrics were included, but I think it would have been more interesting to maybe target a specific component or piece of a distributed system to get a more interesting comparison against an implementation that is not Bloom at all. It would have even been useful if section 4.2 discussed at a high level what other datalog-like implementations or distributed systems compute the transitive closure of a graph and have performance metrics, so that some baseline could be established even if not within the scope of this paper.

2. 3.

Questions Raised

1. I feel that an aspect of evaluation that never seems to come up is something of an HCI approach: given a task and maybe some example code, ask a developer to implement the task and see how well it performs. As a follow up evaluation, have that person try to improve a sub-optimal implementation. Since this work on CALM and bloom takes a different approach to addressing monotonicity compared to CRDTs, and because the whole point of CRDTs and CALM is to make writing distributed programs easier (I think), it seems like usability or programmability should be an important aspect of evaluation.

2. I wonder if adding fixpoint semantics to other languages would be all that is needed to make them more concise for the use cases described in this paper.

Research Connections