Not all books approachs algorithms in a procedural manner, however. Higher Order Perl, for instance treats a number of algorithms from a functional point of view, as do most books on Haskell. Books on SQL algorithms (like my favorite, SQL for Smarties) are mostly declarative in style.

Giving it some more thought and after some online research, I think I have a clearer view on this:

We should separate two things: algorithms and programming techniques. Algorithms like "to solve ax = c for x, divide c by a" have nothing to do with programming techniques. It's a way humans are used to think about "stuff to do" in "steps". Our computers are designed this way - no matter what language / paradigm you use, down bottom it compiles to some sort of machine code, which is inherently procedural and linear. Turing machines, the universal model of computation, are as linear as you can get.

OTOH, programming techniques like functional, logical and OO are just different ways to *implement* algorithms. Some of the repliers raised the issue of different (non procedural) representation of algorithms. That's curious, but still probably less useful to people, who are "designed" to think in a procedural way about solving problems.

I think the graph module shows an example where the algorithms are naturally object-oriented. They match at least these three hints paraphrased from Damian Conway's ten rules for when to use OO:

• Data is aggregated into obvious structures.
• Data forms a natural inheritance hierarchy.
• Many different operations are applied to one piece of data.

Other good examples for OO would be matrix and graphics algorithms.

Sort algorithms in Prolog may be interesting to you.

This is obviously some strange new usage of the word "interesting" I've never been made aware of. *shudder*

With apologies to D. Adams and A. Dent . . . :)

Algorithms are pretty well language agnostic. Knuth makes this point in "Art Of Programming" by designing an imaginary computer (with a number of strange properties, like it could be binary or it could be decimal) and then presenting all of his examples in assembler code targeted for this imaginary computer/cpu enviornment. He says that this is important as programmers have a tendency to use constructs that are as brief as possible in the language they are using, and not necessarily as efficient as possible and that a CPU level understanding is necessary to truely understanding and analysing algorithm efficiency.

Its important to remember that FP, OO and Imperative programming are all just different tools, none of them really is any better than the others, just more suited to different types of problems, and with their own particular quirks. OO makes it really easy to write bizarre and inefficient solutions, FP has been known to drive folks mad, and Imperative code often is just horribly difficult to understand and maintain, but underneath they all break down to the same set of CPU instructions, and the CPU really doesnt care where those instructions came from.

  m[i,i] = 0
  m[i,j] =  min  { m[i,k] + m[k+1,j] + p[i-1]*p[k]*p[j] }
           i<=k<j
[download]

What you're seeing is a trick of the light.

There are infinitely many ways to express algorithms, some of which look nothing like structured code. You can implement any given algorithm with a network of logic gates, for instance, or a cellular automaton. They're both Turing-complete, but neither their definitions nor their operation look much like procedural/structured code.

It's true that algorithms do support the concept of state, and with it, a primitive concept of time. Any statement that follows the general pattern: "do this, then use the results to do that," defines boundaries between the inputs and outputs of an operation, and establishes the basic idea that one thing needs to happen before another. Yes, that's 'procedural', but it isn't inherently 'structured'

Writers explain algorithms with structured code because that happens to be what people are used to. Structured programming.. specifically the notion that all programs can be written with:

• nested functions with a single entry point and well-defined exit points
• while() statements with some simple variants (for() loops, next, last, and redo modifiers, continue blocks and so on)
• and if-then-else statements

is the common denominator of every programming language made since the 1970s.

It's surprisingly easy to convert structured code to OO code, though.

An Object is bascially a Random Access Machine, which can be summarized as a block of addressed memory with a set of functions which operate on that memory. To refactor a piece of structural code as OO code, you start by turning all your variables into object attributes, and all your functions into object methods. At that point, you have compatible, if somewhat trivial, OO code. It won't necessarily be good OO code, but it will follow the OO paradigm.

Basically, though, the fact that you're seeing structured code everywhere is a self-selecting convention. Writers use it because they assume it will be familar to any programmer trained in the last 30 years. If OO becomes the dominant mindset for programming (or FP, or some declarative style, or some formal-methods typesystem), the writers will shift over to a pidgin version of whatever is most popular.

And that's not just pedantry, either. There are definitely fields of algorithms wherein the most natural way of expressing the algorithm is not procedurally. Take proofs by induction, for example: those are much more naturally represented functionally.

I think that maybe what's throwing you off is the definition of algorithm you've got there. That's simply not a good definition of the term, as it says "step by step". A better way of describing an algorithm would center more on the fact that it is a complete and unambiguous description of a way to solve a problem, not that it is "step by step". "Step by step" is sort of begging the question, if you will, of how that algorithm is represented (as "steps", in this case)... and that's really imaterial to what an algorithm is.

------------
:Wq
Not an editor command: Wq
[download]