[rauhl]

> My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years.

I think that you’re right, and I think it’s great, because we have a programming model in which code is data and data is code: Lisp & S-expressions.

It’d be downright awesome to have a Lisp-based system which used dynamic scoping to meld geographical & environmental (e.g. production/development) configuration items. But then, it’d be downright awesome if the world had seriously picked up Lisp in the 80s & 90s, and had spent the last twenty years innovating, rather than reïnventing the wheel, only this time square-shaped. But then, the same thing could be said about Plan 9 …

I’ve not yet had the time to take a look at Pulumi, but I hope to have time soon.

[ajross]

> I think that you’re right, and I think it’s great, because we have a programming model in which code is data and data is code: Lisp & S-expressions.

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

http://wiki.c2.com/?GreenspunsTenthRuleOfProgramming

Seriously, this has happened again and again and again. You have software, so you configure it via a clean and simple text syntax, then the configuration needs to be generated and the syntax becomes more complicated, then the next system you do has an "API" instead so you can configure it via programming, which is too complicated so the next time you Do it Right and go with a simple text file, which is then outgrown when the configuration it stores becomes too complicated...

It's like a circle of life thing.

[aaaaaaaaaaab]

And people are vehemently agreeing/disagreeing depending on their phase shift in the Turing complete vs declarative carousel.

Compare with: strongly vs weakly typed languages

[marcosdumay]

That saying was very true of Fortran, reasonably true of C, and mostly don't happen on newer languages.

[mschaef]

I think the parts of Lisp that tended to be rebuilt have mostly been incorporated into the newer languages. (At least, it's been a very long time since I've had to rewrite a fundamental data structure, etc.)

[erikpukinskis]

You don’t need code-is-data for what your parent is describing. All you need is code that outputs data. Or even better, code that initiates contact with other code.

The only requirement is a commitment to doing things imperatively in a real programming language. It’s hard to resist the temptation to do things declaratively (because it’s easier to imagine a declarative interface that describes your problem than an abstraction of the procedure which will solve it) but you are never forced to.

[pjc50]

As the kids say: stop trying to make Lisp happen, it's not going to happen.

It has become yet another community that's fighting a struggle that everyone else ended years ago, like the few Japanese in jungles who refused to surrender. I'm not entirely sure why it's not been adopted, but I suspect it's because most people strongly prefer (a) visually semantically different scope delimiters and (b) function-outside-brackets syntax ie f(a, b) rather than (f a b).

Or you could go the other way and say that JSON is s-exps with curly brackets so it should be made executable as such, and build that language.

[eadmund]

> As the kids say: stop trying to make Lisp happen, it's not going to happen.

That's probably true, but I think it's useful to fight the good fight regardless. Even if Lisp & s-expressions don't, in fact, take over the world (and I think they will), arguing in their favour might help increase the chance that whatever inferior technology does end up getting adopted is better than it could have been.

> Or you could go the other way and say that JSON is s-exps with curly brackets so it should be made executable as such, and build that language.

The problem is that without symbols, that ends up being hideously ugly. This:

    ["if",
     ["<", 1, 2],
     "less than",
     "greater than or equal to"
    ]

is appreciably worse than:

    (if (< 1 2)
        "less than"
        "greater than or equal too")

And alternatives like:

    {"if": [[1, "<", 2], "less than", "greater than or equal to"]}

are so much worse that I don't think anyone could seriously expect to use them.

[mschaef]

> It has become yet another community that's fighting a struggle that everyone else ended years ago, ... like the few Japanese in jungles who refused to surrender.

Nice imagery, but the wrong point.

Except for the syntax, everybody else joined Lisp.

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." --Guy Steele

Flash back to the mid-1980's (when the mainstream was C, Pascal, BASIC, FORTRAN, COBOL, etc.) and it's Lisp/Scheme (and Smalltalk) that have features like Garbage Collection, interactive development, lexical closures, decent built-in data structures, dynamic typing.

The fact that all of this is commonplace today, both justifies a lot what Lisp did in the first half of its existence and undermines its (technical) competitive advantages now.

> but I suspect it's because most people strongly prefer (a) visually semantically different scope delimiters and (b) function-outside-brackets syntax ie f(a, b) rather than (f a b).

It's not technical. I don't think it ever was. So much of it is around social concerns: a performance stigma dating back to the 1970's, fear of being able to hire people to do the work, fear of what VC's will think, worries that the language will still be available... And then at the end of the day, the problems whatever language will solve are a tiny fraction of the overall problem of doing something relevant and lasting and useful to others.

> As the kids say: stop trying to make Lisp happen, it's not going to happen.

Life is too short and the world is too big to try to confine other people's ideas of how they should think or work.

The point of the market economy and of the scientific process is that people get to try what they think is going to be useful and then let the world decide. The fact that Lisp is still in the conversation at all, when its contemporaries (Autocoder, Fortran) either aren't or are highly specialized, says a lot that we can learn from.

[kkarakk]

>As the kids say: stop trying to make Lisp happen, it's not going to happen.

Mean girls came out in 2004, no kid knows that movie

[lenkite]

Oh my! So web-assembly is not 'happening' then ? May it REST in peace.