3 ms·

As one of those people who have used pseudocode in papers, I have to disagree. In a scientific paper, you describe what you have in mind using mathematical defi

As one of those people who have used pseudocode in papers, I have to disagree. In a scientific paper, you describe what you have in mind using mathematical definitions. This makes it easier to reason about (proofs) and to describe it in an unambiguous way to other people (papers). Pseudocode is used to describe an algorithm following those mathematical definitions. In your paper, you might use sets. A set is defined by what it contains or does not contain. Never by how the elements found their way into the set. Including that kind of implementation detail is considered bad form (cf. forest and trees). If you wish to implement it using purely procedural code, FP, or OOP is up to you. Don't think scientists shun any kind of method just because they rarely talk about it. And for the record, I remember a number of papers that used pseudocode that could have been directly translated to working code using an OOP paradigm.

xamuel 11y ago
The algorithm might take set(s) as input, sure. If that's inherently OOP then C structs are OOP. In any case, what actually happens to those sets once they're declared, will probably be procedural. "Let I be the intersection of A and B." "Let Restriction be those elements of S which are positive." Etc. You'll rarely ever see factories, managers, private variables, explicit inheritance, or any other flagship OO mechanisms in pseudocode.
- AnonymousPlanet 11y ago
  > You'll rarely ever see factories, managers, private variables, explicit inheritance, or any other flagship OO mechanisms in pseudocode. Because they are implementation details that have no place in pseudocode. Their absence there does not say anything about their usefulness in general. You can't point at some observation about pseudocode and say "See, they don't use it so it must be rubbish." Exceptions, handling of error variables, monads, unsigned ints are also absent from typical pseudocode (unless the context is about those concepts). Does that make them useless concepts aswell?

xamuel 11y ago

The algorithm might take set(s) as input, sure. If that's inherently OOP then C structs are OOP. In any case, what actually happens to those sets once they're declared, will probably be procedural. "Let I be the intersection of A and B." "Let Restriction be those elements of S which are positive." Etc. You'll rarely ever see factories, managers, private variables, explicit inheritance, or any other flagship OO mechanisms in pseudocode.

AnonymousPlanet 11y ago
> You'll rarely ever see factories, managers, private variables, explicit inheritance, or any other flagship OO mechanisms in pseudocode. Because they are implementation details that have no place in pseudocode. Their absence there does not say anything about their usefulness in general. You can't point at some observation about pseudocode and say "See, they don't use it so it must be rubbish." Exceptions, handling of error variables, monads, unsigned ints are also absent from typical pseudocode (unless the context is about those concepts). Does that make them useless concepts aswell?