text:
Wikipedia talk:WikiProject Computer science/Manual of style
WikiProject Computer science | (Rated Project-class) | ||||||||||||||||||
- 1 Arbitrary section header
- 2 Recursion vs. Iteration
- 3 Role of this page
- 4 Pseudocode vs. real code
- 5 Choice of language criteria
- 6 Standardized pseudocode
- 7 Samples of code for popularity
- 8 Haskell?
- 10 Proposal: construct our own "executable pseudocode"
- 11 LiteratePrograms
- 12 Major Changes
- 13 The programming language in algorithm articles
- 14 Wikicode
- 15 And/Or
- 16 Introduction Example
- 17 Functional pseudocode
- 18
 and
- 19 Concrete Implementations of Algorithms
- 20 Code Samples
- 21 Pseudocode syntax
- 22 New formatting tag
- 23 Sample good programming language articles
- 24  vs. ?
- 25 High Level Pseudocode
- 26 Wikipedia:Manual of Style/Computing
Arbitrary section header[edit]
A couple of points:
- OOP is about programming in the large. For programming in the small (to provide illustrative examples of algorithms, for instance), OOP is just a bunch of unnecessary cruft. Hence, Java and C++ don't add very much over C for the purpose of illustrating fundamental algorithms, and the cruft gets in the way of understanding.
- Some of the HLL's (Perl, for instance), aren't exactly ideal for describing implementations of data structures (trees, hash tables etc).
- As far as the untestability of pseudocode, most algorithms we present should be verifiable by inspection.
- Perl looks ugly and encourages, er, idiosyncratic coding. It's great for getting jobs done. It's bad for presenting examples in, IMHO.
- Of course, I think we should present most of our algorithms in something like Haskell, but I can't see us winning that argument :) --Robert Merkel
- Yeah Robert I agree at most. Especially for C as I don't understand all the HLL's, PERL's, IMHO's, Haskell 98's, Haskell++, O'Haskell's and Mondrian's stuff you've written. C++ and Java are very active nowadays and perhaps according to C++, through C# and some other futher classification efforts C will see its own rebirth. I am also very much interested in RPN programming and in Maple V R4.00a codeing for the number theory applications. --XJamC 4 Wednesday (Thor's day) [2002.02.28) (0)
I suggest as a compromise the Python programming language one of the most readable progamming languages, often described as "executable pseudocode". -- Anon.
I would be very much in favour of real pseudo-code. This has benefits that
- No programmer is "angry" because the implementation is in a - in his eyes - stupid, silly, inferior programming language (it's NPOV). Moreover, they will not feel compelled to add other versions of the same algorithm
- No details of implementation have to be presented, and use of mathematical signs (also variables with subscripts) or plain text make the code very readable
- Pseudocode makes it possible to focus on what's important about the algorithm.
- An encyclopedia is about things, not the things themselves. Therefore, having executable code is not very useful (it's not in all languages anyway). If somebody is interested in implementing one of the algorithms, pseudocode should give him more than enough information to implement things in his favourite language, especially if the article also contains some pointers on implementation details (f.e., an algorithm on graphs can point to an article Graph representation in programming, or something like that.
I could probably go on here, but I think my point is clear. A problem of pseudo-code is of course that there's no standard, but it should not be a problem to create a Wikipedia pseudo code language, and linking to explanation when used. Jeronimo
- If you fully define a pseudocode then it becomes a code. Next thing someone will write a complier for it, then people will start with the language pissing matches etc.... ;-)
- Hehe, you might be right. But te definition should simply define some syntax (assignment, if-then-else, while-do, etc). The rest of the notation should be relatively free. That's why it's pseudo-code. Jeronimo
Recursion vs. Iteration[edit]
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
Role of this page[edit]
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.
- 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
Pseudocode vs. real code[edit]
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 think the argument that "Pseudocode can't be easily tested" is a spurious one. Unless we're engaged in "original research", the pseudocode in question should be coming from some external (referenced) source, so there shouldn't be any need to test it (although there might be a need to proof-read it against the reference). With regard to the argument about sample implementations
- constructing their own sample implementation based on the pseudocode will probably help the reader gain an even better understanding of the algorithm
- unless we're planning on providing sample implementations in every conceivable language, there's a chance that $RANDOMREADER won't be able to make use of the sample implementation anyway
- there's nothing that says that there shouldn't be a few sample implementations in addition to a good language-independent pseudocode description of the algorithm
- --Allan McInnes 00:44, 29 January 2006 (UTC)
- I think the argument that "Pseudocode can't be easily tested" is a spurious one. Unless we're engaged in "original research", the pseudocode in question should be coming from some external (referenced) source, so there shouldn't be any need to test it (although there might be a need to proof-read it against the reference). With regard to the argument about sample implementations
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.
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
Choice of language criteria[edit]
There are two things that need to be considered in choosing languages - its readability and its popularity. That's why languages like Python and Ruby, which were designed (successfully) with readability in mind are more apropriate, while Perl and C are less apropriate, than they would be if only popularity mattered. I put Eiffel and Smalltalk on discouraged list not only because of their little popularity but also because of their non-standard syntax, and it case of Smalltalk, philosophy.
About popularity:
- From http://www.eros-os.org/pipermail/e-lang/2001-October/005793.html (freshmeat projects count, only relevant entries quoted):
- Python: 403
- Ruby: 31
- Eiffel: 16
- Delphi: 15
- Pascal: 15
- Smalltalk: 3
- Visual Basic: 6
- Object Pascal: 4
- Basic: 1
- so if Unix hackers are considered, BASIC, Pascal, Smalltalk and Eiffel are less popular than you stated while Ruby is more. (in other groups, popularity ranking will be different)
- BASIC and Pascal aren't bad only because there are too many variants. There are many bigger problems with these languages. (details are easy to find online)
- Nowadays most new programmers aren't familiar with Pascal and BASIC. They might have seen some code, but haven't used it to do anything serious. Most schools don't use these languages for teaching and they are virtually unused in UNIX world.
- Ruby's popularity is comparable to Python's in Japan (there was article on /. about it, but i don't have hard data handy) --Taw
- Algol was specifically designed to be used for print media in a pseudocodish kind of way. Why not continue the tradition?
Standardized pseudocode[edit]
As a beginning computer science student, I request that all algorithms be written in a Wikipedia-standardized pseudocode. I'm not particularly familiar with any language, and IMO, the most generalized presentation would be of greatest benefit. There's no reason why there can't also be implementations in Python or Java, giving us the best of both worlds. --Stephen Gilbert
What's the point in "standard" pseudocode as compared to using simple real world language ? --Taw
- I find that pseudocode helps me understand the general algorithm, as opposed to a specific implementation of it. Why can't both pseudocode and a simple real world language be used? --Stephen Gilbert
Samples of code for popularity[edit]
Freshmeat is hardly an unbiased sample, and the numbers quoted are too small to mean much anyway. Google returns twice about as many hits for "Smalltalk language" and "Eiffel language" as it does for "Ruby language". Check out any bookstore: you're likely to find 5-10 books on Eiffel and Smalltalk; I think only one Ruby book exists. Smalltalk is big in academia as a teaching language (like Pascal used to be, and Java is now), so a lot of people are familiar with it even if it doesn't get used for real projects much. I have no idea what you mean by its "philosophy" or why that matters. BASIC isn't used in academia and it's not used much in Unix, but it's still the #1 most popular programming language by many measures--let's not kid ourselves that the world is Unix--the world in Windows, and us Unix hackers are growing minority, but still a minority.
The Ruby code does have the advantage that it's pretty readable as pseudocode for simple things. All in all, I think if I were to add code samples here, I'd use Java (which you omitted from the table above--its count is 740, above all those you mentioned and below C/C++, Perl, and PHP), since it is quite common, well-defined and standardized, and quite readable. -LDC
- By user count, world may be Windows, but by programmer count it's not.
- I wouldn't call Java very "readable".
- Google count for 'basic language' and 'basic programming language' contains mostly false positives on main page - basic is popular english word after all
Your first point may be true; it would be hard to measure. Perhaps the "bookstore" metric would be useful there as well (that is, count the sales of related books). I personally don't find Java any less readable than Python or Ruby; they all use the same operators, keywords are sensible, etc. At any rate, that's a matter of personal taste. Yes, searching for "BASIC language" on Google would be silly, which is why I didn't do or suggest it. Even the ones I did do are only the roughest possible estimate, just like your "Freshmeat" metric. Another metric that might be useful is to look at newspaper job advertisements. Java, C, and BASIC (usually MS VB) programmers are in greatest demand, followed by Perl, ASP (a BASIC derivative), and miscellaneous others.
I'd support using real programming code (my favourites would be C/C++ or Java, but take your pick), not psuedocode. The problem with psuedocode is that there are no standards, and sometimes it is difficult to interpret. At least with real programming code, there is always only one (in theory at least) interpretation for the code. -- SJK
Why don't we just let everybody use their favorite programming language? That way, not only will we get the biggest possible catalog of sample implementation, but we will also get a nice collection of sample code snippets that we can link to from the respective programming language pages. Whenever you come across an ugly sample implementation in language you don't understand, like Scheme, just add your own implementation written in Brainfuck. Can't hurt, can it? --AxelBoldt
Nobody's saying that one can't add another sample implementation, if there is some reason of doing it. Hints are made so people have easier time if they're unsure what's the good way. --Taw
I'd prefer real code to pseudocode in general, but sometimes pseudocode is far more readable. For example, I just added an algorithm to Complexity_classes_P_and_NP. It's 8 lines of pseudocode, and fairly readable (I think). In any real language, this would be far less readable, since you'd have to build an interpretor, and deal with all sorts of data structures that aren't really important to the central idea. --LC
But that's because it's hardly an "algorithm", it's rather abstract mathematical construct --Taw
That's what algorithms are! Actual code implements an algorithm, which is the abstract mathematical construct of a sequence of steps to produce a result. Taw uses pseudocode here to give a very high-level presentation of an idea. In a real language, you'd have to just put in a procedure call like "RunProgram(x)", and comment that this is left as an exercise for the reader. :-)
The list of algorithms seems to be rather slewed towards algorithms used in computer programming. Do algorithms like Euclid's algorithm (a numerical algorithm) and Grover's algorithm (a quantum algorithm) belong? Or are the lists meant to be geared towards computer programming? -- CYD
- See /More talk for the page history of this section. Graham87 01:38, 8 May 2008 (UTC)
A couple of points:
- OOP is about programming in the large. For programming in the small (to provide illustrative examples of algorithms, for instance), OOP is just a bunch of unnecessary cruft. Hence, Java and C++ don't add very much over C for the purpose of illustrating fundamental algorithms, and the cruft gets in the way of understanding.
- Some of the HLL's (Perl, for instance), aren't exactly ideal for describing implementations of data structures (trees, hash tables etc).
- As far as the untestability of pseudocode, most algorithms we present should be verifiable by inspection.
- Perl looks ugly and encourages, er, idiosyncratic coding. It's great for getting jobs done. It's bad for presenting examples in, IMHO.
- Of course, I think we should present most of our algorithms in something like Haskell, but I can't see us winning that argument :) --Robert Merkel
- Yeah Robert I agree at most. Especially for C as I don't understand all the HLL's, PERL's, IMHO's, Haskell 98's, Haskell++, O'Haskell's and Mondrian's stuff you've written. C++ and Java are very active nowadays and perhaps according to C++, through C# and some other futher classification efforts C will see its own rebirth. I am also very much interested in RPN programming and in Maple V R4.00a codeing for the number theory applications. --XJamC 4 Wednesday (Thor's day) [2002.02.28) (0)
I suggest as a compromise the Python programming language one of the most readable progamming languages, often described as "executable pseudocode". -- Anon.
I would be very much in favour of real pseudo-code. This has benefits that
- No programmer is "angry" because the implementation is in a - in his eyes - stupid, silly, inferior programming language (it's NPOV). Moreover, they will not feel compelled to add other versions of the same algorithm
- No details of implementation have to be presented, and use of mathematical signs (also variables with subscripts) or plain text make the code very readable
- Pseudocode makes it possible to focus on what's important about the algorithm.
- An encyclopedia is about things, not the things themselves. Therefore, having executable code is not very useful (it's not in all languages anyway). If somebody is interested in implementing one of the algorithms, pseudocode should give him more than enough information to implement things in his favourite language, especially if the article also contains some pointers on implementation details (f.e., an algorithm on graphs can point to an article Graph representation in programming, or something like that.
I could probably go on here, but I think my point is clear. A problem of pseudo-code is of course that there's no standard, but it should not be a problem to create a Wikipedia pseudo code language, and linking to explanation when used. Jeronimo
- If you fully define a pseudocode then it becomes a code. Next thing someone will write a complier for it, then people will start with the language pissing matches etc.... ;-)
- Hehe, you might be right. But te definition should simply define some syntax (assignment, if-then-else, while-do, etc). The rest of the notation should be relatively free. That's why it's pseudo-code. Jeronimo
This is a simple issue. Use C++ without any object oriented constructs and without pointers except for binary trees and other dynamically allocated data structures. References should be used whenever possible. Also, no macros.
Secondly, clarity/readability should be emphasized over speed.
- basic syntax of C++ is essentially the same/easily understandable by programmers in other languages
- C is widely known
- Avoids Unix specific languages such as Ruby, Python, Perl, etc. (NB: Technically, these are portable but almost all users of those languages use linux/unix).
- Why C++ and not C? Also although a lot of samples are in C, once you start having to deal with pointers it's probably getting too bogged down in the C-ness of it and you need a more "pseudo"-type language such as Python. —EatMyShortz 13:55, 14 February 2006 (UTC)
- There's a very good reason not to use C/C++ exclusively. Their syntax has a lot of problems, and C++ in particular is extremely verbose, even for relatively simple things. A lot of the built-in operators are counterintuitive to people who just know high-school math, such as assignment/equality, not-equals, bitwise versus logical and/or, and so on. They use different bitwise operators from computer engineers. Damian Conway has written papers on how confusing C/C++'s declaration syntax is. Additionally, C is limited to fixed-size integers, which makes many algorithms in number theory and other areas much more complicated. C++ at least has string operators, That said, I do support procedural code samples for most things, and I have often used C samples where they are simple. Deco 20:07, 14 February 2006 (UTC)
- I don't think using any concrete programming language is a good idea, as the clearest algorithms are written with appropriate section in words, e.g.
union of Xi for i ∈ { 1 ... n }
is infinitely clearer than(apply union xs)
in Lisp/Scheme,foldl union [] xs
in Haskell, and the corresponding C++ iterator loop. --Mgreenbe 20:35, 14 February 2006 (UTC)
- I don't think using any concrete programming language is a good idea, as the clearest algorithms are written with appropriate section in words, e.g.
- I have to agree with Mgreenbe that the requirement of executable code in a concrete programming language is only going to obfuscate things. High level pseudocode allows you to condense something that would require considerable complexity in a concrete language into a simple and accessible description in pseudocode. For instance I think it would be hard to write an executable version of Buchberger's algorithm in C or C++ or Scheme or Python that is going to be as clear as the psuedocode presented - far too much code would be spent dealing with the complications of implementation rather than in explicating the important steps of the alorithm itself. Leland McInnes 22:03, 14 February 2006 (UTC)
- I agree that it's not good to use a certain programming language indefinitely. In the case of Buchburger's algorithm, that's explained as it stands in a mixture of pure maths and english - a very pseudo pseudocode. Which is good - since it's broken down into these neat steps and it's a very mathematical procedure, it's good to have it expressed like that. I think problems like this though should be explained in "pseudo pseudocode" and then also more detailed in "pseudocode" - see Longest-common subsequence problem, where it is explained twice - thrice in fact. So I think we should only use computer code for either simpler things, or more-computational-less-mathematical things. Python would be my language of choice - even if you've never used it it is very easy to understand, some of my lecturers use it for pseudocode even though they haven't taught us the language. C should be used on things like 'Pointer' where it's necessary to explain it. —EatMyShortz 02:14, 15 February 2006 (UTC)
- How about Topological sort then? That's largely computational and is fairly simple. The algorithm, as presented in pseudocode, is quite clear. Converting that into executable code is going to involve declarations of some sort of data structure to hold the graph, and then manipulations specific to that structure cluttering up the internals of the algorithm itself. The result will still be readable, but it will be more complex, less clear, and do a much poorer job of actually expressing the important points with regard to how the algorithm works.
- Pseudocode is also more neutral, thus less inclined to induce language wars and redundancy via multiple different implementations in multiple different langauges. Pseudocode is also more flexible - you aren't bound to a the constructs offered by a particular implementation: for example pseudocode could support pointers, or pattern matched functions, or dependent types. As long as you can find a clear generic way of expressing it, pseudocode can be bent to any task required of it. I don't believe that's particularly true of any concrete languages - certainly not without extra hoop jumping (such as metaprogramming in Lisp) to set it up. I would ask, instead, what the benefit of expressing algorithms in a concrete language is. Anything presented as (pseudo-)code on Wikipedia ought to be referenced and verifiable by inspection, so correctness can't be the issue. If you want to provide people with a working example they can play with - you're making the assumption they have a compiler or interpreter for the language you've chosen. Instead working examples would much better be provided on a linked page or on Wikisource as a respository of implementations in as many different languages as people care to submit - why limit yourself to one implementation language, and why clutter the main page with multiple implementations in different languages?
- It seems to me that pseudocode is the most neutral, the most expressive, the most flexible, the most consistent, and the simplest solution. I see few real benefits to using a concrete language that can't be obtained by simply linking to a page of concrete implementations. In turn there is much to be lost in straightjacketing yourself into concrete implementations, particularly if you want to have consistency. Surely pseudocode, standardised with some basic guidelines outlining suitable style, is the most natural answer? Leland McInnes 02:40, 15 February 2006 (UTC)
- Well expressed - I agree. I think the only problem with pseudocode is that it *isn't* standardised so as somebody said, it isn't immediately clear what you mean by "=" for example, and some people start using <- arrowey things for assignation, and it all becomes inconsistent. I'd like to see some consistent pseudocode rules set up, with the intention of having writers need to know the rules and follow them, but readers can understand them just by looking. However this has already been proposed and failed (Wikicode), probably because nobody took the interest to learn how to write it. —EatMyShortz 13:52, 19 February 2006 (UTC)
- Why not have a look at the draft Wikipedia:WikiProject Computer science/Manual of style (computer science)? I think most of the feeling is against strict pseudocode structure, but syntax we can agree on. --Mgreenbe 14:37, 19 February 2006 (UTC)
Proposal: construct our own "executable pseudocode"[edit]
I've been thinking about the real-language versus pseudocode debate, and I think an interesting compromise would be to construct an "executable pseudocode" language with a real interpreter specifically with the aims of readability, simplicity, and brevity in small code samples. To facilitate embedded English statements, we could either allow English statements to "summarize" (hide) sections of code that implement them, or we could have the interpreter pause and make the human interpret the English statement. This would allow us to test code samples without succumbing to the idiosyncrisies and verbosity of real languages, with the additional benefit of ensuring regularity of syntax for common constructs like loops. Real languages could still be used where one is particularly suitable or simple, or in a supplementary fashion.
This is all a little abstract, so here's a contrived example. Let's say you type this very C-like text into a text file:
function insert(array a, int length, value) { set i to index of last element while i >= 0 and a[i] > value { a[i + 1] := a[i]; i--; } a[i + 1] := value; }
You run it through a "beautifier" which converts it to this pretty wikitext, expanding or replacing counterintuitive constructs and operators and adding bold/italics:
function insert(array a, int length, value) { set i to index of last element while i ≥ 0 and a[i] > value a[i + 1] ← a[i] i ← i − 1 a[i + 1] ← value }
Next you load this up in the interpreter. It gives you an input-eval-print loop in which to enter test invocations. Let's say you type "insert({1,3,5,0},3,2)". It executes the above function, and when you get to "set i to index of last element", the interpreter stops and asks you to carry this action out. You type "i := 2" and then continue running. The result "{1,2,3,5}" comes back.
So that's a brief preview - any suggestions or criticism welcome. Deco 21:23, 14 February 2006 (UTC)
- Who would be entering an algorithm that is unable to either (1) test and experiment with a working implementation or (2) prove correctness (perhaps following a proof in a book)? I feel like anyone who doesn't fall into one of these two categories shouldn't be entering algorithms. So would this be helpful to readers? I wouldn't find much use from it (biased sample). Perhaps it would be more helpful to leverage WPCS to add real-language implementations of algorithms to Wikisource. --Mgreenbe 22:08, 14 February 2006 (UTC)
- Unless someone is doing original research, any algorithm that gets entered into Wikipedia should be traceable to a reference. The algorithm should not require any testing or proofs, because the reference is responsible for the correctness of the algorithm. At worst, the algorithm may need to be proof-read against the reference. This is true regardless of whether the algorithm is provided as pseudocode or in a particular language. IMHO the algorithm itself should be defined in pseudocode, for many of the reasons that Leland describes below. I think it's reasonable to have sample implementations of an algorithm that are not traceable to a specific reference (perhaps generated by WPCS members) where those samples are based on the pseudocode presentation, which is traceable to a reference. Where a sample implementation isn't directly based on the pseudocode (or where no pseudocode is provided), it should be traceable to a specific reference. --Allan McInnes (talk) 23:19, 14 February 2006 (UTC)
- While I appreciate your efforts (and particularly the benefits of your experience in this issue) I would like to question how important it is to actually have "executable" code. A few people have cited the need to ensure "correctness" but executability doesn't guarantee correctness, only that the code can be tested - it may still fail for corner cases or cases that haven't been tested. Moreover I would suggest that any algorithm (pseudo)code posted should be checkable by inspection - if it isn't then the algorithm really needs to be rewritten at a higher level to make the important processes clear. I would also suggest that any algorithms really ought to provide a source: given a loose/general enough set of pseudocode guidelines transcription from, and verficiation against, the source pseudocode ought to be trivial.
- On the other hand the requirement of executability is a heavy constraint leading code to become potentially mired in necessary implementation details that obscure the important points of the algorithm. Your suggestion of allowing english descriptions of steps that the executable simply prompts the user for is a good one, and does go some distance toward alleviating this issue, but might not always be sufficient. For example, consider the pseudocode for Topological sort: the statement for each node m with an edge e from n to m do is clear enough, but prompting the user to find all the nodes connected by and edge from the given node at each step of the for loop is going to be beyond most people for all but trivial examples, and will still be tedious even for those trivial cases. This could be alleviated by having a suitable data structure declared for the graph, but then the essential points of the algorithm become lost amidst the necessary manipulations of that data structure: it will still be readable but more complicated and less focussed on how the algorithm actually works, which is to say less clear.
- In short I believe that "executability" is vastly overrated - the costs are high but the benefits are negligible in comparison. Leland McInnes 22:31, 14 February 2006 (UTC)
- I also believe executability isn't really all that necessary for the code we deal with here, particularly when we can supply supplementary real-code implementations for that kind of experimentation, but there is a certain faction that is unwilling to adopt standard notation for any sort of code that isn't executable. In addition to allowing the user to specify the semantics of English steps, they could be specified by "hidden code" that actually implements the prose description, as in:
'''function''' insert(''array'' a, ''int'' length, value) { ''set i to index of last element''  '''while''' i ≥ 0 '''and''' a[i] > value a[i + 1] ← a[i] i ← i − 1 a[i + 1] ← value }
- renders as:
function insert(array a, int length, value) { set i to index of last element while i ≥ 0 and a[i] > value a[i + 1] ← a[i] i ← i − 1 a[i + 1] ← value }
- I'm not certain if this generalizes, though. If nothing else I do rather like the idea of a translator for beautification and normalization of pseudocode. Deco 22:54, 14 February 2006 (UTC)
- I also rather like a code beautifier - it seems like a sensible thing to have around. As to "hidden code" - I'm curious as to how well that will scale, particularly for a lot of mathematical algorithms that are best presented at a very high level. Could we not standardise some method for providing executable implementations (whih can be any a wide variety of languages) on some subpage, or Wikisource, linked to from the article? That seems a moe natural way to provide executable code - Wikipedia isn't meant to be a source repository, while Wikisource is... Surely having a link to a wikisource page with working implementations in a dozen different languages is a far better way to go? Leland McInnes 23:07, 14 February 2006 (UTC)
- You might want to check out what I did with quicksort and quicksort implementations. The concept there was to provide a few representative implementations in the article, and shove the rest out to another article, sharing the common ones in a template. I did this not because I believe implementations belong on Wikipedia, but because people will keep adding them if they're not there (I don't understand this compulsion of adding sample code). The odd thing is that even though there were a gazillion implementations, many of which almost exactly reflected the pseudocode, it didn't discourage overzealous anons from breaking the pseudocode from time to time. But the same problem exists with real code. I personally think there should be a separate code sample repository project under a non-copyleft license, but that's not going to happen (I've tried). And yeah, the idea of executable pseudocode seems increasingly infeasible. :-) Deco 01:02, 15 February 2006 (UTC)
- In fact what you did with quicksort and quicksort implementations has been taken as the model of how to handle such a situation for use in the project style guidelines for WP:COMPSCI! I feel that it is the most natural way to deal with concrete implementations. Perhaps it should be suggested that all algorithm pages have a prominent link to an implementations page (though maybe link to Wikisource). A lot of thoe pages will, naturally, be blank, but if the link is prominent hopefully it will encourage people to put their implementations there and we can end up with a good code library on Wikisource. Leland McInnes 02:46, 15 February 2006 (UTC)
- Update: Quicksort implementations has been deleted. If additional unencyclopedic implementations are added in the future, feel free to remove them — better to train the contributors about what's appropriate than to encourage them to add anything so long as it stays out of the way. —donhalcon〒 21:12, 27 February 2006 (UTC)
Hey all. This is really an advertisement, since this isn't a Wikimedia project, but I thought some of you might be interested in a new wiki I've started using a modified MediaWiki server. It's called LiteratePrograms, and is based on the idea of literate programming. The concept is that every article is simultaneously a document and a program; the document describes the program piece by piece, and there's a "download code" tab at the top to automatically reassemble the pieces and download it as ready-to-compile source code. I also added automatic syntax highlighting for the code segments. Here are some sample articles:
- http://literateprograms.org/Insertion_sort_%28C%2C_simple%29
- http://literateprograms.org/Turing_machine_simulator_%28C%29
Any feedback is appreciated. Deco 08:51, 2 March 2006 (UTC)
- Wow! Great idea! I really like the
tags — it'd be nice if we could get something similar here on WP. I think LP would make a nice complement to WP articles on particular algorithms, and an excellent repository for implementations (and helps to resolve the licensing issues). --Allan McInnes (talk) 17:45, 2 March 2006 (UTC)
- Thanks! I was a bit worried that people would see it as attempting to supplant some aspect of Wikipedia, but it really is distinct in purpose. For the most part I link to Wikipedia for descriptions of the concepts, and the articles just describe specific implementations. At the moment the codeblocks are invoking the external perl tool code2html, which probably wouldn't scale for Wikipedia, but it could easily be rewritten in PHP - it just does some simple regular expression search and replace.
- As for licensing, that's a little tricky. Wikimedia wants everything to be under the GFDL, which I really don't think is an appropriate license for code (no disclaimer of warranty/liability, and big companies are very edgy about copyleft code). Using a less restrictive license permits wider use, but also prevents copying of content from Wikimedia projects without the authors' permission. I've got my wiki set up to add comment blocks with the (very short) MIT/X11 license at the top of each downloaded source file (at least the ones it knows how to write comments in). This is nice in that each file can be redistributed separately, whereas a GFDL'd or GPL'd archive would have to include a LICENSE file that has to be redistributed with each substantial part. The comment text is at MediaWiki:Copyrightcomment. Deco 19:12, 2 March 2006 (UTC)
- That is a rather good idea but once again, we need to choose a programming language, universal enough, and that may be translated easily in other programming languages. The code currently used, that is Python actually, is not easy to translate. The lack of typed variable and return of functions is a real problem. Pascal is a better choice. Splang 14:13, 17 May 2006 (UTC)
- Huh? The LiteratePrograms wiki currently contains code in about 30 or 40 different languages. Python is one of those languages, but the wiki also includes everything from Assembler to XSL. Pascal is also represented, although there are only a few Pascal programs at present. You are welcome to add more (so long as they are under released under the MIT/X11 license). --Allan McInnes (talk) 16:24, 17 May 2006 (UTC)
- My comment is misplaced and this is confusing. I repeat it in its own section. Splang 17:27, 21 May 2006 (UTC)
Major Changes[edit]
This page has been extremely static for some time in a state that could be, at best, described as "provisional", and at worst as "dithering, non-committal, and largely meaningless". With that in mind I have decided to be bold and import the work from WikiProject Computer Science Manual of Style to try and get things moving with some assertive guidelines. I'm not suggesting this to be a necessarily finalised version - this topic should remain open for input and discussion. I do hope, however, that discussion can proceed working from this rather more complete set of guidelines. Discussion is most welcome! Leland McInnes 05:39, 20 May 2006 (UTC)
- Shouldn't this page just redirect to the WPCS MoS? —Ruud 19:21, 21 May 2006 (UTC)
- I viewed that as being a little too bold. WPCS MoS is still just a WikiProject style guide and contains things (like suggestions to link to Literate Programs) that probably aren't ideal for actual Wikipedia policy. Besides, I would rather spend a little more time getting the MoS in good shape and then try and get it promoted to similar footing as Wikipedia:Manual of Style (Mathematics) as a set of official Wikipedia style guidelines rather than doing things piecemeal. Leland McInnes 05:30, 22 May 2006 (UTC)
The programming language in algorithm articles[edit]
We need to choose a programming language, universal enough, and that may be translated easily in other programming languages. The code currently used (for example in the quicksort page), is Python actually, it is not easy to translate. The lack of typed variable and return of functions is a real problem. Pascal should be a better choice. An XML-like syntax (as that of Scriptol) should be perfect, for universality. Splang 14:13, 17 May 2006 (UTC)
- Er... if you look closely, I think you'll see that the "code" in the quicksort is actually not Python at all (unless Python has recently started supporting operations like
add pivot to pivotList
). The examples are in pseudocode. If it looks like Python, that might be because Python has often been described as looking like "executable pseudocode"). I'm not sure why you say it's "hard to translate to other languages". The examples look extremely clear an easy to translate to me (note that I did not write the examples - I'm not sure who did). What exactly is the problem with them?
- Pseudocode is generally a better choice for describing algorithms than any specific language. It permits the description to focus on the essentials of the algorithm, rather than the quirks of any one language. As for what the pseudocode should look like, you will probably never get precise agreement on that either (look up Derrick Coetzee's wikicode proposal to see what I mean). As it stands, the current Algorithms on Wikipedia page prescribes some basic guidelines, while leaving the specifics free enough that individual editors can do what makes them happy. If there is a specific piece of pseudocode that you feel looks "too Python-like", and would benefit from being made more "Pascal-like", then feel free to make those changes. --Allan McInnes (talk) 18:57, 21 May 2006 (UTC)
I've read through the Wikicode debate, and I think any similar effort to define a standard is going to hit similar brick walls. I think the best we can hope for is a decent set of "style guidlines" for pseudocode, and a corresponding effort to try and clean up pseudocode to meet the guidelines. Personally I would have to favour a more mathematical/algebraic style if possible, and generally trying to keep to a fairly loose set of guidelines. I expect this will be a significant point for debate. That's probably going to be a good thing: people who are drawn in to argue can be encouraged to to join the project. Leland McInnes 23:19, 28 January 2006 (UTC)
- Yeah, I've read through the same debate, and pretty much came to the same conclusion. My intent in putting the wikicode link there was not to mandateanything, but (a) to make people aware of it, and (b) to provide some "guidance on style", based on existing work. I agree that a more mathematical style would be nice, but, as you say, also a huge point for debate. --Allan McInnes 23:32, 28 January 2006 (UTC)
On the subject of pseudocode: IMHO some of the objections about verifiability raised in the wikicode debates are totally spurious - if the algorithm in question is not original research then the pseudocode should be coming from some known (and preferably referenced) source, such as the Cormen book. Perhaps that's another argument in favor of loose pseudocode guidelines - if algorithms are transcribed in the style of the source material there's less chance of errors. --Allan McInnes 23:32, 28 January 2006 (UTC)
Okay, here's my take on some basic guidelines for pseudocode:
- assignment, comparison, and other mathematical operators should be rendered with proper mathematical symbols wherever possible:
- assignment: ←
- comparison: =, ≠, <, >, ≤, ≥, etc.
- arithmetic: +, -, ×, /, mod, etc.
- control structure keywords should be bolded, comments should be in italics (in addition to whatever other manner for denoting comments is used)
- preferred conditional structure is
if condition then code path else if code path else code path end if
- preferred looping constructs are
while condition do code block repeat
- and
for loop_control do code block repeat
- where loop_control is any suitable clause to control a for loop, such as item in list or 1 ≤ i ≤ n etc.
Feel free to tear that the shreds. Leland McInnes 00:12, 29 January 2006 (UTC)
I've copied an extended version of this suggestion to the main page, including a description of how to format suitably complex mathematical algorithms (following the standard conventions in math for such algorithms). Perhaps we should get some involvement from Wikipedia:WikiProject_Mathematics on getting this more formalised. Further ideas and suggestions are most welcome. Leland McInnes 04:29, 29 January 2006 (UTC)
As a side note we might want to in general stick to structures that have an "obvious" one-to-one mapping to features in most programming languages: good things would be say, using indexed lists as opposed to pointer/refrences (like C) or a loop with a conditional as opposed to list comprehensions (like Haskell or Python). It might be beneficial to define to formally enough so one could write a program to produce pretty good code in a given language from the pseudo-code. --NotQuiteEXPComplete 23:49, 4 May 2006 (UTC)
Assignment operator[edit]
Traditionally, academic pseudocode has used := for assignment (and that's likely to be the case for sources we use); shouldn't we stick with that for consistency? --bmills 17:46, 11 February 2006 (UTC)
- I've seen both := and ← used in academic pseudocode. Personally, I'm ambivalent as to which actually gets used. These are meant to be "guidelines" anyway, rather than hard mandates. Given that they are "guidelines", perhaps it would be better if these guidelines stated that either version is acceptable. Leland? Ruud? --Allan McInnes (talk) 17:57, 11 February 2006 (UTC)
- Makes sense to me to state that either is acceptable. I certainly agree that both tend to get used. I'm a mathematician so I generally see more of ← so I went with that. I'll amend the page to reflect either is acceptable. Leland McInnes 22:57, 14 February 2006 (UTC)
- I personally prefer ← over := and this is also the notation used in TAoCP and Introduction to Algorithms. I'd also prefer some cosistency among the algorithms, but I also know that this is most likely not going to happen. —Ruud 23:07, 14 February 2006 (UTC)
- I like ← more as well, not least because it isn't a composite of two characters. If we could muster some level of , if not consensus, at least plurality then perhaps we could note that ← is the preferred option, but that := is "acceptable". In the end it's a matter of what we can actually find support for with a minimum of pointless arguments. The looser the guidelines the less arguments, but the more varied the resulting pseudocode. I would happily support a preference for ← - any other takers? Leland McInnes 23:19, 14 February 2006 (UTC)
- For being slightly more language neutral and simply looking better on my screen I would be willing to claim that ← is preferred over :=. —Ruud 23:28, 14 February 2006 (UTC)
- It does look a little nicer and resembles fewer real-world languages, but it doesn't match very well with the old-style keywordy pseudocode we've got so far. Most of our pseudocode resembles academic papers from 1965-1985, which is when := was most heavily used due to its easy representation in ASCII and other character encodings. --bmills 03:13, 15 February 2006 (UTC)
- Please feel free to suggest a more modern less keyword driven pseudocode - things are far from written in stone. I went with something resembling Wikicode, with a few variations for "readability" and "genericity" where I felt appropriate (like eliminating curly brace block delimiting), as a best first guess. Improvements are more than welcome. Leland McInnes 04:46, 15 February 2006 (UTC)
If we're going with "proper mathematical symbols wherever possible" for algorithm descriptions, shouldn't and and or really be rendered as ∧ and ∨? Note that I'm not opposed to using and and or if it leads to more readable algorithms. Just questioning how consistent it is with the guideline we have, as stated — I'd be open to altering the wording of the guideline (e.g. to simply recommend the use of the symbols in the table, whatever they may be). --Allan McInnes 17:13, 2 February 2006 (UTC)
- I'm not sure about this on, I think and is more readable in an if-statement, but ∧ in an boolean assignment. And we propably also need a bitwise-and which people should be able to recognize without reading this page. —Ruud 17:19, 2 February 2006 (UTC)
- Perhaps the right way to go is and and bitwise-and (as well as things like exclusive-or). That should be readily understandable to anyone without reference to this page. But let's wait and see what some of the other people working on this have to say first. --Allan McInnes 17:27, 2 February 2006 (UTC)
- I think that would be a good idea, as programmers without any formal education are likely not to recognize symbols like ⊕ and ∧. —Ruud 17:38, 2 February 2006 (UTC)
- JA: Fashions come and go. I recall a time when everybody felt like "real logo-maths don't use words", then it became hip, er, cool, er, PC to write out even immoderately pleonasty things like "if and only if". I think if we follow a rule of "what helps a reader" (WHAR? -- what they did to me in CS with their acronymania is another story), then we'll probably interweave both, hieroglyphs suitably cartouched, and laxer lingo in line. But I'd leave it to the category of friendly advice, and not make an auto(matic)-da-fe out of it. 'Cause you know, "Nobody Expects The Spamish Inquisition" (NETSI). Jon Awbrey 17:44, 2 February 2006 (UTC)
- Understood. These guidelines are meant as just that: guidelines. Not a mandated style. Just something to help achieve some consistency, and to provide some tips for people who are creating a new article. The Wikicode
debacledebate made it pretty clear (to me at least) that trying to mandate a standard is doomed failure. --Allan McInnes 19:41, 2 February 2006 (UTC)
- Understood. These guidelines are meant as just that: guidelines. Not a mandated style. Just something to help achieve some consistency, and to provide some tips for people who are creating a new article. The Wikicode
Introduction Example[edit]
The project page suggests
It is a good idea to also have a basic introduction to the topic, with reduced technical detail and suitable for a high school student or a first-year undergraduate, as appropriate. The basic introduction should give the reader sufficient understanding of the topic to grasp how and where the concept might be used, and a reasonable ability to judge when it might be applicable to a specific problem. For example,
And after much hunting I have failed to find any articles that have a suitable introduction to be provided as an example. There may well be one out there, but it is certainly hard to find. I suggest that it would be beneficial to the project to choose a suitable article (preferrably one we wish to try to rapidly move toard featured article status) and simply write an introduction. With enough hands focused on the task surely something suitable can be realtively quickly hammered out. Does anyone have any candidate articles? Curry-Howard could possibly work, and Topos already has an introduction, just not one suitable for high school students (though it could be made so with a little work). Any other suggestions? Leland McInnes 01:13, 3 February 2006 (UTC)
- That particular suggestion was as much wishful thinking on my part as anything else. I suspect some topics are just going to be too hard to boil down to the high-school level. The best we'll be able to do is copious wikilinks to the terms and concepts we're using. And no, I don't have any suggestions for examples, although I agree that Curry-Howard is quite good, and I think that Finite state machine does a pretty reasonable job. --Allan McInnes 02:41, 3 February 2006 (UTC)
Perhaps it would also be useful, in some cases, to have introductory analogies or the problems which inspired a specific solution. For example, the dining philosophers problem should be contained in (or at least breifly explained in) the article on semaphores. Right now is it only linked to from the article. Perhaps the solution should be phrased in terms of the analogy as well. I suppose that my suggestion boils down to saying that when stating solutions, we should make some effort to state the problem as well, both in formal terms and in terms of some analogy. Any thoughts? --NotQuiteEXPComplete 13:44, 14 July 2006 (UTC)
Functional pseudocode[edit]
The proposed pseudocode looks good, but what about functional pseudocode? There's an awful lot of bad Scheme code in Wikipedia, quite a bit of Haskell (which is actually fairly readable for a beginner), a bit of ML, and a lot of lambda calculus. Just sticking to lambda calculus works well for "pure" functional code, but a lot of the functional pseudocode uses algebraic data types with pattern matching, which don't exist in pure lambda calculus. --bmills 17:43, 11 February 2006 (UTC)
- Good question! During the Wikicode debates I believe that they decided that "imperative pseudocode is more understandable". Which may be true, for imperative algorithms :-) But of course some things are better expressed functionally though (trying to describe Okasaki's purely functional data structures using imperative pseduocode would probably be a bit of a stretch). So, what to use? I agree that pure lambda-calculus isn't really feasible. But I'd also prefer not to pick one language (e.g. Haskell or ML): pseudocode is supposed to be language agnostic. There's also the question of lazy vs. strict semantics. I have no idea how to handle that.
- With regard to what the pseudocode should look like, I like the look produced by the lambdaTeX Haskell typesetter (that look in turn being based on Okasaki's style of typesetting ML). It's also somewhat consistent with the guidelines we've already laid down for imperative code.
- --Allan McInnes (talk) 18:24, 11 February 2006 (UTC)
Haskell looks pretty much like ML if you don't go too wild with it's more advanced features. My guess would be that it is pretty readable to Lispers and Schemers as well. What about using Haskell, but not using lazy-evaluation unless explicitly stated, avoiding the more obscure functions and operators from the Prelude and writing λx.x instead of \x->x?</haskell-propaganda-mode>
—Ruud 18:39, 11 February 2006 (UTC)
- That's pretty much been my standard; sounds fine. I think it's best to lean on the Haskell/ML family, as there's a great deal of ignore-on-sight prejudice towards Lisp syntax. To the unacquainted, Haskell/ML definitions are also a lot clearer than Lisp definitions. --Mgreenbe 18:47, 11 February 2006 (UTC)
- I agree with the above. Plus, Haskell was invented to provide a kind of lingua franca for FP, so it makes sense to lean on something Haskellish. I also like the idea of using λx.x instead of \x->x. Beyond that, please take a look at the way lambdaTeX (mentioned above as well) typesets things like type signatures and the like. --Allan McInnes (talk) 18:56, 11 February 2006 (UTC)
- The pseudcode guidelines were meant to be fairly loose and flexible, and just guidelines anyway. I think it's reasoanable to be fairly free in terms of what you do beyond the rough structures the guidelines lay out - for instance you'll note that there is no mention of types at all. If you don't feel you can extend the existing pseudocode guideline into something suitable for functional algorithms, feel free to suggest a different set of guidelines for functional code, hopefully hewing to the same sort of style/flavour as what currently exists. Leland McInnes 19:41, 11 February 2006 (UTC)
After taking another look at the existing pseudocode guidelines, I couldn't quite see how a Haskellish syntax would fit in there. So I decided to try something else. I've added a proposed guideline for pattern-matched functions to the MoS. It follows the style we've already established much more closely than Haskell does. If it looks ok to everyone here, maybe we can give some thought to how we might translate other common FP constructs into this style. If everyone hates it (I'm willing to concede that it's a little clumsier than Haskell) maybe we should consider revisiting the guidelines for imperative code too. I'd prefer if we could come up with a single "style", since it's entirely possible that there'll be some pages that mix imperative and functional code. Come to think of it, how are we going to deal with object-oriented code or logic code? Might as well cover all the paradigms... --Allan McInnes (talk) 05:50, 12 February 2006 (UTC)
- It looks okay to me (though some optional delimter to mark the end of a patterns code block might be nice). In general, however, I a loathe to getting into too much detail in guidelines on this and the particulars of various programming paradigms. In principle the pseudocode guidelines are for documenting algorithms, and if you method of expressing an algorithm requires the use of various constructs idiosyncratic or idiomatic to particular programming paradigms then I would suggest that you should either
- Consider describing the algorithm at a higher level that doesn't require such constructs
- Consider a how such constructs can be expressed in a more generic way
For example, with pattern matching, it might be easier to have, for example,
function factorial is Input: n, a non-negative integer Output: the integer value of n! if n = 0 then return 1 else return n × factorial(n−1)
- which, while a little more clumsy, is probably clear to a much wider audience. Of course not everything will work this way, and it may well occur that you need special constructs. In that case I think some sort of guideline with regard to "do the obvious thing" ought to be enough. For instance, if you had to use pattern matching I think the current suggestion is a perfectly good example of "do the obvious thing", and while I can think of other variations they will be, for the most part, sufficiently similar that it won't matter. Similarly if you need to use OO then anything along the lines of
class class_name is variable foo variable bar method method_name is code block end method end class
- will most likely be fine, where "variable" and "method" can be "var", "property", "member", or "data" etc., and "procedure", or "function" etc., without any real loss. I think once you try and codify too many particulars such as this you start digging yourself into the Wikicode hole. I would rather not go there. Leland McInnes 22:46, 12 February 2006 (UTC)
- The vertical bars delimit the start of a new pattern (similar to the way ML does things. I'm all for "doing the obviosu thing" — I just threw the example out there to start some conversation. --Allan McInnes (talk) 03:54, 13 February 2006 (UTC)
- I've tried to include some explicit instructions to avoid idiomatic pseudocode where possible and "do the obvious thing" where it isn't. For now I've removed the pattern match example - it didn't fit with the guidelines I added. Don't take that as a rejection of it, simply as me being unable to figure out how to elegantly include it. It seemed very natural and in line with the current style to me. Perhaps we can have some "general suggestions" regarding idiomatic code outlining how to do pattern matching, types, algebraic types, classes etc. though I would prefer to separate that off somehow into more of a "suggested examples" rather than clutter up the guidelines themselves. Leland McInnes 04:54, 13 February 2006 (UTC)
- Sure, that's fine with me. --Allan McInnes (talk) 05:16, 13 February 2006 (UTC)
I've started a page of "suggested examples" as a userpage (thus not conferring any authority to it) so we can at least have a resource for ideas about how to implement various idiomatic structures and techniques in line with the currently defined general style. Please stop by User:Leland_McInnes/Pseudocode_examples and feel free to add, edit, or otherwise fix and extend the examples there. Leland McInnes 03:01, 14 February 2006 (UTC)

 and [edit]
I think that  should be used instead of (or in addition to)
 for code in articles. That is, after all, what that tag was intended for, and we should be using our markup to actually mark up the document.
Here's an
inline pre block
and an inline code block
. Note that the code block actually works inline, whereas the pre doesn't.
However, Wikipedia's engine hates code blocks by themselves.
int main (void) {
printf("hello world\n");
return 0;
There are two possible solutions:
- putting pre blocks inside code blocks:
int main(void)
printf("hello, world\n");
return 0;
- starting all code with at least one leading space:
int main (void)
printf("hello world\n");
return 0;
If someone could improve the engine, I think it would be best to just use ; otherwise, I think we should use pre blocks within code blocks. Regardless, we should ensure that all code (inline or in block form) is enclosed in  tags. That way we can do the following:
Consider the main
function for the "hello world" program:
int main(void)
printf("hello, world\n");
return 0;
Note the use of printf
to display the output.
--bmills 18:02, 11 February 2006 (UTC)
You should write inline code with  and outline code like this (doesn't require code or pre)
id :: a -> a id x = x
—Ruud 18:27, 11 February 2006 (UTC)
- The problem you're running into there is fundamental to HTML, not just an issue with MediaWiki. Unfortunately, HTML doesn't fully support semantic markup. I'm not sure what the best solution is. --Allan McInnes (talk) 18:29, 11 February 2006 (UTC)
- I'm more concerned with making edits easier, and with making the pages forward-compatible — if we use the  tag for all code, it doesn't cause any harm, and it does make it easier for screen-readers and other HTML-processing software to figure out what is code and what isn't. Also works well on the off chance that the user has custom CSS set for code.
- While HTML isn't fully semantic, it seems to me that we should apply as much semantic information as we can; in this case, that means tagging our code as code. I'm going to go ahead and add something to that effect since this is a pretty volatile draft; if anyone feels strongly otherwise do feel free to remove it. --bmills 03:20, 15 February 2006 (UTC)
- I created two templates {{algorithm-begin}} an {{algorithm-end}} for use in the alorithm article. Is this the kind of semantic information you are reffering to? (Although the templates also add some visual information.) —Ruud 17:01, 15 February 2006 (UTC)
- Not really; mainly I mean that definition lists should use definition list markup,
 should only be used for tables, etc. Since there's an HTML tag for code, we should use it. --bmills 17:39, 15 February 2006 (UTC)
- I don't think I follow you here, you shouldn't use  for bold or
 for tables, MediaWiki markup is not HTML although is does allow a limited set of it. —Ruud 17:49, 15 February 2006 (UTC)
- Right, but MediaWiki markup compiles down to appropriate HTML; since there isn't any MediaWiki markup for code, we should use the HTML for it. --bmills 17:55, 15 February 2006 (UTC)
- Not for
inline code
, no. But there is for
- Not for
outline code
- so I guess you are talking about the first? —Ruud 18:03, 15 February 2006 (UTC)
Concrete Implementations of Algorithms[edit]
Sometimes it is beneficial to have a concrete implementation for explanatory purposes, but generally pseudocode is better. This, of course, doesn't stop people producing implementations in their language of choice and adding them to the page. Just look at Quicksort implementations to see how out of hand that can get. The logical place for such a repository of implementations is on Wikisource, and we really ought to be encouraging people to take their implementations there - because certainly a code repository of implementations of each algorithm is certainly of value. On that front I've begin to think that maybe the right way to go is to create a template for algorithms that links to a corresponding page on Wikisource as the place to find implementations, and start attaching the template to algorithm pages. Sure the Wikisource page in question may not exist yet, but a suitably worded template can imply that it's the place to look for (and put) implementations, but not to expect to necessarily find them. Something like "Concrete implementations in various languages, if any have been submitted, can be found at link". Is it worth trying to make such a template? Comments? Suggestions? Leland McInnes 04:42, 15 February 2006 (UTC)
- I agree that an encyclopedia is a poor place to put to implementations (as you may have seen from my recent edits). As such, I think we should discourage outright links to implementations; to do otherwise will only provide people with the idea that links to implementations are acceptable in general, and thereby encourage linkspam from people adding their favorite other implementations. If we want to point out the existence of materials on Wikisource, we can always use Template:wikisource, which has that nice "sister project" look rather than the "link to some other page" look.
- However, my reading of Wikisource's goals is that it's mainly a repository for copies of public-domain and GFDL texts, not source code. I don't think we should even be promoting it as a repository for code; that's what SourceForge is for, though it's not a WikiMedia project. --bmills 05:05, 15 February 2006 (UTC)
- How about just using
{{Template:Wikisourcehas|implementations of this algorithm|'''''[[wikisource:Special:Search/{{PAGENAME}}|{{PAGENAME}}]]'''''}}
- whenever unnecessary implementations are added, and simply shuffling off implementations there. I admit that Wikisource may not be an ideal place for a code repository - but it is certainly a better one than Wikipedia. Leland McInnes 05:23, 15 February 2006 (UTC)
- It looks as if there isn't a simple answer for this. How about we just follow the Quicksort implementations example and divert to a different Wikipedia page? Still far from ideal. It is useful information, and it ought to be somewhere - the question is where is the right place for it? At this point I'm quite open to suggestions. Leland McInnes 05:40, 15 February 2006 (UTC)
- It may be useful, but it's not encyclopedic; it belongs in a more general repository of useful information (a.k.a. the World Wide Web!) rather than Wikipedia in particular, which aims to be an encyclopedia. Maybe it could go to SourceForge or the Great Compiler Shootout or something. Regardless, I intend to put Quicksort implementations up for deletion soon (we'll see where that goes). --bmills 05:52, 15 February 2006 (UTC)
- I did hear something about Wikisource (planning on) deleting a whole lot of source code a few months ago. Yet one some other page I read host source code (yet, this may only be primary source code, if there is such a thing?) Could be interesting to see what happends when you place Quicksort implementations on AfD though. —Ruud 11:15, 15 February 2006 (UTC)
- I do remember seeing code on Wikisource before (including a few quicksort implementations). But a quick search now shows that they appear to have purged many of those pages. I agree with bmills that lists of implementations are unencyclopedic (I early brought this up at Talk:Quicksort implementations, but was persuaded by Deco that it was a reasonable defensive measure). As you say, it'll be interesting to see where the AfD goes. --Allan McInnes (talk) 18:27, 15 February 2006 (UTC)
Code Samples[edit]
Given the line being taken on inclusion of source code (which I generally agree with) I think perhaps we should actually have some clear an explicit guidelines as to exactly when code samples are and are not acceptable. At the moment the explanation is fairly vague, and I think some firm policy would be beneficial. Clearly code to demonstrate the look of a language, for example on the various language articles, is justified. Equally language specific features, or, at least, features that aren't easily translatable into easily understood generic pseudocode, are also reasonable. Are there any other cases where code samples are acceptable? I'd like to get something resembling a firm policy hammered out reasonably efficiently. Leland McInnes 22:25, 15 February 2006 (UTC)
- I'd say don't use real code on articles describing algorithms, but it may be helpful in articles describing programming constructs. —Ruud 22:46, 15 February 2006 (UTC)
- What kind of constructs did you have in mind? I could see it making sense for language-specific constructs. But illustrating a general for-loop doesn't seem like it would require an actual implementation. --Allan McInnes (talk) 23:04, 15 February 2006 (UTC)
- Ok, point taken. I suspect there might be situations (don't ask me to name them now :) in articles on programming where you might want use some real code, so having a general policy against it might not be most sensible to have. —Ruud 23:28, 15 February 2006 (UTC)
- Algebraic data types don't lend themselves well to pseudocode, since the pseudocode ends up being essentially ML or Haskell. I think the main idea is that if actual source is used, it needs to be intelligible to people who don't know the particular language. --bmills 03:49, 16 February 2006 (UTC)
- I think the point is that while the particular pseudocode dealing with algebraic data types may be indistinguishable from Haskell of ML, that's not really sufficient reason to put an entire example in Haskell or ML. If it's only code that's indistinguishable from Haskell then the entire example is sufficiently generic that once can hardly say that is necessarily Haskell, and if there is other code involved in the example then I don't see any necessity to make that extra code language specific. Probably I am simply lacking in imagination as to necessity. Could you could give me an example of something that is clearly Haskell or ML rather than a generic "any of the above" and needs to be so? Leland McInnes 04:20, 16 February 2006 (UTC)
- I'm not sure it's a matter of necessity so much as one of consistency and correctness. With language-specific examples, the example can be tested (and automatically checked for proper syntax and types); with pseudocode, the example cannot be executed unless the pseudocode can be executed (and then it's not so "pseudo", now is it?). There's something to be said for mechanical validation. --bmills 05:07, 16 February 2006 (UTC)
- This gets into the interesting debate of verifiability of pseudocode. How about we compromise with: if most sources/references only provide a language specific example, then code is fine. If there are sources/references with language neutral or pseudocode presentations then those should be preferred. Psuedocode should be verifiable against the source. Leland McInnes 06:21, 16 February 2006 (UTC)
- A very good point: if a reliable pseudocode source can be found, such as the original paper or a variant, use that. I volunteer to be an ACM lackey for nonmembers. --Mgreenbe 11:57, 16 February 2006 (UTC)
- That sounds good to me. Pseudocode is clearly best if it can be verified; actual code samples are allowable if they are clear and concise and add to the encyclopedic content of the article. --bmills 14:16, 16 February 2006 (UTC)
- I think that sounds like a reasonable position to take. I think the key point is that any algorithms or code must be traceable to a reference. I too can act as an ACM lackey for nonmembers. --Allan McInnes (talk) 19:01, 16 February 2006 (UTC)
Rudy, I take the challenge! The chief utility of code samples is to serve as a grounding, usually for one of two reasons:
- Showing concrete errors (e.g. buffer overflows) under fixed semantics (e.g. pointers in the C-family). What is the pseudocode for a NULL-dereference?
- Clarifying complicated/unique programming-language ideas (e.g. monads in functional programming). Any notation we choose which is not Miranda/Haskell/Clean/... is either misleading, too verbose, or both.
Representative code samples in programming-language articles are also helpful, where "representative" means characterizing the syntax and style. "Hello world" programs do not fall into this category. --Mgreenbe 01:45, 16 February 2006 (UTC)
- Sounds like decent guidelines to me. Effectively it amounts to
- In concrete language or implementation specific discussions.
- When generic pseudocode is inadequate to accurately express the concept.
- though I'm sure much better phrasing could be arranged. Leland McInnes 02:46, 16 February 2006 (UTC)
- I feel guidelines only benefit from ambiguity and example-based reasoning. So I would propose the following:
- Include actual code only when it is absolutely necessary; pseudocode is preferable.
- Examples of cases of inclusion and exclusion would be: language pages (abstracting the syntax is only confusing, so use code), complicated or abstract ideas (a fixed semantics helps, e.g. monads or buffer overflows), and algorithm pages (not absolutely necessary; explain the properties of unique implementations in pseudocode or prose). --Mgreenbe 11:57, 16 February 2006 (UTC)
- I feel guidelines only benefit from ambiguity and example-based reasoning. So I would propose the following:
- Hmm... That may be more restrictive than necessary. How about:
- Include actual code in an article only when it significantly clarifies existing prose or pseudocode.
- That definitely includes pages about languages and complicated algorithms (which should have a prose description anyway). A point I added the other day should specifically exclude pages like Quicksort implementations:
- Multiple source code implementations are not appropriate unless they contrast specific aspects of the code and that contrast is important to the encyclopedic content of the article. If possible, accentuate differences by providing the alternate implementation in the same language as the original.
- (That point is already in the article.) --bmills 19:29, 16 February 2006 (UTC)
- Hmm... That may be more restrictive than necessary. How about:
Pseudocode syntax[edit]
The content here overlaps with Wikipedia:WikiProject Computer science/Manual of style (computer science). Which should be the main source? I added the integer division operator to the table. Considering that we have floor and ceiling operators, it may be useful to distinguish. But now I don't know where I should be changing.
The algorithm keyword is a bit redundant. It has the same role as function. I think we should remove it from the Ford-Fulkerson example.
I think we should have a notation for arrays, lists and sets, together with proper operators (especially for sets; that would simplify some parsing algorithms when their correctness proof uses set theory).
And what about increment operators? For example, Counting sort currently (26 January 2007) has a C sample code. It's a very simple algorithm, but without ++ and += it can be very confusing. This
counts[i] += counts[ i - 1 ]; ++counts[ A[i] - min ];
would be
counts[i] ← counts[i] + counts[ i - 1 ]; counts[ A[i] - min ] ← counts[ A[i] - min ] + 1;
Does anyone favor increment, a ← a + 1 or inc(a) over a++? What about +=? DanielKO 14:00, 27 January 2007 (UTC)
- I think Wikipedia:WikiProject Computer science/Manual of style (computer science) and this page are expeted to diverse slowly. Each has their own demands that are slightly different. If you feel a change is needed in both, then make it to both. If not then make it on whichever seems appropriate.
- As to the algorithm keyword - see it as being akin to the procedure keyword, and thus, in some sense, distinguishable from the function keyword. Some might argue that that's a subtle point (though in practice it really isn't), but I think the real point is that the pseudocode guidelines are just that: guidlines; the aim is to provide flexibility and let people do what they want, but provide enough general stylistic consistency that things don't get too wildly divergent.
- As to notation for arrays lists and sets - I personally don't want to get too far into nailing down hard syntax. That was lies the problems of the Wikicode debate. I think most people, in general, are going to pick suitable nottion themselves. The real judging point is that whatever notation is chosen, it should be relatively clear, or makde clear, in the article in which it appears.
- I'm not a fan of increment operators for pseudocode. With pseudocode the aim shoul be clarity and no requirement for knowledge of any particular language - and increment operators are a language specfic feature. I think a great many users, particularly non-programmers who simply want to understand an algorithm, will find the slightly longer version that mkes the operation explicit far more clear than increment operator notation. Leland McInnes 17:13, 27 January 2007 (UTC)
- I'd add that increment operators and other side-effecting operators, while convenient, are notorious for introducing unexpected behavior into programs. Being explicit about where values are being assigned (i.e. the a ← a + 1 form) is probably a safer approach. --Allan McInnes (talk) 18:42, 27 January 2007 (UTC)
I've changed the page to recommend "a div b
" over "a ÷ b
", since — at least in the United States public school system — "÷" and "/" are both synonyms for "divided by". There's nothing inherently "integer" about the line-and-two-dots division symbol. On the other hand, "div
" is used to mean "integer division" in several real-world programming languages.
Of course, there's still the question of whether -1 div 2
is -1
or 0
, but that's a question better left unanswered; let the individual algorithm descriptions pick their own rounding modes if they find it necessary.
My two cents on increment operators: It's obvious to me that "a := a + 1
" is clearer than anything you could possibly dream up as a pseudosyntax for "increment". Even in C, you should prefer "blah[baz]->foo += 1;
" to "++blah[baz]->foo
", for clarity, and also to prevent confusion on the reader's part about whether the prefix or postfix operator binds tighter. (Yes, C programmers know which; but do Wikipedia readers?)
The left-arrow "←
" should never be used as a shorthand for assignment; it looks too much like a minus sign in Courier New, the most common font with which  tags will be displayed in a browser. Use the universally recognized (thanks to Wirth) assignment operator ":=
" instead. --Quuxplusone 03:01, 7 March 2007 (UTC)
New formatting tag[edit]
There is now a new tag available: <source>. It can cope with many languages right now, and can be extended if necessary to cover new ones. HTH HAND —Phil | Talk 09:16, 16 May 2007 (UTC)
- Very useful for Wikibooks, but I don't see any use for it on Wikipedia. (Unfortunatly some people will now start using it beacuse they can, not because it increases the quality of the articles.) —Ruud 11:14, 16 May 2007 (UTC)
It would be useful for scrapers, because it automatically tags the programming language; it could even be extended to automatically put articles in the proper subcat of Category:Articles with example code. So it would be cool if it worked. However, see Wikipedia talk:WikiProject Programming languages#New_formatting_tag for my short-list of problems with GeSHi. Hopefully they can be resolved, and <source> can replace  (or, better,  could be implemented according to improved <source> semantics, so we wouldn't have to change the wikitext of a billion articles).
The message I'd like people to take home: Don't use <source> on Wikipedia. (For experts only: Don't use <source> on Wikipedia yet.) --Quuxplusone 05:55, 18 May 2007 (UTC)
- I don't see why we shouldn't continue to use it while those problems are being fixed. — Omegatron 00:27, 10 August 2007 (UTC)
Sample good programming language articles[edit]
The three examples chosen could hardly be more different to each other in the way they treat syntax examples. Python (programming language) has barely any, and is a great, readable article for it. BASIC is a fine article up until the "Examples" section, which is largely a useless appendix for editors to show off their programming skills in. Objective Caml is built around its examples, and as such is mostly unreadable after its initial two sections. For now, we should highlight only Python here, and work on convincing editors that the more code an article contains the less useful it is to most people. Imagine if Wikipedia's article on various natural languages were built around large blocks of syntax examples. Chris Cunningham (not at work) - talk 12:53, 18 September 2008 (UTC)
 vs. ?[edit]
In a nutshell: Should sample code use syntax highlighting? My feeling is no. No programming web page that I come up with on a random sample run through Google uses it. I know most editors do (mine does), but lacking any sort of standardization within a language, we shouldn't be arbitrarily be deciding on rules that should be applied with a shotgun to every piece of code on the project. Any highlighting is going to be unreadable on some skins and/or browsers and allowing manipulation of the rules in the "my preferences" tab would add a huge load to the interface. - Richfife (talk) 11:49, 15 October 2009 (UTC)
- I don't really have a preference either way at this stage. On the one hand, syntax highlighting can make code much more readable. On the other hand, it can also (as you point out) degenerate into an unreadable mess depending on the skin or browser. I would like to at least see language keywords made bold, since that does tend to enhance readability and is fairly platform-agnostic. --Allan McInnes (talk) 23:24, 15 October 2009 (UTC)
- I strongly support code samples using syntax highlighting, and of having this document explicitly recommend it, so as to help avoid the kind of absolute nonsense we had to endure on the topic at C (programming language). I would require observed cases of your hypothetical downsides in order to give them any weight. —chaos5023 (talk) 21:25, 27 June 2011 (UTC)
- I also strongly support syntax highlighting. I have added instructions for use to the document, but not explicitly recommended it. InverseHypercube 21:37, 27 June 2011 (UTC)
High Level Pseudocode[edit]
The example format given in High Level Pseudocode,
- Inputs description of input arguments
- Output description of outputs
- (description of a step in the algorithm)
- (the next step in the algorithm)
- (substep)
- (etc.)
puts a lot of stuff in italics, but doesn't specify whether the italics is part of the format or not... I'm guessing not, but I'm not quite sure. Either way, it should probably be made explicit. --SamB (talk) 21:25, 8 April 2011 (UTC)
Wikipedia:Manual of Style/Computing[edit]
How about we add Wikipedia:Manual of Style/Computing to this draft? It is an essay that covers more generic areas of article writing. Fleet Command (talk) 06:25, 13 September 2011 (UTC)
- Computing ≠ Computer science. —Ruud 18:20, 13 September 2011 (UTC)
- I knew it. But I take that it is the polite form of "not a chance, unless Hell freezes over". Okay! Quick and painful; I got it. Fleet Command (talk) 18:54, 13 September 2011 (UTC)
- Sorry, didn't mean to offend you ;) I just don't think these's currently much in the Computing MOS that's useful for writing articles on CS. —Ruud 19:01, 13 September 2011 (UTC)
- No! Surely you did not offend; you did not even come a kilometer close to offending. You are cool. :) Cheers. Fleet Command (talk) 00:21, 14 September 2011 (UTC)


text:
Monthly Archives: May 2011
Pretty Palm Springs Wedding by Lacie Hansen
Happy Tuesday everyone! I hope you all had a fantastic Memorial Day! I had the pleasure of spending part of the weekend in Boston with the lovely KT and Chad of KT Merry Photography. Although we tried not to talk too much shop, they did mentioned that I should check out the work of Lacie Hansen. So I did. Needless to say I was immediately blown away by her imagery and am so excited to share her work with you on AC today! Here's a snippet from the photog herself…
From Lacie:
"Krystal + Christian are both in the architecture field + choose The Horizon Hotel for its amazing mid century feel. They later celebrated with their guests with yummy ice cream + tacos to end the night!"
This fab hotel setting along with Krystal's short dress, bird-cage veil and sweet billy ball bouquet give this wedding the coolest casual retro vibe, and the food trucks – so fun!
So pretty! A very special thanks to Lacie for giving me the go ahead to feature her beautiful work on AC today! Make sure to check out her blog for a peek at all of her gorgeous photography.
Photographer: Lacie Hansen Photography
Venue: The Horizon Hotel
Ice Cream Truck: Cool Haus
Dinner: Flying Pig Taco Truck
Joshua Tree E-Session by This Modern Romance
Happy Friday everyone! I hope you have something fun and relaxing planned for the long weekend ahead! I am SO excited to share today's engagement session with you. Shot by Stephanie + Isaac Williams, the fab husband and wife team behind This Modern Romance, this duo has easily become one of my favorites so it is truly an honor to have their work on Aisle Candy today!
Andrea + Eric shared their first kiss in Joshua Tree so it was only fitting to shoot their e-sesh there! From the gorgeous natural surroundings, to the adorable couple, bright red balloons, handmade bunting and killer wardrobe – this shoot is just a dream. Hope you like…
I love how Stephanie + Isaac used Polaroids! They offer such a cool retro vibe.
I am in LOVE with Andrea's boots – gotta find out where she got them!
Totally and utterly GORGEOUS!!! Thank you Stephanie and Isaac for sharing these fabulous images with us today! They have so much more incredible work on their blog, I highly suggest a visit asap.
Happy long weekend! Yay!
Vera Wang Trunk Show in NYC
I told you I was back in NYC! Last night I had the pleasure of attending a special blogger event at Vera Wang's Madison Avenue salon, which was nothing short of amazing. We sipped bellinis and indulged in the cutest mini red velvet cupcakes made by Ruth Drennan (seriously delicious). Vera's staff was so sweet. They gave us a tour of the salon, which was stunning and walked us through each gown in her newest collection (even more stunning). I've sprinkled a few of my favorites throughout this post, but I'd love to hear which one you'd die to wear…
All photos by Kevin Sturman via verawang.com
It's one thing seeing her dresses online or in photographs but to view them up close and get to touch them was just – well, words can't quite describe it. Each and every one of her gowns is meticulously crafted and constructed from the most amazing fabrics. Her collection includes a wide range of colors from ivory and blush tones to grey and even celedon. She has also included an array of adornments and sashes, so if your gown isn't just right, adding one of these pieces may be the special touch needed to complete your wedding look.
One thing I thought was interesting was that each collection has a letter attached to it (this season is G) and the gowns' names begin with this letter. Take a look back at her older collections. You'll see her 2010 gowns begin with E and 2011 with F. Never noticed that before right?
The sales consultants also stressed the importance of finding your Vera Wang gown 7-8 months before your wedding. It takes time to create such beautiful pieces ladies… so plan accordingly!
A very special thank you goes out to Vera and her amazing staff for including me in this wonderful event. I hope to visit again soon!
So you may have noticed I've been a bit slow with my posts lately. Life just gets crazy sometimes doesn't it? I've been swamped with a big move and another trip to NYC (which I'll be posting about very soon!) and didn't have quite enough time to finish my feature for today. So, instead of nothing… I've been saving this image for a while and thought today was the perfect day to share it. I hope it brings a smile to your face
Image via Pinterest
I LOVE him!
Ban.do Giveaway Winner!
Just selected a winner at random… congratulations to Jennifer S! You're the lucky lady who scored this sparkling hair accessory! Yay!

subset: commoncrawl


text:
low carbon
Welcome to the 'low carbon' tag page at Technorati. This page features content from the farthest reaches of the Blogosphere that authors have "tagged" with 'low carbon'.
Are you an expert about 'low carbon'? Do you want to be the Technorati authority on 'low carbon'? You can write a description that will appear right here: Join Blogcritics!
Original Technorati articles tagged "low carbon"
in Technology50 Technologies That Will Change the World
A new report reveals over 50 innovations that will drive society in the next 20 years.by cmimanagers / on Nov 23, 2012
Latest blogosphere posts tagged "low carbon"
Mid-term review of "Tokyo Strategy 2012 for Mekong-Japan Cooperation"
— Authority:
Leaders of Japan, Cambodia , Laos , Myanmar , Vietnam and Thailand met in Tokyo on December 14 for the Fifth Mekong-Japan Summit back to back the ASEAN-Japan Commemorative Summit Meeting. The Leaders conducted a mid-term review of the progress to date of Mekong-Japan cooperation based on "Tokyo Strategy 2012 for ...1 week ago -
Energy Secretary Announces $150 MM Clean Energy Manufacturing Tax Credit Awards
— Authority:
Moneys tight in Washington D.C. amid sequestration and ongoing federal budget battles, but the Obama Administration is maintaining its commitment to helping forge a U.S. renewable and clean energy manufacturing base. Energy Secretary Moniz on Dec. 12 announced $150 million in Phase II, 48C Clean Energy Manufacturing ...1 week ago -
Corruption has left our country among the poorest
— Authority:
DEAR EDITOR, The impending economic and political crisis in Guyana is not an accident; it was caused by an out of control and corrupt, political Stalinist oligarchy that controls the ruling party . Since November 2011, the failure of the minority PPP regime to accept that they continue to bleed politically ...1 week ago -
New Paper Offers Sweeping Plan to Decarbonize the Global Economy
CleanTechies Blog - CleanTechies.com — Authority: 433
Eighteen prominent international climate scientists and economists have authored a paper that seeks to answer the most vexing environmental question facing the planet: How to reverse soaring carbon dioxide emissions and prevent the world from experiencing destabilizing climate change. Their answer, presented in ...2 weeks ago -
Nick Clegg says UK can lead the way in electric cars
— Authority:
Deputy Prime Minister, Nick Clegg, says Britain can become the global centre of electric cars, encouraging motoring firms and consumers to continue to buy into the technology. The Government has recently put aside £500m investment for the ultra-low carbon car market from 2015-2020, in the hope of reducing carbon ...3 weeks ago -
UK Government Makes £90,000 Porsche Eligible for a Low-Carbon Grant
— Authority:
How would you feel if your tax dollars were going to fund a £5,000 discount on a Porsche for the wealthy? UK citizens will now be able to receive a break on their £89,900 Panamera S E-Hybrid thanks to decision by the Department for Transport . The subsidy, which was introduced in 2011 and designed to give ...3 weeks ago -
£90,000 Porsche gets low-carbon government grant
— Authority:
Porsches hybrid Panamera S with electric motor and petrol engine will get £5,000 off the pricetag, thanks to a public subsidy . . . → Read More: £90,000 Porsche gets low-carbon government grant3 weeks ago -
Get Climate Ready: Moving Towards Low Energy and Low Carbon Buildings
— Authority:
On Tuesday 5 November, The Institution of Engineering and Technology (IET) held an Oxfordshire Network Event at Oxford Brookes University, which reviewed the need for buildings to become low energy, low carbon and climate ready. The IET is a world leading professional organisation which shares knowledge to promote ...3 weeks ago -
Oil, the North Sea and Scottish independence: North Sea Investment
— Authority:
This is the fifth in a series of researched articles on the oil and gas industry, the situation in the North Sea and the relation of this overall picture to a potentially independent Scotland. We are publishing these as a series because oil is one of the most important, complex, contentious – and fascinating – ...3 weeks ago -
David Cameron gets his beans
— Authority:
The other day I blogged about David Cameron and his decision to get rid of all the "green crap". James Delingpole excoriates David Cameron for his own green crap. So how exactly does Cameron's alleged desire to cut the green crap square with his government's actual policies? Not very well, as David Rose has ...4 weeks ago -
Mexico to Follow Carbon Tax with Region's First Carbon Offset Market
— Authority:
Launched by Bolsa Mexicana de Valores and wholesale financial markets broker SIF ICAP, the MEXICO2 platform seeks to promote and foster private and public sector investment and collaboration in climate change mitigation initiatives that reduce carbon and greenhouse gas emissions, including renewable energy, energy ...4 weeks ago -
Producer Spotlight: New Leaf Biofuel
— Authority:
Driving with Propel biodiesel in Southern California? Here's a look at the amazing people & process behind your favorite fuel. New Leaf Biofuel based out of San Diego California has been producing high quality biodiesel with pride and purpose since 2005. Started … Continue reading →4 weeks ago


text:
Skip to content
and found 2 items
1690cc, bhp, 112mph, Insurance group 15
The Slim is essentially a standard Softail (ie a big twin with hidden rear shocks for that 'hardtail' look) but given (as seems to be repeatedly fashionable with cruisers from all manufacturers at the moment) the minimalist, '50s 'bobber'/hot rod look. The difference here, though, is the 'Slim' bit. Harley's view was that its existing Softails had become ever bigger ...
1199cc, 109bhp, mph, Insurance group 15
There was a time when Yamaha's Tenere range of bikes ruled the earth, literally. As desert and dirt blasters for Paris-Dakar like competitions, the name Tenere became synonymous with adventure and off-road riding. Then it all went quiet and BMW took on the mantle of Adventure bike champions with its modern-day GS range.Yamaha's revival started with the 2008 XT660Z Tenere, ...
Save money by comparing quotes. It's quick and easy
Compare and buy 100s of bargain priced products for you and your bike


text:
Video recording from Professor Sasha Nikolaev's presentation
The video recording from Prof. Nikolaev's presentation on "The Story of Writing"...
Graduate Student in French,
Teaching Fellow in French
BLA, Universite De Montreal, Canada
MLA, University of Guelph, Canada
MA, Boston University
Sophia received her French Baccalauréat from College Marie de France in Montréal, Canada. She went on to receive a Bachelor of Landscape Architecture from the Université de Montréal in Québec and a Masters of Landscape Architecture from the University of Guelph in Ontario. Her Masters thesis focused on the historical underpinnings of design theory as a way to explore how landscapes express cultural attitudes towards nature and human beings.
Sophia is currently completing her Masters of French Literature at Boston University. Her research interests include the portrayal of the Parisian landscape, gender studies, and cultural identity in 19th century French novels. In 2011, she served as an instructor in a French language immersion program in the Loire Valley in France.


text:
Ranked #1 in 7 out of the 10 evaluated specialties by U.S. News
MyPatients provides referring primary care providers with secure access to their patients' information.
Boston Children's has launched the world's 1st program dedicated to offering hand transplants to children who qualify.
First-of-its-kind international contest takes first steps toward establishing "best practices" for using genomic sequencing
Read the most recent article from Boston Children's Medical Editor Dr. Claire McCarthy
Support the hospital with a donation that helps kids get the care they need.
Contact: 617-919-2275
Fax: 617-919-4266
Sleep Disorders
Medical School
Albert Einstein College of Medicine, 1978
Bronx, NY
Boston Children's Hospital, 1982-1985
Boston, MA
The University Hospital, 1978-1979
Longwood Area Neurological Training Program, 1979-1982
If this is a medical emergency, please dial 9-1-1. This form should not be used in an emergency.
The future of pediatrics will be forged by thinking differently, breaking paradigms and joining together in a shared vision of tackling the toughest challenges before us."