On 2/12/10 8:29 AM, "Les Mikesell" <lesmikes...@gmail.com> wrote: > On 2/10/2010 8:30 AM, nwat...@symcor.com wrote: >> I'm a pretty good perl hacker. I often refer to perl as my Swiss army >> knife. However, using perl on the scale Cfengine is designed to handle >> would be difficult. Having to keep a collection of perl modules, and >> dependencies, all at the correct version across dissimilar UNIX platforms, >> some of which are years behind, would be difficult. > > Have you had any bad experiences in this regard? I've considered perl > to be the most meticulously backwards-compatible language I've ever seen > and am fairly sure that scripts I wrote under perl version 1 would run > unchanged today with the single exception of how @ is handled in > double-quoted strings. By contrast, python has broken thing regularly > in its much shorter life - even rpm and yum within the same > distribution, supposedly maintained together. Even things I wrote in > K&R C back in the day would likely need more changes than perl code to > run today.
I'm partially to blame for starting it, but I'm honestly not sure where this discussion is going... I agree perl has uses (e.g. text processing in Python is generally slower), and cfengine certainly does too. I don't think we could ever hope (or would honestly want to request) that the new cfengine syntax change at this point -- too much has obviously been invested, and we'd never get heard anyhow. My point when originally raising an eyebrow over the new syntax was that something simpler than even perl would generally be a good thing for system admins (not programmers). The more immediately readable a policy, the more like documentation it becomes and the easier it is to maintain. The fact cfengine now has in-built documentation features (like other full-blown programming languages) seems to support the obvious fact complexity has increased at an expense to readability. Looking back to the car/engine analogy Mark presented... I disagree. Cfengine is not really like the engine at all. That is the source code, as another pointed out. Going further, cfengine (in my mind of course) is really much more like the interior controls. It's an interface between the driver (admin) and rest of the car (what we want to control). I shouldn't need to be an ACE certified technician to drive a car. Better car interiors (Audi/Porsche typically receive high ranks) are more minimalistic, and functionally driven (so as not to distract from driving). There is not a button for every variable one could control by connecting to the ECU. In the sense of an "interface" between the admin and controllable assets, cfengine's syntax is a sort of API. Generally, APIs try to be backwards compatible and not force complete re-learns across versions. Of course this is just one perspective. However, it is a perspective based upon the reality of promoting and teaching cfengine to a growing group of admins... Those admins generally had completely different reactions when looking at cf2 and cf3. The first time around I saw receptive faces and received comments like, "Wow, this almost reads like English!" Now, I am receiving looks of fear and frequent requests to put off upgrading for as long as humanly possible -- not what I want. >> One of the nice >> things about Cfengine is that it is mostly self contained with few >> dependencies. > > I'm not sure I follow this. The part that is important to me is whether > I have to do my coding work over again and whether things break during > updates as a result of gratuitous language changes - and being > self-contained just means I have to do more of this work myself as > special cases. If cfengine were included in distributions that update > and I had started with cfengine v1, would most of my code still be > running today? If that's not the case historically, should I expect it > going forward any more than I should for python? Having worked in shops where we built our own internal system (perl with shell glue) -- I am painfully aware of what he's talking about. The extra care and feeding required to maintain all your own modules and supporting bits (irrespective of what versions the base OS or other installed applications may use) does require thought and can bite you if mishandled. It's not hard, but it is one more thing to think about. I like that cfengine really only needs openssl and bdb. Granted... I have had to work out how to upgrade those packages outside of cfengine (especially openssl). For the record, none of what I say should be taken as an insult or attack. I have used cfengine for many years, and plan to continue doing so. I have a vested interest in seeing cfengine succeed and continue to evolve. I can even understand we may come to agree the new complexity is required (I won't argue the cf2 parser had many flaws, ordering was a royal PITA, etc), but for now I'm just basing my initial thoughts on experiences I have had promoting the new tool. The fact I'm not pulling punches and inflating egos when I describe what's encountered in the field should be taken as a desire to provide honest, constructive criticism. For better or worse. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
