Recent comments in /f/church_of_alonzo_church

Moonside wrote

Tbh in that specific case I'd just use mathematics:

f(n+1) = f(n) * g(f(n))

which is almost an implementation in some functional languages. (Nb. it's very nice to be able to use n+1 or 2n style notation in parameters, it can clean up expressions a lot.) Obviously the base case ought to be treated somehow, but that's besides the point.

I would say that ad hoc usage of pseudocode seems innocuous to me - sometimes you have improvise and there's not an common agreed upon system to draw on. Perfect is the enemy of the good. But I think its virtues as a tool for planning and documentation aren't great. If you go forth and plan or prototype your project in pseudo before implementation, why?

I'm speculating here as I don't have access to any empirical research treating this topic.

3

Moonside wrote

I've never seen a system of pseudocode that I've liked. Basically it's too concrete for planning and too abstract to be of much help when writing code. It seems to come from an era when procedural coding was all that was agreed to matter.

2