On Apr 11, 2016, at 9:17 AM, Alex Harvey <alexharv...@gmail.com> wrote:
> An example might be abstract data types. I know that the data types had > issues, oddities and bugs around the implementation of hashes and arrays. > And a lot of that seems to have been fixed, and that's great, but we somehow > ended up with a long list of strict, abstract data types. And there's > something about these new data types that just doesn't "feel" - to me, anyway > - like Puppet any more. > > And here's the thing: Puppet was already perceived to be a difficult > language, despite the fact that it was intended to be an easy one. So, I > don't get how it's in Puppet's interests to inflict abstract data types on > people who may not even have a computer science degree. Some have come from > shell, perl backgrounds, some may not have programming experience at all. This thread kind of tapered off, and there's stuff that I'm pretty sure I cannot address in a satisfactory way, but I did want to tuck into this point a bit. There's an interesting balance to strike because — as you note — the puppet language was intended to be simple. "It ought to look and feel more like a nagios config file than a scripting language", I recall Luke saying, early on. But as time has passed, users have demanded it fulfill more and more complex tasks, like setting up OpenStack, one of the most hellaciously complex distributed systems ever invented by humans. (I kid, I kid, just a bit) And using a tool whose sophistication is mismatched to the task leads to hacky awfulness; you're going to do what you must, but it won't be pretty. The type system and iteration syntax are a response to that situation, in the same way that parameterized classes were a response to the dearth of reusable Puppet code before 2.6; similarly I hope that in time, as style standards, best practice, and the syntax itself evolve, the new stuff will come to feel as Puppet-y as class parameters do today. Aside from the few syntactic changes that the type system imposes on existing code, like forcing quoting of numeric file modes, all of the new stuff is completely opt-in. So I'd (gently) dispute the assertion that they're inflicted on everyone as an early barrier to using puppet — a new user could go a long way downloading forge modules, composing configuration with hiera and/or roles+profiles, writing their own modules and classes, and generally being successful with the product, without needing to understand Variants, Enums, and the rest. Conversely, the existence of those things makes it easier for module authors to represent concrete API promises, so previously impossible things become easy, like a GUI that accurately represents a Boolean class parameter as a true/false toggle rather than a text field. > I believe that in order to "encourage" open source Puppet users to buy Puppet > Enterprise, Puppet has deliberately made Puppet difficult. And I'm sure the > problem is somewhat recognised internally, and Puppet 4 did seem to go some > way to make Puppet easier. This is plainly untrue. Even setting aside Hanlon's Razor and assuming the most Machiavellian profit motive, it would be folly to adopt such a strategy. Most of our customers come to Puppet Enterprise after some experience with open source, so relying on commercial differentiation that turns them away at the door would be suicidal. Now, we *are* painfully aware that the overall experience of starting out with Puppet is harder, not only than other competing solutions, but than Puppet itself used to be. Any spiky edges that cause users frustration between "hey I think I need some config management in my life" and "look there's Puppet doing just what I needed" need to get ground down into a smooth frictionless polish, and that goes equally for people who encounter Puppet via open-source or PE. All this is to say, it's highly likely that the current state of the language is not going to be its final state. Some things are certain to be wrong and need to iterate to improve. Puppet's reach is so much broader than it was five years ago, the ripple effects of changes that improve the experience for one set of users might actually make things worse for another set, but we just can't know until we get out in the world and see what happens. It's a tough landscape to navigate and I value guidance like this immensely. Eric Sorenson - eric.soren...@puppet.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- 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/5FA8BE6D-E1A6-400C-BEA3-9B6907CF65AC%40puppet.com. For more options, visit https://groups.google.com/d/optout.
