crustycoder

Heartening to see so many "This is an apple, that is an orange" comments. Spot on folks!

Yes, exactly. The issue detection step isn't particularly well-suited to a LLM, as it will tell you itself. The issues can be established deterministically by examining the Cloud resource data with a set of relatively simple rules, and Prolog is ideal for that. Where a LLM comes into the picture is analysis of the symptoms - resource relationships, ages, ownership, hypothesising root causes, generating cleanup plans, management reporting and so on. The interface between Prolog and the LLM is a JSON file containing the detected symptoms which is described to the LLM by a Skill. It all works pretty well.

It's not that sophisticated ;-) There's command editing using readline, result pagination using less and I output links to the reports and the Cloud console using ANSI HTTP link escapes. Primitive but sufficient.

I think in many real-life cases it's a mix - for example impure code that deals with the outside world to set up the data needed for the pure "core" of the app to run over.

I get what he's saying but I think it's overstated. I'd categorise his list as "Things to be careful with" not "Coding horrors". For example, "The primary means to make your programs defective in this way is to use predicates like assertz/1 and retract/1" is an unqualified statement that makes it sound like you should never ever use them, and that's not the case. I have a real-life Prolog app that applies rules to facts read from JSON data files. I could do that two ways:

1) Read the JSON with Prolog (there's a library) and assertz() the facts from that, building an immutable database in the first phase before applying the rules in the second phase.

2) Externally transform the JSON into Prolog facts, load that into the app on startup and apply the same rules to it.

I agree that mutating the database in the second phase is probably a bad idea, but that's not the same as saying "assertz() always bad". I'd read his site before it appeared on HN and whilst there a lot of very good stuff on it, some of it reminds me of FP purist edicts - fine if you want to go that way and it's appropriate to your problem, but that isn't always going to be the case. That was the basis of my earlier (downvoted) "Mostly overblown" comment.

But nice to see Prolog mentioned at all on HN :-)

Mostly overblown.

Name me a new bit of tech that hasn't been hyped beyond reasonable bounds. And yes, this is one of the worst examples. But saying it doesn't have its uses isn't reasonable either.

Go figure it out, it will be a useful challenge for you.

I'd tell you to read it again, but you seem to be struggling.

I'm not going to repeat myself, I've already explained the context to you - funny how you seem to have ignored that. If you want to find out, do the experiment yourself.

You clearly missed the "The truth is somewhere in between" bit.

Picking phrases from what I said and deliberately misquoting them out of context does not make you right.

"exactly this inspection" != "what does it exactly do"