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 <ashley.pen...@puppetlabs.com
> wrote:
> On Mon, Aug 4, 2014 at 12:09 PM, Reid Vandewiele <r...@puppetlabs.com>
> 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
> ashley.pen...@puppetlabs.com
> 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 puppet-dev+unsubscr...@googlegroups.com.
> 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
tvaug...@onyxpoint.com
-- 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 puppet-dev+unsubscr...@googlegroups.com.
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.
