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.
twovests wrote
I like using pseudocode when there's a lot of magic that needs to happen and you want people to know what that will look like.
magic_fib (n) = magic_fib(n - 1) * something_else_magical(magic_fib(n - 1))
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.
twovests wrote
i guess in a functional language pseudocode would replace larger swathes than just adding something_else_magical
but tbh i only ever used pseudocode imperatively :c
Moonside wrote
The curious thing is that I've never really seen functional language pseudo being written. But then again I'm not a serious programmer or a software engineer.
Viewing a single comment thread. View all comments