Super high-quality article. Kudos for the author.

Since Common Lisp has a low-lever goto, it's not really required to use something like SBCL for tail-call optimization. You can write a macro for it. Check Doug Hoyte's version in Let Over Lambda:

http://letoverlambda.com/index.cl/guest/chap5.html#sec_4

Very cool! I was hoping the author might have some thoughts about Clojure vs. Lisp to share — what he preferred, what he missed, what he'd use in the future.

I am pleased this is not another Gorilla vs. Shark comparison. I like that the article focuses on the thing being developed rather than the tool being used.

> when trying to build things and learn programming languages you should either build something you know in a language you’re learning, or build something new in a language you already know, but not try to do both at the same time.

This makes a lot of sense. I learned this the hard way.

How is this a postmortem? Everything seems to have gone well and nobody/nothing died...

Edit: I was under the impression that postmortem was usually used to mean a discussion of a failure of some sort. I was not aware of the project management version.

Postmortem is the de facto name for blog posts summarising how things went after a, typically, game development jam. Nothing bad has to go wrong, it's just called that.

> Nothing bad has to go wrong, it's just called that.

Correct.

> Postmortem is the de facto name for blog posts summarising how things went after a, typically, game development jam.

Not just this. Postmortem is a generic Project Management term. A process/meeting after the project's end (or the end of a part of the project) where collaborators discuss what went right/wrong is called a postmortem.

This is formalized by the bible of Project Management, the PMBOK, and Wikipedia has a nice article about the notion: https://en.wikipedia.org/wiki/Postmortem_documentation

Programmer's TL;DR: your scrum sprint retrospective and its "what went wrong" / "what could have been better" is a Postmortem.

Agree. Stop using postmortem for neutral retrospectives.

Postmortem ("after death") is a term used for diagnosing what went wrong, when something went wrong.

It's the right term to use to report on a service outage on a website, for example.

From Wikipedia project post mortem: "is a process, usually performed at the conclusion of a project, to determine and analyze elements of the project that were successful or unsuccessful. "

Why use "after death"? it's not like latin words don't have meaning...

Prescriptive vs. descriptive.

It's how this term is used already. I remember seeing it as a kid, when I first started dabbling in building games.

If we want to enter fights about prescriptive definitions, then - at the risk of committing tu quoque fallacy - I'd like to ask the JS and nouveau-functional-programming crowd to stop renaming things that already have established names. Signed, Don Quixote.

"…usually performed at the conclusion of a project…"

Conclusion, not unsuccessful conclusion. It's not incorrect to use it for any retrospective for a project that has concluded, regardless of whether it's successful or not.

But did it die? Is it referring to "after the lifetime" of the project, rather than during?

You could think of it as "death of the author". Also could be thought of as death of production.

The game jam is over, and so is dead.

The game jam itself has died, of natural causes at old age, and now it can be analyzed.

It is no more. It has ceased to be. It's expired.

Please don't post acerbic swipes.