Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
18K views

Pseudo Code

Pseudocode is meant to relax rigor and provide higher-level constructs compared to code, but it fails at both. While ambiguity allows top-down prototyping, one should just write real code with undefined functions marked clearly. Pseudocode assumes it will be at a higher level than the eventual code, but for programmers it is just a syntactic variant of the language they know best. Pseudocode is only useful for C programmers who don't know a higher-level language, but it is better to code directly in that language instead. Pseudocode remains appropriate for non-programmers describing algorithms.

Uploaded by

svidhyavs
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
18K views

Pseudo Code

Pseudocode is meant to relax rigor and provide higher-level constructs compared to code, but it fails at both. While ambiguity allows top-down prototyping, one should just write real code with undefined functions marked clearly. Pseudocode assumes it will be at a higher level than the eventual code, but for programmers it is just a syntactic variant of the language they know best. Pseudocode is only useful for C programmers who don't know a higher-level language, but it is better to code directly in that language instead. Pseudocode remains appropriate for non-programmers describing algorithms.

Uploaded by

svidhyavs
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

Pseudocode

Jeff Atwood wrote about the uselessness of pseudocode a couple of days ago. Jeff’s a
good writer, but…as usual, something seems a little off. I think that he’s drawing the
right conclusion but focusses on the wrong reasons.

The problem with pseudocode is that it’s supposed to do two things at once: relax the
rigour of real code–allow ambiguity–and also provide higher level constructs–supposedly
available in English but not in code.

Ambiguity

Allowing you to use things without fully defining them is useful, as are allowing
synonyms and skipping steps. The first is a necessity any time you work top-down while
prototyping, and the others are helpful in keeping you in the flow of the algorithm. But
there’s the problem: if you intend to get a real algorithm out of this pseudocode, you
should just write *real* code top-down. Calls functions that return undefined, nil or
your language’s Crashy Object of Choice. Then once you make up your mind about how
to implement that fuzzy thing, you’ll have a program. Example:

Pseudocode: Analyse all the good things in collection1


code = analyse . filter good
analyse = undefined
good = undefined

The difference from pseudocode is that the rest of the algorithm is rigorous, and the fuzzy
parts are clearly marked. This means that you know which parts of your algorithm aren’t
defined, unlike pseudocode, which lets you ignore that. I should be clear. This is an
advantage of pseudocode, but a weak one that is not worth the tradeoff of having
unknown stretches of your algorithm ill-defined. What’s more, you can train yourself to
use undefined functions. It’s easiest if you start in Scheme, where surrounding (some
words with parentheses) is legal syntax. Sure, the program won’t run, but the Haskell
program above doesn’t run either. In Scheme you can get away with a first draft full of
ambiguous, synonym-filled, incomplete code. All you have to do is balance the
parentheses (or get your editor to do it).

The High Level Language

Pseudocode’s second problem is worse: the assumption is that the pseudocode you use
will be significantly higher level than the code you eventually write. That assumption is
wrong for programmers. For a programmer, pseudocode is invariably just a syntactic
bastardisation of the highest level language he knows. Take my undergrad CS professor:
his pseudocode was Java, with some capitalised keywords (?) and prefix function calls
for linked lists. Also he left out some curly braces.

So, face it, pseudocode is useless for anybody writing in the highest level language they
know. That basically leaves C programmers: In these futuristic days, nearly all C
programmers know at least one high level language. Pseudocode might be useful for
them, if it weren’t so much more useful just to code in the real HLL they know instead.
Your 3-line Haskell program can serve as a useful comment and test case for your 40-line
C program. Your 37-line “C-esque” pseudocode? Not so much. (I’d also like to point out
that we have hundreds of programs lying around that can translate your high level code to
C–they’re called compilers.)

Pseudocode is still appropriate for non-programmers describing an algorithm, or if you


are working with non-programmers. Just be aware that the resulting algorithm will be at
least half wrong: either incorrect or insufficiently specified.

Incidentally, none of this refers to design documents, really, where you *do* want
English sentences describing what the software does and sometimes how it does it. But!
The line will continue to creep up as useful DSLs are defined and used and some
documents should eventually be written as code.

You might also like