Alexis,

Thanks for sending that paper out. It was a fun read to start my day.

I think it's only tangentially relevant to Helm because Helm is a package manager rather than a build tool. A comparison that looked at tools like apt, yum, chocolatey, brew, and so forth would be a more relevant to Helm. Not to say there aren't concepts described in the paper that are important. I just want to make sure we're all on the same page for Helm's scope.

I got a real kick out of the way Excel is discussed in the build sense to highlight dynamic capabilities in a build system.

I was a little disappointed that container based systems, like drone and concourse, weren't brought up. The way container images are used to handle tasks is an interesting take.

For anyone interested in the benefits of bazel, especially on language tooling that doesn't have build caches the way Go does, this paper does have some nice insight.

Thanks again for sharing.

On Tue, Mar 20, 2018 at 5:36 AM, Alexis Richardson <alexis@...> wrote:

Hi

Dropping Computer Science, right about now...

Ilya dug up this new paper from Simon Peyton-Jones (MS Research) and
others.  They look at build systems from a theoretical POV.  Their
objective is relevant to Helm, although their notion of build is
richer.

"We have investigated multiple build systems, showing how their
properties are consequences of two implementation choices: what order
you build in and whether you decide to rebuild. By decomposing the
pieces, we show how to recompose the pieces to new points in the
design space. In particular, a simple recombination leads to a design
for a monadic cloud build system. Armed with that blueprint we hope to
actually implement such a system as future work."

This may also be relevant to wg-app-def folks.

alexis

--

Matt Farina

mattfarina.com

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.