Unplanned Obsolescence

Thank you a lot for your interest! Yes of course: As I see it, Prolog is often awesome in types of applications that are distinct from those one would usually build in other kinds of languages.

Alex Petros phrased it extremely nicely and insightfully in his comment at https://lobste.rs/s/0cvxwk/prolog_basics_explained_with_pokemon#c_qq87n1:

"I don't know if this will be a satisfying answer to your question, but since writing this blog post I find myself reaching for Prolog in cases that are entirely orthogonal to any kind of code I used to write before. There are definitely people in the Prolog community who like using it for web servers or whatnot, but for me personally it's more about unlocking a different skill tree. For instance, I've become better at identifying where custom parsers or DSLs might be a good fit for a problem."

The mentioned blog post by Alex is available from: https://unplannedobsolescence.com/blog/prolog-basics-pokemon/ and was recently discussed here: https://news.ycombinator.com/item?id=48147091

For another example, please see factgraph.pl also by Alex: https://github.com/alexpetros/factgraph.pl

Prolog is great in applications that must be able to analyze, extend, adapt, reason about and give account of their own workings and results. As an example for this, please see An Executable Specification of Oncology Dose-Escalation Protocols with Prolog by David C. Norris and me: https://arxiv.org/abs/2402.08334

In this example and others like it, one…

As you can see even the basic documentation is compromised at this point:

https://unplannedobsolescence.com/blog/behavior-belongs-in-html/

<button onclick="alert('I was clicked!')">Click me</button>

,,You can find HTML attribute equivalents for many of the event handler properties; however, you shouldn't use these — they are considered bad practice. It might seem easy to use an event handler attribute if you are doing something really quick, but they quickly become unmanageable and inefficient.''

,,You should never use the HTML event handler attributes — those are outdated, and using them is bad practice.''

And then proceeds to suggest this:

<button>Click me</button>

<script> const btn = document.querySelector("button")

btn.addEventListener("click", () => { alert('I was clicked!') }) </script>

After this, next step would be putting javascript to a separate file, and on a slow mobile connection in a random airport with thousands of people using the same wifi, a simple working code gets timeouts.

20 years ago all I needed to know was this, and it worked great:

<button onclick="alert('I was clicked!')">Click me</button>

> “You didn’t solve anything! Doing validation is complex and you just magic wanded it away by designing a perfect interface for it.” Yes. Exactly. That is what interfaces are supposed to do. Better semantics make it possible for the programmer to describe what the element does, and for someone else to take care of the details for them.

Gosh I couldn't agree more, what a wonderfully succinct way to communicate what I spend a ridiculous amount of time trying to explain to my colleagues when designing programs!

[EDIT]: I just realized I had read this on one of the linked articles https://unplannedobsolescence.com/blog/behavior-belongs-in-html/

In many cases, browsers will also automatically perform a "smooth" transition between pages if your caching settings are don well, as described above. It's called paint holding. [0]

One of the driving ideas behind Triptych is that, while HTML is insufficient in a couple key ways, it's a way better foundation for your website than JavaScript, and it gets better without any effort from you all the time. In the long run, that really matters. [1]

[0] https://developer.chrome.com/blog/paint-holding [1] https://unplannedobsolescence.com/blog/hard-page-load/