Addendum:
Sorry again for forgetting the link
http://www.infoq.com/presentations/Simple-Made-Easy
It is worth commenting on two ways in which this talk applies to CFEngine, (in
my personal view).
What I like about the talk is that it is not dogmatic, but poses questions. The
speaker
says that certain things are good and bad, but does not claim that certain bad
things are unavoidable, only
undesirable in a perfect world. CFEngine was needed because we don't live in a
perfect world.
The talk is about how to limit it to what is "necessary and sufficient" and it
applies to CFEngine at two levels:
1. the design and principles used by CFEngine for the problem of modelling
configuration
e.g. CFEngine's language design seems to satisfy all the speaker's requirements
for simplicity.
With reference to the inline body-syntax we discussed recently in the forum, I
believe inline
syntax complects "what" with "how" by abusing syntax to mis-represent
information (that puts it
strongly to underline the point).
The speaker suggests that one should *try* to avoid complexity, but CFEngine's
job is to cope with / model
configuration complexity that others have created, i.e. (state) in a simple
way. The disciplines it brings
encourages users to design simplicity, making things more declarative and
non-intertwined (autonomous) and eliminating
imperative threads that complect what with how.
This complexity cannot necessarily be removed (there is a concept of necessary
and sufficient complexity),
so we should not *oversimplify* a model.
We try to cope by imposing a simple discipline on the representation of state
by disentangling independent issues
into promise types with body types, using a meta-model called "Promises",
together with the concept of convergence
(persistence of state).
2. the internal design of CFEngine's implementation.
In writing CFEngine 3, the use of the promise model led to considerable
disentanglement of code, compared to CFEngine 2,
though there might still be parts in the lower subsystems that could be
further disentangled. It was necessary
to have a model to understand how to disentangle issues. In my view
Puppet more deeply entangled the modelling
issues, sacrificing simple for easy.
It would be an interesting exercise for the development team to discuss
how the principles the speaker expounds
apply to different parts of the code.
Personally, I would have liked to hear what the speaker had to say about
global data/variables, since this is an area where
I noted the speaker's words (paraphrased): "Let data be data, don't hide
it behind an API" with agreement. I read this as
an argument that global data/variables have a valid place in
programming, as long as one copes with the inevitable
changes of state.
M
-------- Original Message --------
Subject: How easy/simple is cfengine?
Date: Sat, 17 Dec 2011 10:09:12 +0100
From: Mark Burgess <m...@cfengine.com>
To: help-cfengine <Help-cfengine@cfengine.org>
Mikhail, one of our very brilliant developers, recently brought this
talk to my attention. I just had time to look at this and it is very
good. The talk is a most excellent discussion about making choices about
easy versus simple in software. I recommend everyone to watch this and
absorb its content.
It is very relevant to the discussion about making CFEngine
easier/simpler, also vis a vis the choices made by Puppet/Chef versus
CFEngine, etc etc - and I very much agree with the speaker's viewpoint.
He does not provide any answers, but he poses important questions: the
best kind of talk.
M
PS - Category theory (re: monads) is a form of mathematics, akin to set
theory which is often used to explain anything by pulling the wool over
people's eyes :)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
