4 ms·

Along a similar vain please stop writing external DSLs. Especially in the DevOps ecosystem. I'm really tired of learning yet another syntax for (bash + ssh).

thenewwazoo 10y ago
This is a hairier problem than you make it out to be. Eventually, you end up needing to describe the state of a system based on input values you may not be able to control. Arbitrarily complex dependency graphs add another layer of complication. Being able to construct simple data structures can suffice for almost all use cases, which is why YAML is so popular. Eventually, though, you end up needing to programmatically generate those trees of structures and oops now you're Turing-complete. If the goal is to decouple describing the state and executing the actions leading to convergence, there's no good solution to bridge the gap between the two, so you end up writing a DSL or creating an unholy marriage of a data description language and an imperative templating language (YAML+Jinja2), or just doing it all in BASH and giving up on the idea of clean separation.
- dkarapetyan 10y ago
  It's not hairy at all. All these "orchestration" things written in some weird YAML format end up doing the same thing. Re-inventing their own syntax for modules. Re-inventing their own querying language. Re-inventing idempotent building blocks and then forcing you to compose it all in some YAML format. I'm tired of these state of affairs. All of the above can be done in real programming languages, with real syntax. There is no need for yet another external DSL when an embedded DSL in the form of a library will suffice.
  - rad_gruchalski 10y ago
    But which programming language. Some like Python, some like Go, some like Ruby. Whatever one chooses, it will alienate large group of people who could otherwise use the product. It's not black and white.
    - mixedCase 10y ago
      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.
      - 10y ago
  - niftich 10y ago
    Well it's the same problem isn't it? Programming languages and their libraries come with their idiomatic conventions of API design, calling conventions, data structures, etc, which tend to translate awkwardly to a "foreign" programming language. The solution is usually one of two choices: pick a lowest-common-denominator programming language and implement everything in it such that all higher-level wrappers are only cosmetic shims; or, make a DSL that has clear and defined mapping to language-specific constructs and conventions in each programming language. The former is the coder's solution, the latter is the designer's solution.
  - rdtsc 10y ago
    But at the same time there is little chance say Puppet, Ansible, Salt, Chef would just write their newer/better system but will try to emulate some other existing language/DSL. For example do you see Chef taking off and becoming popular if it just implemented Puppet's language. Or would Salt have any appeal if it just had the Ruby syntax like Chef does? It just won't happen easily. One reason is because the API surface and the DSL is so varied that chances are there were significant design mistakes made in a previous version. And one of the reason people want the new shiny is that it fixes some of those fundamental design issues. Copying and emulating an existing thing, means sticking with broken fundamental design decisions. The irony is of course the new shiny also has it own fundamental design flaws and so now there will be a new group of people implementing the newer and shinier thing. (With obligatory articles on HN on "Why we switched from X to Y").
coldtea 10y ago
If you're tired, then just use bash + ssh. People use those "extenal DSLs" because they are tired of bash and ssh for the things the want to do.
- dkarapetyan 10y ago
  Or you know they could just write a library in a real programming language instead of forcing people to write YAML. Don't quite get the fascination with YAML. Give me actual fucking syntax instead of some bastardized serialization format that is badly trying to ape lisp.
  - camus2 10y ago
    the issue is as soon as you introduce a scripting language in a solution, people will write monstrosities with that. A configuration format guarantees that configuration will stay simple and "readable". I agree that LISP should be used more often though.
    - dkarapetyan 10y ago
      I have now seen enough deployments of puppet, salt, ansible, etc. to last me a lifetime and then some. Trust me. People have managed to turn configuration formats into unreadable monstrosities as well. At least with a real programming language I would have sensible debugging capabilities and maybe some refactoring tools to help but with a half-baked YAML programming language I have no such recourse.
- deleted 10y ago
  [deleted]

thenewwazoo 10y ago

This is a hairier problem than you make it out to be. Eventually, you end up needing to describe the state of a system based on input values you may not be able to control. Arbitrarily complex dependency graphs add another layer of complication. Being able to construct simple data structures can suffice for almost all use cases, which is why YAML is so popular. Eventually, though, you end up needing to programmatically generate those trees of structures and oops now you're Turing-complete. If the goal is to decouple describing the state and executing the actions leading to convergence, there's no good solution to bridge the gap between the two, so you end up writing a DSL or creating an unholy marriage of a data description language and an imperative templating language (YAML+Jinja2), or just doing it all in BASH and giving up on the idea of clean separation.

dkarapetyan 10y ago
It's not hairy at all. All these "orchestration" things written in some weird YAML format end up doing the same thing. Re-inventing their own syntax for modules. Re-inventing their own querying language. Re-inventing idempotent building blocks and then forcing you to compose it all in some YAML format. I'm tired of these state of affairs. All of the above can be done in real programming languages, with real syntax. There is no need for yet another external DSL when an embedded DSL in the form of a library will suffice.
- rad_gruchalski 10y ago
  But which programming language. Some like Python, some like Go, some like Ruby. Whatever one chooses, it will alienate large group of people who could otherwise use the product. It's not black and white.
  - mixedCase 10y ago
    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.
    - 10y ago
- niftich 10y ago
  Well it's the same problem isn't it? Programming languages and their libraries come with their idiomatic conventions of API design, calling conventions, data structures, etc, which tend to translate awkwardly to a "foreign" programming language. The solution is usually one of two choices: pick a lowest-common-denominator programming language and implement everything in it such that all higher-level wrappers are only cosmetic shims; or, make a DSL that has clear and defined mapping to language-specific constructs and conventions in each programming language. The former is the coder's solution, the latter is the designer's solution.
- rdtsc 10y ago
  But at the same time there is little chance say Puppet, Ansible, Salt, Chef would just write their newer/better system but will try to emulate some other existing language/DSL. For example do you see Chef taking off and becoming popular if it just implemented Puppet's language. Or would Salt have any appeal if it just had the Ruby syntax like Chef does? It just won't happen easily. One reason is because the API surface and the DSL is so varied that chances are there were significant design mistakes made in a previous version. And one of the reason people want the new shiny is that it fixes some of those fundamental design issues. Copying and emulating an existing thing, means sticking with broken fundamental design decisions. The irony is of course the new shiny also has it own fundamental design flaws and so now there will be a new group of people implementing the newer and shinier thing. (With obligatory articles on HN on "Why we switched from X to Y").

coldtea 10y ago

If you're tired, then just use bash + ssh. People use those "extenal DSLs" because they are tired of bash and ssh for the things the want to do.

dkarapetyan 10y ago
Or you know they could just write a library in a real programming language instead of forcing people to write YAML. Don't quite get the fascination with YAML. Give me actual fucking syntax instead of some bastardized serialization format that is badly trying to ape lisp.
- camus2 10y ago
  the issue is as soon as you introduce a scripting language in a solution, people will write monstrosities with that. A configuration format guarantees that configuration will stay simple and "readable". I agree that LISP should be used more often though.
  - dkarapetyan 10y ago
    I have now seen enough deployments of puppet, salt, ansible, etc. to last me a lifetime and then some. Trust me. People have managed to turn configuration formats into unreadable monstrosities as well. At least with a real programming language I would have sensible debugging capabilities and maybe some refactoring tools to help but with a half-baked YAML programming language I have no such recourse.
deleted 10y ago
[deleted]