Talk:Pseudocode

Ok, I cleaned up the style discription a bit (removed some that was repeated from the earlier definition of pseudocode), and put in examples of many operations. We should still add more, like object oriented syntax ( foo.bar(baz) ? ). I'm also torn on how to do arrays... --BlckKnght

We might need the ability to create pseudo-structs (for describing tree algorithms, for instance), but we don't need any object orientation in our pseudocode (with a possible exception specifically for discussing OOP, perhaps). OOP comes into its own for programming "in the large", not for 10-line illustrations of classic algorithms.

Yes, thats what I was thinking of mostly. Object oriented stuff can use the same syntax as structs, if we decide how to do them. foo.bar or foo->bar?

foo.bar, I think. This is going to be a difficult concept for non-programmers, so you'll need to go through it carefully on the pseudocode page. --Robert Merkel

We could do like the Java language and consider anything bigger than an int to be a referenced type.

Or we could not. We are trying to build a set of conventions to describe algorithms, *not* design a real programming language to build large systems in.

WRT arrays, I would suggest square bracket indexing, and starting array indexing at 1 rather than 0. --Robert Merkel

Ok, foo[int] is definately good, but I'm not so sure about how to decide on indexing. Being a C / C++ hacker at heart, I'm generally inclined toward 0-indexed arrays, but I'm open to 1-indexed (they make complete binary trees[?] easier too) if you think that's important. --BlckKnght

The reason I suggest 1-indexing is that programmers will generally be able to cope with it, but 0-indexing is going to really confuse anybody who's not already a programmer and is trying to read the pseudocode examples. --Robert Merkel

Or we can compromise, and do like some basic dialects do: "dim foo[0 to 3] as integer", with inclusive indices. --Damian Yerrick

---

I do not like "dim" for declaring types. It will not be self-evident to people who have not programmed languages (like BASIC) that use it. I suggest instead using "declare". For example:

 declare <variable-name> as <type>
 declare <variable-name> as <type> = <initial value>
 declare <variable-name>[<lower-bound> to <upper-bound>] as <type>

Though it should only be necessary to use this for important data structures. Also I suggest types not be be restricted to "char, integer, real, or string". --Eob

s/dim/declare/g implemented (VAX Basic also uses declare), but what types should we have other than char, integer, real, string, and classes? --Damian Yerrick

We don't need char, integer and real, and string. Just describe in English what the variable contains. -- Robert Merkel

---

Dang, this is starting to look suspiciously like a real language by now, a weird mixture of VAX Basic and Python. Would we be better off switching to a Pascal dialect for pseudocode, like the early Mac OS tech manuals use? --Damian Yerrick

Agreed, it is getting elaborate. Can we get rid of class methods, for a start? While these guidelines are all well and good, the point I'd like to make is that we should freely use English handwaves to skip over nonimportant stuff. --Robert Merkel

Most of this stuff is not needed. We don't need "include" directives, functional conditionals, or member functions. We should make our pseudocode minimal and simple. Anything complicated should be explained in english. The one thing I do still think we need is a way of explaining pointers and/or references. For declarations "reference to a <type>" is probably good, but we need to dereference somehow...

hmmm. in that case, can I suggest C pointer notation for dereferencing? However, I'd recommend that we try to avoid using pointers/references where possible (and I know they will be necessary sometimes). Anyway, I'm going to chop out some of the more OTT bits of the main page. --Robert Merkel

already done quite a bit of that. see below. The type of referece/pointer usage I need is with trees and linked lists.... I'm not sure how I can avoid it. --BlckKnght

---

here's stuff I'm removing and my reasons:

Referring to another page in Wikipedia:

include linked list, hash table

Note that this must be done before the preformatted code so that users can follow the links.

Referring to a set of commonly used C functions and types:

include stdio.h

Bah! Just say in the description what it uses.

Note that == (double equal sign), not =, denotes equality; this distinguishes it from the assignment =. An optional colon (':') after the condition improves readability

use whatever is clearest. == is not meaningful to non-programmers

Functional conditionals:

if <condition>
  value
else
  other value

so far we havn't done any other functional programming stuff. I don't see that this is important. Perhaps mention it on the Functional programming page instead of here?

Arguments can be marked as pass by value or pass by reference.

when it's significant, mention it. the rest of the time, ignore the whole issue.

Long program lines:

do something that takes a lot of text to describe, and if it doesn't
    fit on one line, continue it indented at least two levels
    (four spaces) inward

write clearly, and consider how it will display in smaller browser windows, but we don't need this to be formally declared.

type can be char, integer, real, string, or a user-defined type. (Any other significant types?)

Lower and upper bounds can be integers or chars. Note that an array declared [0 to 10] would have eleven elements: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10.

I changed the surrounding parts around, so I don't think these are needed.

oops, I changed the class part without copying here first. grab it from "other revisions" if you think it's valuable. --BlckKnght

---

On talk:Algorithms I've argued that we should write our pseudocode in a real programming language, rather than pseudocode, because it is overwhelmingly more likely to be correct. Python is just as readable as the pseudocode specified here (programs written in this pseudocode will sometimes have slightly more irrelevant crap in them than the corresponding Python programs, and vice versa is also true), and has the enormous advantage of being testable.

Using a real language is likely to save us from confusing irregularities as well; some pseudocode-using pages presently use indentation to denote blocks, some refer to

Using a real programming language will also, probably, save us from hideous botches like 1-based arrays (predictably, some pseudocode pages on Wikipedia use 1-based arrays; others use 0-based arrays).

So here's what I'll do.

On pages that need something more rigorous than English, but that currently have either nothing or C, I'll write Python. On pages that presently have pseudocode, I will leave it there.

If people want to rewrite the Python code in pseudocode because they think it's clearer or more uniform, that's great. (Although I hope they'll move the Python code to a /Python[?] subpage instead of deleting it. There's no need to have multiple redundant rigorous descriptions of the same algorithm on the same page; it's just distracting.)

If, eventually, there are lots of pages that contain algorithms in pseudocode and few in Python, I'll convert the remaining Python pages to pseudocode (moving the Python code to /Python[?]). If, eventually, there are lots of pages that contain algorithms in Python and few in pseudocode, I'll convert the remaining pseudocode pages to Python (moving the pseudocode to /pseudocode[?].)

Meanwhile, the Python code for merge sort really sucks; I'm too tired to figure out how to fix it tonight, and the C code for Quicksort should probably be moved to a subpage. (And maybe it has insights that can be used to simplify the Python code.)

-- Kragen

That's quite reasonable. However, the point I'm trying to make with regards to pseudocode was that writing out complete code for an algorithm in a real language can sometimes obscure the forest for the trees, as well as require detailed understanding of the language. I would argue that the point of putting code for the algorithm in a wikipedia article is primarily to explain the algorithm better, not as a Python code resource (it can be that too, but I would argue the explanation is far more important). So, if you do use Python, try to keep it *very* simple and handwave over any tedious, unnecessary bits IMHO. --Robert Merkel

Yes, I agree, except that I don't think Wikipedia should be a Python code resource; it's an encyclopedia. I agree that it's very important to keep it very simple. However, I don't agree that we should handwave over tedious, unnecessary bits, just tedious, unnecessary bits that are a product of the language choice. Getting geometrical algorithms right, for example, typically involves a lot of corner cases that are essential to the algorithm.

The point is to build an excellent encyclopedia.

Can you try to fix the ugly Python I put in this morning? Seems to me that Quicksort and merge sort should be simpler than they are. -- Kragen