4 ms·

In this case functional ones come out as the obvious choice for declarative specs. The trick for adoption I imagine is designing a DSL in any LISP of one's cho

In this case functional ones come out as the obvious choice for declarative specs. The trick for adoption I imagine is designing a DSL in any LISP of one's choice that defines systems as s-expressions... and just turn it into its equivalent XML instead. Once the project inevitably becomes ubiquitous in enterprise IT you make a blogpost thanking everyone for being part of the social experiment but the DSL is back to being LISP again, with an optional pricing model per-processor a la SQL Server for those companies wishing to continue using XML instead of passing their specs through an automated converter. On an unrelated note, I'm looking for a cofounder with a FP background...

rad_gruchalski 10y ago
But that's the point. Why X? Maybe I don't like X. Maybe s-expressions, paredit and all that lisp stuff makes me upset. XML isn't a programming language either, we're going the DSL route again. Maybe I like, I don't know, cobol. What if I feel happy with my non-DSL DSL being cobol? Would people like it? Or maybe, really, the dedicated DSL is a better approach? To give people, at least, some handlebars, a lowest common denominator, if you wish. The point is, no matter what language is selected, someone is always going to be unhappy about the choice. Look at Chef, great technology, IMO. Gives all the power of Ruby. One can do totally whatever they want. Yet people were not happy with it. Alternatives came out, people started reinventing stuff all over again. But even with those, one can use whatever language they want to automate these tools even further. All these DSLs are just helpers, a starting point, make the initial adoption easy. I think people are looking at this aspect from a wrong perspective. "Is my time worth learning this new DSL / am I compensated enough to make it worth learning". It does not matter, as long as it all calculates.
otterley 10y ago
Sysadmins and SRE types typically work close to the metal, where C is the language of choice (i.e. how the kernel and libraries are generally programmed). We don't typically grok FP; we understand imperative programming. Python is close enough not to disorient us, but LISP and its derivatives are pretty far out there in left field.
jabl 10y ago
My idea for a saner more lispy ansible would be something like: 1) You define your configuration in (common lisp) s-expr's. 2) The configuration management system is a lisp program which reads the configuration defined in (1), generates bash code, uses ssh to contact the nodes to be configured and runs said bash code. That would retain one of the big advantages of ansible, namely you don't need to have some agent running on each node, and you can leverage ssh for security/cert handling etc. And you don't need a lisp environment installed on the nodes either.

rad_gruchalski 10y ago

But that's the point. Why X? Maybe I don't like X. Maybe s-expressions, paredit and all that lisp stuff makes me upset. XML isn't a programming language either, we're going the DSL route again. Maybe I like, I don't know, cobol. What if I feel happy with my non-DSL DSL being cobol? Would people like it? Or maybe, really, the dedicated DSL is a better approach? To give people, at least, some handlebars, a lowest common denominator, if you wish. The point is, no matter what language is selected, someone is always going to be unhappy about the choice. Look at Chef, great technology, IMO. Gives all the power of Ruby. One can do totally whatever they want. Yet people were not happy with it. Alternatives came out, people started reinventing stuff all over again. But even with those, one can use whatever language they want to automate these tools even further. All these DSLs are just helpers, a starting point, make the initial adoption easy. I think people are looking at this aspect from a wrong perspective. "Is my time worth learning this new DSL / am I compensated enough to make it worth learning". It does not matter, as long as it all calculates.

otterley 10y ago

Sysadmins and SRE types typically work close to the metal, where C is the language of choice (i.e. how the kernel and libraries are generally programmed). We don't typically grok FP; we understand imperative programming. Python is close enough not to disorient us, but LISP and its derivatives are pretty far out there in left field.

jabl 10y ago

My idea for a saner more lispy ansible would be something like: 1) You define your configuration in (common lisp) s-expr's. 2) The configuration management system is a lisp program which reads the configuration defined in (1), generates bash code, uses ssh to contact the nodes to be configured and runs said bash code. That would retain one of the big advantages of ansible, namely you don't need to have some agent running on each node, and you can leverage ssh for security/cert handling etc. And you don't need a lisp environment installed on the nodes either.