+1 Mark. This was awesome.
On 12/16/11 3:49 AM, "Mark Burgess" <m...@cfengine.com> wrote:
>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
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
