On 12/16/2011 09:15 AM, Erlend Leganger wrote:
> I wasn't talking about the JSON support (but I can see why you thought
> I did), I just think the following is a good idea:
>
> Instead of writing this:
>
> ...
> depth_search => recurse,
> ...
> body depth_search recurse {
> depth => "inf";
> }
>
> I would like something like this:
>
> depth_search => { depth => "inf" }
>
> This may increase the size and complexity of the cf3 parser, but it
> would make my cf3 code clearer and less verbose. I cannot quite follow
> why this isn't good knowledge management, but then again, I'm only
> using cf3 community as a tool to satisfy my needs for assuring
> consistent configuration across servers, I'm not sure that qualifies
> as knowledge management.
>
> -
Erland,
I know that people have said this several times, but I am going to
disagree with you anyway. It looks very innocent when you write this one
small example, but in a real case the opposite would be true. What you
"advocate" here is to make every instance standalone, removing
extractable patterns. That only works for a simple case where there is
little reuse of information. It is a bit like taking a program with
functions/procedures and removing them all, putting everything inline --
this is how "gotos" got a bad name in programming.
I spent a long time (5 years actually) looking at why cfengine 2 got out
of control, and this kind of inline parameterization is one of the
reasons. Look at this example of CFEngine 2 code
/usr/lib dest=$(ftp)/usr/lib
recurse=2
mode=444
owner=root
backup=false
include=ld.so*
include=libc.so*
include=libdl.so*
include=libmp.so*
include=libnsl.so*
include=libsocket.so*
include=nss_compat.so*
include=nss_dns.so*
include=nss_files.so*
include=nss_nis.so*
include=nss_nisplus.so*
include=nss_xfn.so*
include=straddr.so*
In CFEngine 3 syntax we have managed to reduce 10,000 lines of code down
to 1000 due to the absorption of irrelevancy using the body templates.
The interesting part of the code is not what all of these attributes
actually are, but what is the *intention*. Now we can write
"$(ftp)/usr/lib"
perms => simple1,
depth_search => simple2,
copy_from => x("/usr/lib");
And you can sprinkle parameters where you want for *clarity of
communication*, not for programming necessity.
As a teacher of many years I will share an experience that sounds
arrogant but which is very true: people are rarely the best judge of
what is good for them unless they have thought very, very carefully
about everything. Most of us react instantly to what looks nice right
now and don't think about the wider implications. That is my job: "CTO"
= "Clear Thinking Organizer". So we need to encourage a shift away from
programming towards knowledge management.
A programmer thinks mainly about him/herself when writing code, but the
code in CFEngine is documentation about the system first and foremost.
It is meant for the long term to assist understanding. Reducing the
complexity of information through patterns is a key strategy for this,
and it has been my intention to make it hard for people to fall back
into bad practices. That is always a sensitive issue, but it has always
been my intention to challenge people to think differently and "better"
about issues.
This does not mean that the discussion is over, as there are plenty of
things we can do to make CFEngine 3 even simpler to understand. I hope
to come back with something on this in the new year.
hope this explains my thinking a little better
Mark
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
