4 ms·

> No, it was a field dozen years old already valid point, what i meant was that it was new field to me. fixed it, thanks. > first you believe declarative tool

> No, it was a field dozen years old already 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

jldugger 9y ago
> 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.

jldugger 9y ago

> 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.