> Configuration management was a new field and major competitors at the time were (and still are) Puppet and Chef.
No, it was a field dozen years old already. And major competitor was (is) also
CFEngine, though they suck heavily at marketing, so they're usually omitted by
operationally undertrained people.
> Ruby is a beautiful language. [...] The Puppet language on the other hand is gross.
If we talk about persoanl opinions, I call it the reverse. Puppet is OK and
Ruby is atrocious.
> It almost seems as if [Puppet language] was deliberately designed to be removed from its Ruby roots.
So first you believe declarative tool fits better than imperative (stated
earlier in the rant), but now you complain that Puppet moved in different
direction than Ruby? Make your mind already.
> [...] calling Puppet functional is a major insult to most other functional languages out there.
Calling Puppet's language functional is a major insult to caller's knowledge
about programming languages. It's declarative, and it's not even
a programming language, it was not meant to be Turing-complete.
> Building a functional language without builtin support for closures and adequate syntactic- or library-provided functional primitives like map, reduce, filter, etc is just plain bad.
What made you think it's a programming language? It's not.
---
The rest of the rant is a list of actually valid problems. From what I know,
most of these don't occur in CFEngine, which also uses simpler architecture in
typical deployment (agents are more autonomous, not tied as much to their
master as in non-masterless Puppet).
valid point, what i meant was that it was new field to me. fixed it, thanks.
> first you believe declarative tool fits better than imperative ... but now you complain that Puppet moved in different direction than Ruby? Make your mind already
where do i even begin.. a) i was talking about functional/declarative approach, not tool; b) ruby is much more mature, coherent and pleasant language to work with - working hard to move in opposite direction is what i'm complaining about; c) while being very much imerative/oo, ruby still beats puppet in being functional and declarative.
> Calling Puppet's language functional is a major insult to caller's knowledge about programming languages. It's declarative, and it's not even a programming language, it was not meant to be Turing-complete.
what it was or wasn't meant to be i'll leave for your imagination, i'm concerned with what it is in practice. name me one feature of declarative puppet language that definitively rules out possibility to classify it as functional language?
> What made you think it's a programming language? It's not
i could go this way: have i used the word "programming" even once? but this is probably more efficient way to settle the issue:
> The Puppet language is more declarative/functional in its style than imperative/object-oriented, and is more likely to evolve in the functional direction instead of becoming more imperative and operating on mutable objects. - Henrik L
> name me one feature of declarative puppet language that definitively rules out possibility to classify it as functional language?
Out of order operations? IIRC puppet is free to reorder operations, and thus you need to explicitly declare any dependencies between operations, and the runtime has a solver to decide what order is appropriate.
But it's kind of a silly dichtomy. Your article screams "I wish I had used Chef." It's technically a functional language, but looks very declarative:
acme_certificate site do
crt "/etc/apache2/ssl/#{site}.crt"
key "/etc/apache2/ssl/#{site}.key"
chain "/etc/apache2/ssl/#{site}.pem"
wwwroot '/var/www/website'
end
There's two general options for creating a DSL: define a formal grammar (Puppet) or extend an existing one to needs (ruby+chef). The latter gives you easy access to a community of existing developers, but ties you heavily to the language and runtime you extended. A formal grammar is more work to create, and more work to learn, but allows for multiple implemenations in languages and runtimes other than Ruby.
When you're courting the likes of Apple, Google, and Facebook, suddenly the scalability of the solution matters. Chef Server is in Erlang, which is neat, but chef-client will basically always be a slow ruby app.
No, it was a field dozen years old already. And major competitor was (is) also CFEngine, though they suck heavily at marketing, so they're usually omitted by operationally undertrained people.
> Ruby is a beautiful language. [...] The Puppet language on the other hand is gross.
If we talk about persoanl opinions, I call it the reverse. Puppet is OK and Ruby is atrocious.
> It almost seems as if [Puppet language] was deliberately designed to be removed from its Ruby roots.
So first you believe declarative tool fits better than imperative (stated earlier in the rant), but now you complain that Puppet moved in different direction than Ruby? Make your mind already.
> [...] calling Puppet functional is a major insult to most other functional languages out there.
Calling Puppet's language functional is a major insult to caller's knowledge about programming languages. It's declarative, and it's not even a programming language, it was not meant to be Turing-complete.
> Building a functional language without builtin support for closures and adequate syntactic- or library-provided functional primitives like map, reduce, filter, etc is just plain bad.
What made you think it's a programming language? It's not.
---
The rest of the rant is a list of actually valid problems. From what I know, most of these don't occur in CFEngine, which also uses simpler architecture in typical deployment (agents are more autonomous, not tied as much to their master as in non-masterless Puppet).