Fantastic response, Eric, couldn't have (and obviously didn't) said it better myself.
> On Apr 28, 2016, at 8:00 PM, Eric Sorenson <[email protected]> wrote: > > >> On Apr 11, 2016, at 9:17 AM, Alex Harvey <[email protected]> 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 - [email protected] - 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 [email protected]. > 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. -- 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/26B2A322-CFD1-4E97-94B6-35A614C92EA8%40puppet.com. For more options, visit https://groups.google.com/d/optout.
