On Sunday, August 3, 2014 4:32:39 PM UTC-7, henrik lindberg wrote:
>
>
> My main objection with create_resources function is that it is not a
> natural progression from the language. When developing puppet code, you
> start out with simple resources and use the syntax for creating them. As
> you are building up your modules and complexity increases you reach a
> point where you have to redo what you have already done because now you
> have to instead construct a hash and call a function.
>
> When you have reached this point several times, you are more likely to
> always use create_resources.
>
> When instead directly supported in the language, you can add the more
> advanced things if and when they are needed.
>
> Having the power to do so, does not take anything away.
>
> - henrik
>
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.
--
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/25847473-d8a7-48e2-a4df-e430374e4f9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
