6 ms·

This clearly is much more about Tower, consultancy, etc, than their main product, but their yaml encoded language is an abomination; masquerading as 'declarativ

by leg100 11y ago

This clearly is much more about Tower, consultancy, etc, than their main product, but their yaml encoded language is an abomination; masquerading as 'declarative' and easy to read, yet piling on loops and conditional statements and an unintuitive inheritance tree of global and local variables.

anton_gogolev 11y ago
Spot on. I'm constantly amazed at how many projects use _serialization formats_ as a "programming language". LiquiBase, NAnt, MSBuild, Ansible.
- raverbashing 11y ago
  Maven or pretty much anything XML based
  - reitanqild 11y ago
    In defense of maven it does provide neither branching nor looping statements so refering to it as a "programming language" is hard to justify.
    - collyw 11y ago
      Neither does HTML and the L stands for language.
      - detaro 11y ago
        "language" != "programming language"
      - executesorder66 11y ago
        Notice how the M stands for "Markup" and not "Programming"
  - roma1n 11y ago
    I haven't seen conditionals or loops widely used within Maven's XML.
- crdoconnor 11y ago
  It can work but it works best when the language is kept dumb. A dumb declarative language is easier to understand and easier to maintain. It can be used to help maintain a strict separation of concerns. The smarter you try to make the language, the worse it becomes. Ant & MSBuild AFAIK are basically full programming languages in their own right so there was really no point to them actually being their own language.
- TeMPOraL 11y ago
  That's people constantly reinventing Lisp, refusing to use the right tool for the job. Greenspun's Tenth Rule also comes to mind.
  - Jweb_Guru 11y ago
    Lisp is not and has never been the right tool for configuration management.
    - zeveb 11y ago
      > Lisp is not and has never been the right tool for configuration management. Why not? Configurations are collections of items, and among the things Lisp excels at is…lists of atoms. Take a look at https://github.com/ansible/ansible-examples/tree/master/lamp_simple https://github.com/ansible/ansible-examples/tree/master/lamp... (a simple LAMP stack implemented in Ansible). It uses a .ini-style file to manage lists of hosts, e.g.: [webservers] localhost [dbservers] bensible sensible Why not put that in a list? (hosts (webservers localhost) (dbservers bensible sensible)) The Ansible playbooks are YAML lists. There's no particular reason that: --- # This playbook deploys the whole application stack in this site - name: apply common configuration to all nodes hosts: all remote_user: root roles: - common … is more readable than: (playbook "This playbook deploys the whole application stack in this site" (play "apply common configuration to all nodes" (hosts all) (remote-user root) (roles common) …) or: (playbook '((all '(common) :user root :comment "apply common configuration to all nodes") …) :comment "This playbook deploys the whole application stack in this site") In fact, I'd argue that both Lispy representations are much more readable.
      - Jweb_Guru 11y ago
        Oh, I didn't mean to say that S-expressions can't be used for configuration. It's that in general you don't want a Turing-complete language to do configuration management, because you want to be able to reason about things like rollbacks, dependencies and diffs.
- gerbilly 11y ago
  It seems like parsing is becoming a lost art. Maybe because it can't be easily approached by the iterative development style that is in fashion these days.
  - ufo 11y ago
    The real lost art here is scripting languages. Even if you parse things yourself, configuration files still have a natural tendency to evolve into a crappy programming language over time. So instead of writing your own config file format you should just make a couple a quick bindings for a scripting language like Lua, Python or Ruby.
bbrazil 11y ago
Syntax and semantics are separate, not having to learn a new syntax is handy. Syntactically the problem I run into is that it's got it's own DSL in task definitions, so it can be hard to keep in mind what's YAML and what's the DSL. Semantically loops and conditions are essential features so I don't have a problem with that. The inheritance could use some clarification, I was hit last year by a regression that remains unresolved.
bryanlarsen 11y ago
You missed the quoting mess, adding their own compact list and map grammar, the convention of having a comment on every line, and there's more I can't think of right now. I hate ansible, it's just better than any of the alternatives for different reasons. Luckily we're moving away from needing any of them. Scripting an image build is a lot easier than updating a machine using CI: you start from a blank slate every time, and an out of date script isn't the catastrophe it is with CI since you have the images saved.
dorfsmay 11y ago
I think when ansible started it wasn't obvious that logic (loops, conditional etc...) would be needed eventually. By the time it became obvious it was going to be required, it was too late to change. Using jinja2 for markup compounded the issue in my opinion, as it has no loops and logic is less than obvious (compared to mako for example). Still I find its agentless model, the idempotent model, being able to use it on machines where you don't have root access etc... gives it a place that nobody had fulfilled.
- SEJeff 11y ago
  """ Using jinja2 for markup compounded the issue in my opinion, as it has no loops and logic is less than obvious """ This comment makes pretty much no sense at all. Example of a loop in jinja2: {% for item in ("one", "two", "three") %} item is {{ item }} {% endfor %} The logic is pure python minus perhaps setting variables ie: {% set name = "dorfsmay" %} {% if name == "dorfsmay" or name.startswith("dorfs") %} You're spreading FUD about jinja2 {% endif %}
  - justingood 11y ago
    I'd agree that jinja2 has a perfectly fine way of handling loops, but the problem is that functionality only works in Ansible template files. The Ansible playbook can only make use jinja2 filters to act on variables: https://docs.ansible.com/ansible/playbooks_filters.html https://docs.ansible.com/ansible/playbooks_filters.html
    - SEJeff 11y ago
      Oh no disagreement there. I was just disagreeing with the GPs disparagement of jinja2, which is a limitation of how Ansible was implemented and has absolutely nothing to do with jinja2. Ansible is great stuff, but some of those decisions were quite weird.
      - d23 11y ago
        Jinja is great as a templating language. I find yaml by itself to be clean and readable. Cram all of it in to the same soup, mix in the global variables, and it quickly turns into a nightmare. It takes what's already a problem in a dynamically typed language and amplifies it.

by leg100 11y ago

anton_gogolev 11y ago

Spot on. I'm constantly amazed at how many projects use _serialization formats_ as a "programming language". LiquiBase, NAnt, MSBuild, Ansible.

raverbashing 11y ago
Maven or pretty much anything XML based
- reitanqild 11y ago
  In defense of maven it does provide neither branching nor looping statements so refering to it as a "programming language" is hard to justify.
  - collyw 11y ago
    Neither does HTML and the L stands for language.
    - detaro 11y ago
      "language" != "programming language"
    - executesorder66 11y ago
      Notice how the M stands for "Markup" and not "Programming"
- roma1n 11y ago
  I haven't seen conditionals or loops widely used within Maven's XML.
crdoconnor 11y ago
It can work but it works best when the language is kept dumb. A dumb declarative language is easier to understand and easier to maintain. It can be used to help maintain a strict separation of concerns. The smarter you try to make the language, the worse it becomes. Ant & MSBuild AFAIK are basically full programming languages in their own right so there was really no point to them actually being their own language.
TeMPOraL 11y ago
That's people constantly reinventing Lisp, refusing to use the right tool for the job. Greenspun's Tenth Rule also comes to mind.
- Jweb_Guru 11y ago
  Lisp is not and has never been the right tool for configuration management.
  - zeveb 11y ago
    > Lisp is not and has never been the right tool for configuration management. Why not? Configurations are collections of items, and among the things Lisp excels at is…lists of atoms. Take a look at https://github.com/ansible/ansible-examples/tree/master/lamp_simple https://github.com/ansible/ansible-examples/tree/master/lamp... (a simple LAMP stack implemented in Ansible). It uses a .ini-style file to manage lists of hosts, e.g.: [webservers] localhost [dbservers] bensible sensible Why not put that in a list? (hosts (webservers localhost) (dbservers bensible sensible)) The Ansible playbooks are YAML lists. There's no particular reason that: --- # This playbook deploys the whole application stack in this site - name: apply common configuration to all nodes hosts: all remote_user: root roles: - common … is more readable than: (playbook "This playbook deploys the whole application stack in this site" (play "apply common configuration to all nodes" (hosts all) (remote-user root) (roles common) …) or: (playbook '((all '(common) :user root :comment "apply common configuration to all nodes") …) :comment "This playbook deploys the whole application stack in this site") In fact, I'd argue that both Lispy representations are much more readable.
    - Jweb_Guru 11y ago
      Oh, I didn't mean to say that S-expressions can't be used for configuration. It's that in general you don't want a Turing-complete language to do configuration management, because you want to be able to reason about things like rollbacks, dependencies and diffs.
gerbilly 11y ago
It seems like parsing is becoming a lost art. Maybe because it can't be easily approached by the iterative development style that is in fashion these days.
- ufo 11y ago
  The real lost art here is scripting languages. Even if you parse things yourself, configuration files still have a natural tendency to evolve into a crappy programming language over time. So instead of writing your own config file format you should just make a couple a quick bindings for a scripting language like Lua, Python or Ruby.

bbrazil 11y ago

Syntax and semantics are separate, not having to learn a new syntax is handy. Syntactically the problem I run into is that it's got it's own DSL in task definitions, so it can be hard to keep in mind what's YAML and what's the DSL. Semantically loops and conditions are essential features so I don't have a problem with that. The inheritance could use some clarification, I was hit last year by a regression that remains unresolved.

bryanlarsen 11y ago

You missed the quoting mess, adding their own compact list and map grammar, the convention of having a comment on every line, and there's more I can't think of right now. I hate ansible, it's just better than any of the alternatives for different reasons. Luckily we're moving away from needing any of them. Scripting an image build is a lot easier than updating a machine using CI: you start from a blank slate every time, and an out of date script isn't the catastrophe it is with CI since you have the images saved.

dorfsmay 11y ago

I think when ansible started it wasn't obvious that logic (loops, conditional etc...) would be needed eventually. By the time it became obvious it was going to be required, it was too late to change. Using jinja2 for markup compounded the issue in my opinion, as it has no loops and logic is less than obvious (compared to mako for example). Still I find its agentless model, the idempotent model, being able to use it on machines where you don't have root access etc... gives it a place that nobody had fulfilled.

SEJeff 11y ago
""" Using jinja2 for markup compounded the issue in my opinion, as it has no loops and logic is less than obvious """ This comment makes pretty much no sense at all. Example of a loop in jinja2: {% for item in ("one", "two", "three") %} item is {{ item }} {% endfor %} The logic is pure python minus perhaps setting variables ie: {% set name = "dorfsmay" %} {% if name == "dorfsmay" or name.startswith("dorfs") %} You're spreading FUD about jinja2 {% endif %}
- justingood 11y ago
  I'd agree that jinja2 has a perfectly fine way of handling loops, but the problem is that functionality only works in Ansible template files. The Ansible playbook can only make use jinja2 filters to act on variables: https://docs.ansible.com/ansible/playbooks_filters.html https://docs.ansible.com/ansible/playbooks_filters.html
  - SEJeff 11y ago
    Oh no disagreement there. I was just disagreeing with the GPs disparagement of jinja2, which is a limitation of how Ansible was implemented and has absolutely nothing to do with jinja2. Ansible is great stuff, but some of those decisions were quite weird.
    - d23 11y ago
      Jinja is great as a templating language. I find yaml by itself to be clean and readable. Cram all of it in to the same soup, mix in the global variables, and it quickly turns into a nightmare. It takes what's already a problem in a dynamically typed language and amplifies it.