Michael Covington is a computational linguist and amateur astronomer who writes on clear writing, astrophotography, and computing.
HN commenters recommend his guide to writing and thinking clearly, and note his astrophotography guide suits beginners; he also has detailed books.
Well, with respect to Markus Triska, I don't like purity. Prolog gives you plenty of "impure" constructs like the cut (!/0) and the assert/retract family of database manipulation predicates. It also gives you impure I/O and arithmetic functions that are quite separate from the otherwise logical, declarative-ish style of the language.
I'm fine with all that. The language gives you sensible tools to deal with edge cases that otherwise require you to jump through hoops or import libraries (like the constraint arithmetic libraries that Markus recommends... and that he had to mostly write himself before he could recommend). You can get into a spot of bother if you use those facilities without knowing why they are there and why you shouldn't just spam them in every case, but that's why good textbooks exist.
And more to the point, that's why Prolog Coding Guidelines are a thing, more precisely, a paper, which you can find here from the website of Michael Covington who's one of its (many) authors:
https://www.covingtoninnovations.com/mc/plcoding.pdf
Here's what the Guidelines has to say about assert/retract:
5.10 Avoid asserta/assertz and retract unless you actually need to preserve
information through backtracking
Although it depends on your compiler, asserta/assertz and retract are usually
very slow. Their purpose is to store information that must survive backtracking. If
you are merely passing intermediate results from one step of computation to the
next, use arguments.
If…
If you're into any electronics tinkering at all, a good way to get up to speed with assembly is to take a look at some microcontrollers, such as PIC and make some simple hardware projects happen. There are tons of project blueprints out there along with code. The beauty of it is that you can account for pretty much every peripheral on the device with your eyeball. There are many versions of microcontrollers, but a grandfather one with RISC assembly is the venerable PIC16F84A. It has 1 kb of program memory, 68 bytes of ram, and 64 bytes of 'eeprom' ram. That last part is like hard drive storage you can store settings in, or temperatures, or whatever.
The great thing is that you can download the IDE for the chips, write a program, and simulate its running for free. The debugger will light up pins as needed and let you simulate input. But, back to the understanding part: today's CPUs are very complicated and have tons of parts. The microcontroller is a very simplified version of it, and even so it's complicated.
Imagine a microchip in your hand with 18 pins on it. 2 of the pins are power supply (+5 v and ground), another 2 are supposed to be attached to a crystal oscillator (for its CPU clock), 1 pin is a reset button of sorts (or rather a permission to run connection). That leaves you with 13 pins to understand.
The remaining 13 pins are separated into ports "A" and "B", both of which you can address in software and either read or turn individually on or off. …
=== Cut needless words ===
The article references Covingtons How to Write more Clearly, Think More Clearly [...] Powerpoint presentation [1]. I highly recommend it!
A fun part in that presentation is when Covington, in a series of steps, revises this sentence...
“One of the best things you can do for yourself to improve your writing is to learn how to cut out words that are not necessary.”
..Into this one:
“To improve your writing, cut out unnecessary words.”
OPs article calls for more words to provide context. But by revising you can often cut the length in half.
[1] https://www.covingtoninnovations.com/mc/WriteThinkLearn.pdf
So I've dabbled in Prolog and used it a few times, like many here. But yes, there are people doing significant and interesting work in Prolog. A friend of a friend who I followed when I was on Facebook uses Prolog quite a bit[1]. He's not an "all Prolog all the time" person. Rather, he's well acquainted with and likes Prolog and knows when it's a good fit for the problem at hand, or for pieces of the problem at hand. Search his site for prolog and you'll get a lot of interesting info.
1. http://covingtoninnovations.com/michael/index.html
I have many Prolog books and by far the most practical or "real world" of them is "Prolog Programming in Depth" by Covington/Nute/Vellino, which the lead author has made freely available as a PDF:
http://www.covingtoninnovations.com/books/PPID.pdf
It doesn't shy away from explicitly discussing how one goes about expressing various procedural/imperative constructs in a declarative manner.
To me, it looks like the article is intended for an interested "not yet beginner", to just get them to try out astrophotography. I think it does what it set out to do.
FWIW, Michael Covington has written some fairly detailed astrophotography books:
http://www.covingtoninnovations.com/books.html
They are well worth reading.