User talk:Dcoetzee/Wikicode

This pseudocode is no longer a proposed standard. See User:Dcoetzee/Wikicode.

Prologue

See also User talk:Dcoetzee/Wikicode/Specification for discussions. -- Kaihsu 15:54, 2004 Sep 27 (UTC)

For background see also Talk:Pseudocode and Talk:Algorithms on Wikipedia.

Discussion begins

Um, the bit in the opening of User:Dcoetzee/Wikicode where it says Wikicode is a new standard and Whenever you write pseudocode in an article, this style should be used -- that's just wishful thinking, right? Did I miss a vote making this an official policy, or is someone jumping the gun here? -- See also my comments at User talk:Dcoetzee/Wikicode/Specification for some context. Wile E. Heresiarch 06:21, 24 Sep 2004 (UTC)

I agree with Wile E -- I don't intend to use this should it ever come up unless we have a serious proposal and voting, and am forced to by consensus. I feel it's a bad move to invent a language for pseudocode for an encyclopedia. --Improv 04:31, 30 Sep 2004 (UTC)

I do not know the reasons of writing a mixture of C and Pascal: in my opinion it's better to move to only one side. Since I have written in both languages, I feel I can suggest to move towards C because it is well known, has more syntax capabilities, and (for what it may weight for) I do prefer it over Pascal. --Enrico. 13:38, 05 Oct 2004 (UTC)

Again, Wikicode is not a mixture of C and Pascal, and I don't understand why it continues to be characterized in this way. It does not use machine integers, the braces are optional almost everywhere, and at one time it used to use parenthesized comments and ML-style type declarations (I still would prefer the latter). This is not a C/Pascal pseudocode, although it is an imperative pseudocode. Derrick Coetzee 16:09, 5 Oct 2004 (UTC)

My attempt to fix the first example uses unsigned types, which it turns out we don't have. I'm trying to think of a way to fix that issue without over-complexifying things too much, I'd appreciate help. Pakaran . 13:02, 24 Sep 2004 (UTC)

This simple example points up a serious flaw in the whole notion of Wikicode: User:Pakaran wants to invoke unsigned integers but he feels prevented by "the standard" -- it turns out we don't have [that type]. Even in this trivial example, Wikicode is keeping someone from expressing what they want and should express. In pseudocode, people customarily make up stuff as they go along, as demanded by the problem at hand. Limiting Wikipedia writers to the subset of concepts embodied in Wikicode is unnecessary and counterproductive. Wile E. Heresiarch 14:58, 24 Sep 2004 (UTC)

The standard specifically says that you can invent new types wherever they are needed, or any particular other construct that is handy for the situation. If a real language fits particularly well, this can be used too. This will be clarified. Again, the point of the standard is not to restrict but to avoid unnecessary inconsistency. Derrick Coetzee 18:05, 1 Oct 2004 (UTC)

Language Enhancements

Right now Wikicode looks like some strange mixture of Pascal and C. Not that I mind, but it seems better to make it somewhat closer resemble one of those rather than hang in the middle, so as to prevent confusion. For instance, type declarations are probably better put after the variable, as in:

 var x: int := 2

Originally the definitions were exactly like this. This was violently opposed by User: Wrp103, so was changed. Derrick Coetzee 18:02, 1 Oct 2004 (UTC)

I don't understand why comments on separate lines use brackets instead of double-slash. The latter is so common nowadays that pretty much anyone will instantly recognize it as a comment; besides, a comment on a separate line can (and usually is) treated as a comment at the end of a blank line, so why add more special cases?

Sounds good to me. This was a result of a strange evolution of compromise. Changed. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

I'm not sure if I like the idea of implicit line continuation in absence of explicit statement separator. Relying on indentation for that would be nice if the language as a whole used the same concept. But the way it is now, it is possibly confusing. How about using backslash instead?

The language as a whole does use this concept. Braces are optional almost everywhere. Maybe the examples should emphasize this more. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Data type names. Again, a strange mixture. On one hand, shortened versions such as bool and int. On other hand, character rather than char. Perhaps better to make them all long? Would probably make it somewhat more readable, especially for someone with no background in C-derived languages.

Good point. I'm going to leave int alone, just because that's so common, but boolean is good. Changed. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Operators. First, in begs for not in (as in Python). Logical implication operator, e.g. implies, would be nice for some cases. Also, what about bitwise operators? We might need them. Perhaps C-style? But ^ is already used for exponentiation... How about replacing it with **? Oh yes, and what are the precedence rules?

Operators can be invented wherever necessary. A lot of code that does a lot of bit manipulation should just be written in C. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Description of control flow constructs is somewhat ambiguous. For example, it is not clear whether if-else requires then in it or not - some samples are with it, some are without. I'd suggest to leave it there, if only just for readability: if cond then action is easier to read than if cond action. In similar vein, while should perhaps have do after condition. do-while can be replaced with repeat-while. Oh, and while we're at it, how about repeat-until? for desperately needs a step keyword, and perhaps also do before the code block.

Actually the spec says that then is only required where the condition and action are on the same line, specifically to clear up the potential confusion you demonstrate. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Syntax for list and sets is strangely different. For list, an insert-at-of statement is used to add elements to the list. For sets, an insert() function is used. They should probably be made similar. Also, syntax for declaring variables of set, list, and map types is not defined. I suggest set, list-of and map-of-to as in the following example:

 var aSet: set
 var aList: list of string
 var aMap: map of string to integer

--Int19h 04:49, 25 Sep 2004 (UTC)

Wikicode is pseudocode and not intended to be a machine-runable language. As stated in the article, If any particular article requires you to make up functionality or change syntax, you're free to do so. Perhaps that statement needs more emphasis though.

Obviously. However, such made-up functionality and additional syntax are best be organized. Otherwise we'll eventually end up with articles written in several, subtly different, dialects of WikiCode. --Int19h 08:31, 25 Sep 2004 (UTC)

Also note that being pseudocode I'd prefer to follow mathematical conventions more than traditional programming languages. For instance rather than "unsigned int", why not natural number or non-negative. Also I'd prefer to avoid unnecessary shortening of keywords; why not variable rather than var, just like function was chosen rather than fun. int is perhaps so well known as to not matter, but still, perhaps the fully spelled-out integer would be better for pseudocode. Keep in mind that pseudocode may be used in articles other than those familiar to programmers, such as in mathematics. Complete words make it more readable. -- Dmeranda 04:57, 25 Sep 2004 (UTC)

Agreed. Especially since we can use formatting, so identifiers (and thus data types) can consist of several tokens. --Int19h 08:31, 25 Sep 2004 (UTC)

This is a terrible idea. One of the things which makes the code examples useful is that they are real languages illustrating a variety of concepts of both the article topic and the language used. Jamesday 17:16, 1 Oct 2004 (UTC)

How about % for modulus? Or is that not clear enough to everyone? Jimbobbob 03:52, 2004 Nov 20 (UTC)

I feel that an advantage of C over Pascal is shorter and less English dependent syntax. For example, { } instead of the English words begin end, ? : in addition to if then else (a pity that unlike the if keyword, the question mark isn't before the condition), and no need for a function or procedure keyword. As to mathematical conventions, why not N instead of natural number, and the use of Set theory notation, such as $i{\in }N$ instead of unsigned int i;

As to the idea of using then and long words to make code more readable, see Cobol. Instead, borrow an old idea from program editors: syntax highlighting.

Types

Types are confusing to those who do not need them, and those who do can figure them out.

Luckily, types are entirely optional. They're only placed where the author judges the type to be unclear and/or important. If the guide does not make this clear, I'll update it. Your statement is also not always true; types are sometimes an effective form of compiler-checked documentation, particularly in module interfaces. Derrick Coetzee 02:24, 13 Oct 2004 (UTC)

Formalizing

We need a standard for Wikicode that is sufficently detailed to allow construction of a syntax check function in the editor. Perl 6 could be used as a start. We also need objects for articles which require them. Again, Perl 6 is a good start. Watsonladd

Only use wikicode where a real language isn't available

If there's no code in a real language available, I guess it's ok to use wikicode if there's nothing better, but if you do come across wikicode, try to convert it to more readable (pseudo-)english, java or python (though if you insist on pascal or scheme, I'm not stopping you :-) ). It's much better to have actual readable text or runnable code usually, rather than having a fixed syntax pseudopseudocode (there's a *reason* why pseudocode has no fixed syntax, that's why it's called pseudocode. :-) ). Kim Bruning 15:16, 16 Dec 2004 (UTC)

Heh, pseudopseudocode. But yeah, this idea is in many ways the worst of both worlds.

Turing

I made this proposal on the specification talk page, but it seems like few people read that page...

A different proposal

I agree with all who have said that inventing a Wikipedia-specific language is a bad idea. I also believe that it is senseless for articles to contain 10 different implementations of everyone's favorite language and that programming articles should have one consistent programming language. Imagine an introduction to CS textbook that implemented every other example in a new language... not good for learning.

If you look on SourceForge by programming language, the languages there have these project counts:

15177 C++
14638 C
14578 Java
10767 PHP
5788 Perl
3911 Python
2320 C#
2263 JavaScript
2066 Visual Basic
1759 Delphi/Kylix

Which is interesting, but I don't think any of those languages are suitable example languages for many reasons, not the least of which will be endless battles between advocates of different languages, as well as unfairly making editing harder for people not as skilled in that language.

My proposal is simple and is based on these assumptions and premises:

use an existing language
use a language designed to have simple clear syntax (read: teaching language)
do not pick a top 10 language, choose neutral ground
do not pick a language because computer experts like it, but because it works best in an encyclopedia
readability is more important than runability on your computer (runability is going to be different for most of the reader base)
designing our own language is silly (and the straw poll backs this up)

The proposal:

In each programming article, use the Turing programming language in the article text.
Below the example, put a list of links in short form like C, Pascal, Python, Perl, ... to sub-articles with additional examples in more useful languages.

Both parts of the proposal are critical.

Daniel Quinlan 10:05, Apr 11, 2005 (UTC)

Let the reader choose

I can choose the size of the fonts in my browser. I would like to choose my favorite programming language too. Is this completely impossible?

Every user might sort the available programming languages in order of precedence in his profile. Or he might ommit this step and then the default order would be set in a most-voted fashion. The list might include Wikicode!

The code of a page would be displayed in the first available programming language of the user's list.

This behaviour might be activated or deactivated in the pages containing source code. (It would be somewhat confusing to see C code in a specific Pascal programming page)

I'm just thinking loud, but... ?? --Comocomocomocomo 15:13, 22 Apr 2005 (UTC)

MSDN entries have a feature very much like this. It displays code samples in 3 or 4 languages, and there is a filter available to limit it to one. It does make some sense that people would learn best from whatever language they're most familiar with. Deco 16:40, 22 Apr 2005 (UTC)

However, MSDN entries simply have a variety of samples hard-coded in, and display only one. Transforming code from one language to another is not feasible. R adiant _* 14:53, Jun 3, 2005 (UTC)

Of course this is true. I was under the impression that Como was suggesting a mechanism similar to MSDN whereby editors could include samples in many languages and the viewer chooses one (or some). If you don't believe editors will write the same sample in many languages, you haven't seen Quicksort implementations (which used to be part of Quicksort). Deco 21:02, 3 Jun 2005 (UTC)

Yes, I meant samples included by the editors. I have not seen the MSDN case, but it sounds like what I was thinking. Those ase bad news: I'd bet it has been patented. --Comocomocomocomo 11:07, 6 Jun 2005 (UTC)

TfD nomination of Template:Wikicode

Template:Wikicode has been nominated for deletion. You are invited to comment on the discussion at Wikipedia:Templates for deletion#Wikicode. Thank you.