GTD asks you to figure out now the action for each thing, think about how long that will take, figure out if it will take more than 2 (or N) minutes, and if ≤ that, do it now. The "do it now"s can add up to a lot of time and distraction. DBTC is the sorting step but without the "figure out the action" step or (most critically) the "do it now" step. And there's no reflection step, either.
So it's not "literally reinvented", not even "almost".
I'm the author of the original article, I'm a tenured professor, and none of these things is optional for me. Indeed, I wrote this article several years into being a full professor, because my obligations had only grown, not reduced, by virtue of all the promotions. Of course different people have different senses of how "obliged" they are or should be.
Ah, I didn't know there was a HOPL paper! Some day I will have time to run a course reading HOPL papers. Some day I will have the time to read HOPL papers myself (-:. Thanks for the pointer.
Thanks for the pointers. Trampolining is an old idea for obtaining tail-calls. It's a kind of folk-wisdom that has been rediscovered many times, as the related work here shows:
Usually the trampoline is implemented automatically by the language rather than forcing the author to confront it, though I can see why Clojure might have chosen to put the burden on the user.
Tails calls are especially useful in languages with macros. You don't know what context you are in, you just generate the call that makes sense. If the call happens to be in tail-position, you get the benefit of it.
Moreover, you can design cooperating macros that induce and take advantage of tail-position calls.
Here's a simple example that motivates tail-calls that are not tail-recursive:
The correlation is likely causal in both directions.
They're niche because they're doing weird, interesting things. Like creating their own VMs to support funky features. So nobody wants to depend on them: low bus-factor.
They can do weird, interesting things because they don't have a large user-base that will yell at them about how they're breaking prod.
They will give you a sense of how one uses LOP productively.
You do not need to write a "web server language"! To the contrary, the Web server provides several languages to give you a trade-off between ease and power in writing server-side Web applications. So you can just write regular Racket code and serve it through the server. The server also comes with some really neat, powerful primitives (orthogonal to LOP) — like `send/suspend` — that make it much easier to write server-based code.
This isn't meant to be a good programming mechanism, it's meant to be an illustration of how to use the macro system.
But also, if you're processing non-linear data, you're going to want to do with a recursive function anyway. E.g., when dealing with a tree. Code below; can't seem to get multi-line code-formatting so it looks hideous:
Racket is a rich and powerful language, but it is also designed with certain specific ideas in mind. You can learn more about the "zen" of Racket here:
It's definitely written from the perspective of someone who "knows C++". But I put that in quotes because there are (at least) two interpretations of that phrase. There's the person who doesn't know any C++ at all, and for that person, this is useless. But there's the person who knows a baseline of C++ but doesn't know modern C++, and they can use this as a way to modernize their C++ code while ignoring the Rust bits. But either way, yes, it doesn't warn you about C++ footguns (other than pointing you towards Rust <-;).
https://en.wikipedia.org/wiki/Proof_of_work