44 comments

[ 4.5 ms ] story [ 148 ms ] thread
Not everything that can be represented with s-expressions is a lisp. For example:

  (html
    (body
      (h1 "Hello, World!")))
This does not mean that HTML is a lisp.
Also, more than Lisp, clips would be a really good choice there. Defining constraints to configure a system? That's basically what literally Clips does.

https://www.clipsrules.net/

OK, but what about the homoiconicity and syntax macros?
I don't know Ansible well enough to say for sure, but the macro example seems like more of a C preprocessor style "macro." I don't see how it's doing anything more than filling in a template.
It's executed at runtime, not before some compilation stage.
"What is homoiconicity then? Typical definitions state that it is simply “code as data”, will point to a relationship between a program’s structure and syntax or note that the program source is expressed in a primitive data-type of the language. In the below, we will show that none of these definitions make much sense."

https://www.expressionsofchange.org/dont-say-homoiconic/

In this context it seems to refer to programming in a language where the developer facing code is represented in terms of data structure literals within the language. It's a reasonable understanding of what is usually meant in a Lisp-like setting. The code is a list, so you can trivially construct and deconstruct executable lists, just like you can trivially construct data carrying lists.

One could make clever quips that this isn't enough, you need quote/unquote as well to make it practical, and is that really implied by homoiconicity? Should we really use this word? Maybe we should pay someone to make up a new one?

You'd think this would be more understood given that pretty much the whole point of lisp is to be pretty close to just representing an AST without relatively few frills. The idea that we can represent most languages with a tree-like structure isn't particularly novel.
But that can be perfectly valid Lisp. Lisp libraries producing HTML often look just like that.
Not all of HTML can be represented with s-expressions. The following is perfectly valid.

    <b>Hello <i>World!</b> Greetings</i> Earthlings!
I never noticed that, though "doesn't require a closing tag" and "requires that there is no closing tag" ought to have been hints for me.
And yet it's semantically identical to

  <b>Hello <i>World!</></b><i> Greetings</i> Earthlings!
You can see this by looking at the innerHTML, which is really just a serialized form of the DOM tree.
Is it actually valid? W3C's HTML validator complains about invalid nesting.

It might work because the HTML5 parsing algorithm produces well-defined results for broken HTML, but I'm not sure that's the same as "perfectly valid" – the spec calls such markup "misnested" and "erroneous" [0].

[0] https://html.spec.whatwg.org/#an-introduction-to-error-handl...

It certainly was valid according to the original specs. I first saw it as an example over 20 years ago in a debate about whether XHTML should replace HTML 4.0.
This is quite a stretch to call Ansible, which consists of YAML files with syntactic sugar and some light Python evaluation, 'Lisp'.

I thought reading the article would make less inflammatory but it didn't.

Yeah I agree, Ansible would be so much better if it was Lisp-first with a perfectly non-scary I'm-a-devops YAML syntax instead of OMG-parens-nobody-understands-Lisp Lisp syntax.
I'm guessing you'd probably break the declarativeness if you exposed the full power of LISP, but limited subsets in YAML work pretty well.

I especially like how well suited it is to visual block based editing.

Blockly and Node Red let you put stuff anywhere in 2D space, a satisfying auto formatter isn't really possible, and traditional flow charts can easily get big and messy.

But if you look at DRAKON, their charts pretty much always look nice. And looking at ladder logic, It's almost but not quite a set of 1D flow charts.

If you strip it down more, events that trigger a list of commands until a command returns False is a really simple model without much learning time, and it's very easy to create a visual editor

Giving people the full power of LISP would probably result in people writing imperative programs rather than building up an ecosystem of declarative plugins though.

And it seems that the consensus is it doesn't become a LISP just because you can implement it in nested lists....

It’s a homoiconic language like Lisp, just with YAML instead of s-expressions.
that's beyond a real stretch - is XSLT a LISP then? simply using YAML (or json or any equivalent data/markup syntax as the basis for a DSL syntax does not make it homoiconic.

in this case, the very rigid structure of playbooks and tasks, etc. within YAML is also part of the syntax. just the fact that you can generate arbitrary YAML (or json or etc.) from within a copy utility does not come close to homoiconicity of a LISP. can you effortlessly move back/forth from data to code? is everything both code and data at the same time? what's the Ansible equivalent to quasi-quote, for instance? is a bash script that sources (or creates or evals) a list of variable assignments in bash syntax homoiconic? due to eval, bash would seem a hell of a lot closer.

and those really aren't "syntactic macros" either, unless you'd be happy to define an MS-DOS .bat file that generates and calls a .bat file fragment "syntactic macros". it's using an external file ffs.

Ansible is good for what it does, but it has an extremely limited and rigid "flow-control" (if we can even call it that) and is more of a declarative language/config file than a general language.

this represents a pretty naive superficial understanding of these LISP features.

points for making us think though.

Either the author doesn't know what Lisp means (the "essence" of Lisp), or just wants to stretch YAML to mean Lisp.
See also https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Yes, that’s what I think off when I see ansible, not that it actually is a lisp. It’s a poor hack for something you can trivially do with lisp since forever. Like most of these things and indeed Greenspuns rule says we will find that; you need the solution for something complicated so you start building something simple, add more features and end up with something you should’ve done in lisp from the start. And of course now you miss most (all) of the benefits.
Blame the poor computer science education of most people nowadays (could be self-taught or university).

Discovering that code is data and data is code is discovering the moon. And inferring that your sad configuration management system based on an ugly data language is kind of related to Lisp must be mind blowing. Also bonus fact, XML is a lisp too !

Actually maybe we could have written ansible in lisp directly to save us the trouble.

This quote has always seemed very strange to me. I feel like the implicit argument (that just using lisp instead of making a program that has more limited semantics that conform directly to the intended purpose) is not a great one. Obviously informally-specified, bug-ridden, and slow are not good things, but I'd argue those are also not specific to Fortran or C but just to any "sufficiently complicated program". People make a big deal about the Church-Turing thesis, but I think it gets taken too far sometimes because the important part of a programming language isn't always what's possible to do in the language but what _isn't_, and I'd argue most of the large improvements in languages over time are about that; not having undefined behavior, null-pointer errors, and runtime type errors are all huge improvements in programming productivity that only exist because we made languages that don't allow you to do certain things.

At the end of the day, quite a lot of the work in programming boils down to ensuring that what you wrote does _exactly_ what you intend rather than behaving in some other way, and that means identifying and eliminating places where it diverges. There are a lot of common patterns for places where these issues occur, and a language that can identify those patterns and make it impossible for you to write a program that has those mistakes is saving you time up front.

Which are the dramatic examples of lead devs looking at a system, decided half baked configs/guis will start falling apart in a few years, so they moved to a powerful programming language? Blender and Maya getting Python scripting may be one.
Yet another catchphrase made by someone who lived through Lisp's heyday. There is not much "magic" in Common Lisp, aside from homoiconicity; it is dated old language, which reeks the smell of 1970s and 1980s in every corner of it. Yes it still fun to play with even today, but it is not some magic unicorn everything evolves into eventually.
I agree that common lisp has "avocado tile in the kitchen" vibes.

But Clojure is all stainless steel and engineered stone.

So maybe if philg updated his aphorism to mention Clojure it would still fly.

Bash feels more like a C buffer overflow vulnerability than a Lisp: When you're not careful your data tends to leak across its boundaries and get mixed up with your code.

Is there a way to quote data in Bash to safely insert it into a piece of code, the way you can in Lisp?

In Bash, yes. Or, almost.

The printf built-in command has a %q conversion specifier which quotes the argument such that the result can be used as input into the shell.

Such a thing cannot be inserted into a quote without affecting its meaning, but what you can do is terminate the quote before and after it.

  'stuff before'$(printf "%q" "$value")'stuff after'
In this case, because it's a single quote, we need to terminate it anyway, order to activate the command substitution syntax.
> YAML as executable code

Why must we do these things to ourselves?

I don't think my aversion is actually YAML. I have been playing around a lot with Benthos lately, and it is actually quite pleasant.
YAML is one of the best configs languages imo. Using it as executable code? MEH
I thought this was going to be a python thing that exploited functions returning functions with their lexical scope. I find too many syntactical macros tends to encourage excessively dense code. Tho I usually use packer and terraform to configure my end VMs not ansible. A PR to either packer repo or territory repo and push the button to recreate the resources.
Actually, ansible is a prolog. I played around with marelle[1] a bit for managing my Mac configuration and I realized that the core of the typical configuration management tool just is a prolog: it gathers facts from the systems you have, compares them with a desired state you’ve specified declaratively and executes a plan to get from the current state to the specified one. Prolog does the planning more or less “for free” because of its evaluation model.

[1]: https://github.com/larsyencken/marelle

Ansible is great, but using YAML still bugs me. Would just be a lot easier with HCL (Hashicorp) or something else.
At my first job, we had a perl script to transform json into a yaml inventory file (it then allowed us to serve a form to clients that would act as a yaml, but i left a bit before the feature was implemented). We still had to write our module in yaml though.

Still, the greybeard who come up with the initial design and architecture was the best dev i've ever worked with, to this day. I wasn't ready to learn as much as i ought to do, sadly.

Those are 2 lisp tools not unlike Ansible:

* [Consfigurator](https://spwhitton.name/tech/code/consfigurator/) - Lisp declarative configuration management system. You can use it to configure hosts as root, deploy services as unprivileged users, build and deploy containers, and produce disc images. [GPL3][2].

* [cl-unix-cybernetics](https://github.com/cl-unix-cybernetics/cl-unix-cybernetics) (previously Adams) - UNIX system administration in Common Lisp. Not unlike Ansible, Chef or Puppet. [ISC][22]. - You describe your systems (hosts) using resources having properties. The properties are then probed and synchronized using only /bin/sh on the remote host, and /usr/bin/ssh on the control host.

(awesome-cl)