On Aug 15, 2:34*pm, Registered User wrote:
On Sun, 15 Aug 2010 03:53:05 -0700 (PDT), K1TTT
wrote:



if you can't code it in a 'real' language how would you code it in a
pseudo code? *that just doesn't make sense.

Agreed.

the whole purpose of
pseudo code is to help work out logic and program structure at a high
level. *

Your interpretation of pseudo code seems much broader than mine. I
view pseudo code as a non-verbal means to describe the nuts and bolts
of an implementation. I don't see pseudo code having the ability to
describe design patterns, even basic procedural patterns such as
inheritance, polymorphism and encapsulation. Pseudo code just isn't
abstract enough and doesn't scale well enough to communicate larger,
more general concepts, principles and ideas.

A design pattern might call for a collection of references to objects
where pseudo code would use an array of pointers. Abstractly they are
the same but while a pointer is a reference, a reference per se does
not have to describe an object's location in memory. A reference could
be something as simple as an index into an array. It's a subtle
difference but most meaningful. In this example the design pattern can
be implemented in C# while the pseudo code presents a stumbling block.

Then again at certain levels of abstraction, design patterns might be
described as being pseudo code. Design patterns are very useful in
revealing what public properties and methods types will require
without drilling down to implementation specifics.

it wouldn't be much good if you couldn't break it down into
actual code in the end.

Design patterns can do this nicely for OO languages. I can't speak for
FORTRAN as I haven't had occasion to use that language in almost forty
years. Still it seems a FORTRAN flow chart would fall somewhere
between design patterns and pseudo code. A flow chart does describe a
specific design without specifying implementation details.

there is OO fortran also!