So, I'm chiming in to say that I completely agree with Reid and Ashley. As an end user, I want to hand off code that is clear and relatively easy to read. I definitely do not want magic symbols (or I would have stuck with PERL).
I'm OK with all of the concepts proposed but I would like more verbosity and clarity as opposed to more 'elegance' and mystery. Thanks, Trevor On Mon, Aug 4, 2014 at 12:22 PM, Ashley Penney <[email protected] > wrote: > On Mon, Aug 4, 2014 at 12:09 PM, Reid Vandewiele <[email protected]> > wrote: >> >> >> I am concerned that adding additional operators to the language does in >> fact take something away. As such, I do think that proposals to do so need >> to require a very strong argument in order to proceed. >> >> When I go out and introduce new teams of sysadmins to Puppet, the fact *in >> vacuo* that we have our own domain-specific language is anything but a >> strength. One of the top initial objections to Puppet today is that large >> teams will not be able, or will not want, to learn a new, complex language. >> What sets us apart from competitors like Chef, from scripting alternatives, >> is the simplicity and apparent intuitive design of our DSL. The fact that >> it is more akin to a configuration file than to a procedural program. That >> a sysadmin can look at a Puppet manifest and usually figure out the basics >> of what it does and even modify it without needing a training course or a >> pocket reference. Every operator that is added to the language has the >> potential to take away from that, and so absolutely needs to be approached >> as a design decision focused on the end-user experience. >> >> We need the ability to better transform structured data into resources. >> From an end-user experience perspective (setting aside implementation >> considerations) I much prefer the idea of using a hash directly over >> introducing a new operator. The difference would be the two examples shown >> below. >> >> Proposed operator (proposed): >> $x.each |$title, $attributes| { file { $title: * => $attributes } } >> >> Formal hash treatment (my preferred): >> $x.each |$title, $attributes| { file { $title: $attributes } } >> >> If we introduce a new operator it should be a user-experience design >> decision, not an implementation decision. If the preferred design cannot be >> implemented due to technical constraints that's something we have to deal >> with. But I hope that we're arriving at decisions to introduce new >> operators as part of an intentional end-user experience focused design. >> >> The fact that we have a DSL is not a strength. The fact that it is simple >> and intuitive to practitioners in this space, is. >> > > I've been unable to articulate my concerns with the current language > discussions but I think Reid has done a good enough job that I feel > comfortable contributing. It seems like all the talk is now about the > "Puppet language" instead of the "DSL" and this is, in my opinion, a > mistake. > > We seem to be trying to build a general purpose language that is powerful > enough to write other things in, such as functions, types and providers, > etc. We already have languages for those and I don't think that we can > build a better language internally than these external languages. > > As a member of the module team I honestly haven't understood a large part > of the proposed enhancements over the last year, or really understood the > need for them. There seems to be a bit of a disconnect between people who > write modules and people who like languages in a lot of the conversations. > > Some enhancements, like improvements to defaults, make sense. Things like > putting resources into $a and then being able to do things with them just > make the DSL much more difficult to teach, reason able, and expose to > systems administrators. I too prefer the hash to a * operator, it's > follows the patterns of the DSL that we've been using for years and (to my > non-developer brain) makes more sense. > > I've tried to raise these concerns in the past but I've done a bad job of > talking to platform people about it. I think that the separation between > people building the language and people writing the modules has the > potential to do us a lot of harm. At the very least all these language > proposals and suggestions and syntax changes should come with "real > production code" examples that show how you solve it today and how this > proposed change leads to a more elegant situation for actual puppet users > because right now it seems to be happening in isolation from the people > using it to build things. > > -- > Ashley Penney > [email protected] > Module Engineer > > *Join us at PuppetConf 2014**, September 23-24 in San Francisco > - http://puppetconf.com <http://puppetconf.com/>* > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAC9eg%2BkFefgHzYJmYU5k9%3DF-EhMj3h3y9O9qNGDQigKpzx0ewA%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CAC9eg%2BkFefgHzYJmYU5k9%3DF-EhMj3h3y9O9qNGDQigKpzx0ewA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXRvOqmdxrOYG-Y5ZEMbAK5_9GC0B__f_K%2Bxijy0i9u_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
