I can appreciate the emphasis on iteration versus recursion, as recursion is not taught to some people.
I don't agree that iteration is always preferable. A recursive algorithm that searches a binary tree is simpler
to understand, requires less book-keeping in variables, and is in general, preferable when explaining to a neophyte.
I think there are an entire class of problems that are similar. --
BenBaker
I'm aware that recursion vs. iteration is one of more controversial of hints listed.
There is certainly class of problems are much easier to solve using recursion than iteration.
That is a hint for problems that can be solved equally easily with both methods (like fibonacci).
There is also a problem that various people find either of methods "simpler to understand".
There's some point in providing both implementations, so both groups can find easy-to-understand algorithm.
Probably some weaker wording should be used. --Taw
Iterative where immediately apparent would be nice. On the other hand, if its a problem that lends itself to recursion, no reason not to. programming is complicated, there's no two ways about it.
BTW, Even with iterative constructs available in LISP, I tend to go recursive just because the language lends itself to it, but in C I go iterative if I can help it. Something to think about... --alan d
I think this page should be renamed "List of Algorithms", should have a one-line explanation of every algorithm, and should be listed on
Reference tables. I don't think it makes much sense to try to dictate in which way people are to write sample implementations. Personally, I'd prefer pseudo code. Also, why is it directed at
Unix programmers? What about
Hurd hackers? --
AxelBoldt
- Page name is almost irrelevant.
- One-line ok
- Reference Tables done
- It's not discating, it's setting standards
- It makes LOT of sense. Bad sample implementation is almost completely useless.
- Pseudo code is really bad idea. It is in no aspect better than real languages like Ruby or Python. It's impossible to test, so may contain errors and one has to assume many things like array indexing about it. Pseudocode should be discouraged.
- It should be directed at Unix programmers, because majority of people interesed in this topic knows Unix or technologies that come from it, like C. No Unix-specific quirks in code of course.
- Objectively speaking, Hurd is kind of Unix or at least mostly Unix-compatible.
- Hurd hackers are very small group of people and I'm sure that all of them know some other Unices.
--
Taw
- Page names involving "Wikipedia" are generally taken to be meta articles about Wikipedia, not genuine Wikipedia articles. If this is intended to be a policy article about Wikipedia coding standards, then there should be a separate list of algorithms.
- While it is true that pseudo code cannot be tested, it is intended for human understanding and may therefore contain less errors. Programming languages often contain obscure constructs (= vs == for instance, or overloaded division /) which make understanding harder. Just because you can test a program doesn't mean that it is less likely to have errors.
- The reference to Hurd was a joke. I was alluding to the fact that there are many programmers which don't use Unix.
The article should be directed at programmers, period. --
AxelBoldt
So the only unresolved issue is pseudocode, right ?
Arguments for pseudocode and against simple real languages:
- Rarely used languages like Ruby may confuse readers
- Pseudo code forces the programmer to think through the algorithm before implementing it; the danger with real code is that they just cut and paste
- Pseudo code can focus in on the heart of the algorithm, glossing over trivial parts (initializing of arrays, type casts)
- Pseudo code is the most concise description of an algorithm designed for human consumption, programming languages are designed for consumption by computers.
- Pseudo code can use generally established conventions of mathematical notation (xn, √x, x mod n), while avoiding idiosyncracies of programming languages.
- Any algorithm that can be expressed at all can be expressed in pseudo code; some algorithms can not be expressed in some programming languages.
- ...
Arguments for simple real languages and against pseudocode:
- Pseudocode can't be easily tested, so may contain subtle errors like off-by-one
- Pseudocode needs explanations about things like == vs. =, type of division, array indexing etc. before each example
- Pseudocode isn't standarized, so it may confuse reader
- Reader can't play with sample implementation, and playing can help to understand in case of some algorithms
- Pseudocode needs some redundant information, for example it must have array size specified as separate variable, while in most languages constructs like array.size can be used to get it.
- Pseudocode can't be easily used for many algorithms, for example those involving pointers
- ...
I'm moving Ruby into the list of less-recommended languages.
Smalltalk and Eiffel both have many more users than Ruby does, so if you're going to recommend
against them (which I think is reasonable), then you have to take out Ruby as well.
The only ones I think have a significant enough user base that any programmer should
at least be familiar with them are C/C++, Java, BASIC, Pascal, Perl, and Python.
BASIC and Pascal are bad because there are too many incompatible variants.
-- LDC
C programs can be a mess because to write them portably, taking into account char-size, endianness etc., can make them unreadable. While I like Perl, I think it is unreadable unless you have really used it quite a bit. Ideally, I would like the sample implementations to be relevant to beginning computer science students as well as to working programmers. --AxelBoldt
![[Home]](wikipedia.png)