Wikipedia talk:WikiProject Computer science

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated Project-class)
WikiProject icon This page is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Project  This page does not require a rating on the project's quality scale.

Too Many Experts Spoil the Wiki[edit]

I have virtually given up on Wikipedia as a useful source of information with respect to Math or Science, and especially computer science. There was a time in the past when I would refer my children to WP for more information regarding physics, computing topics, etc. And in the past, they were able to learn something. No so anymore. Recently (over the past few years), articles are being rewritten by so-called subject matter experts, seemingly without regard to the audience.

The vast majority of readers who want to learn about networks and for example, graph theory, have no formal education or background in the field. It would be nice if the hyper-technical terms were kept to a minimum, and examples would be geared less toward the scientist, and more toward an average reader who just want to get a feel for the subject matter.

I am an experienced computer scientist, and I find the discussions regarding almost every single topic, whether it be number theory or architecture, confusing and frustrating to read. This should not be the case. I fear that most would-be contributors of late would rather see themselves appear "smart" on the page, rather than impart wisdom and accurate information. It's as though the "keep it simple" concept has been abandoned for the sake of ego.

There needs to be a movement from within WP to simplify ALL articles, and to ensure that readability and comprehensibility is enhanced for the average reader, which would probably be a 9th grade level reader (in the US). If this isn't done, and done soon, I fear that once was good and useful will be lost forever.

Wikipedia is very good at biographical topics. That's pretty much all I use it for now. It should be more like an encyclopedia used to be... A place where anyone could go to learn something on just about any topic. To the extent that it fails at that goal, it will become increasing irrelevant and unusable. Therefore, you would-be "expert" contributors need to ask yourself if it's really important to cram in a "big word", where 2 or 3 smaller ones would suffice. Most of the tech articles now read about as well as a poorly developed college textbook. And that is in no way a Good Thing.

Good feedback. I also have trouble learning new algorithms from their wiki pages, but we must work within WP:NOTGUIDE where we inform rather than instruct. Many topics just cannot be succinctly explained without reference to established knowledge, which requires "hyper-technical" terms. Can you provide an example of where this becomes intellectual showboating? Can you give an example (or create one yourself) of a good computer science article? Andrew Helwer (talk) — Preceding undated comment added 21:01, 9 February 2015 (UTC)

While Wikipedia:About says it is a source for everyone...
  • Is this project the right scope for a rehaul of the entire wikipedia?
  • What level of Flesch–Kincaid_readability_tests are you proposing for being required for reading comprehension?
  • How do you propose to track or identify these articles which are too high level or specific?
  • Can compromise be found in by other experts or teachers adding in summaries at the top without violating Wikipedia rules?

IamM1rv (talk) 17:16, 4 March 2015 (UTC)

Pseudocode Use[edit]

I am of the opinion that pseudocode examples are superior to actual-language code when it comes to demonstrating how an algorithm works for an encyclopedia.

  • Hopefully, the pseudocode is written so that people familiar with a wider range of languages are able to understand it.
  • Pseudocode avoids it being necessary to know one particular language.
  • Pseudocode is free from the quirks of individual languages. For example, a well-written program in C would free all of the memory that it allocates, which is an issue that is not important for demonstrating how an algorithm works. Also, C, for example, lets people say things like if (!thing) to test if thing is null, but for someone unfamiliar with C, this may be confusing. If thing is a FILE, for instance, it makes no sense to take its logical inversion.
  • Using pseudocode means that there does not need to be multiple implementations in numerous languages in an article. Having multiple implementations of the same thing does not add anything to the wiki.

I found some time ago that the page on binary search trees uses many code examples in C++ and Python. This is great for anyone who knows C++ and Python, but if someone unfamiliar with either language wanted to know how to, say, insert an item into a BST, it might be difficult for them to find that information on Wikipedia. To facilitate the transfer of knowledge, I suggest that there be an emphasis on the use of pseudocode rather than actual code.

I have rewritten the examples from the BST page in some form of pseudocode at User:Hwalter42/draft article on binary search tree. I have not at all tried integrating the result with the prose in the article, and do not want to replace the current BST article with this one. But I do want to feedback on the quality/style of the pseudocode, and, of course, its correctness. (I am an enthusiast, not an expert. Also, I am convinced that my delete function is wrong, but my brain is too turned off right now to figure out how to fix it.) More importantly, I also want to know if the use of pseudocode everywhere is something that people support or if the idea should be dropped now. Perhaps there is some substantial upside to using real languages that I am missing?

hwalter42 (talk) 22:40, 20 February 2015 (UTC)

I support this kind of thing in general. I'd suggest not using := vs. =, though; maybe := vs. == to help avoid ambiguity. ErikHaugen (talk | contribs) 23:08, 20 February 2015 (UTC)
The consensus has always been that pseudocode is preferred in articles on algorithms (see MOS:ALGO). Actual code is really only necessary in articles on specific programming languages or articles that discuss programming languages contructs and a very precise semantics is required. —Ruud 23:24, 20 February 2015 (UTC)
I agree pseudocode benefits articles by removing multiple implementations. However, there is no way of verifying psuedocode implementations are correct, either through unit testing or more formal methods (admittedly these standards aren't imposed on implementations in programming languages). We could use only pseudocode published in well-known papers, but those are notorious for technical errors - and what is pseudocode but a technical expression of a concept? Still, pseudocode copied from a published & cited paper is much, much more reliable and traceable than some implementation by a drive-by editor. Known errors with the pseudocode are often mentioned in subsequent papers, and so can be fixed. If it's just you implementing an algorithm in pseudocode rather than a programming language though, that seems worse than having a programming language implementation. Andrew Helwer (talk) 23:36, 20 February 2015 (UTC)
"seems worse"–It seems better to me, especially if the reader isn't familiar with the syntax of the language. I'm not sure I am understanding your point – most of Wikipedia's content is written by "drive-by editor[s]", and we seem to manage; why are code samples any different? Can you think of an example that would illustrate this concern? Also I'm not sure we can copy pseudocode from papers, most of the time, due to legal issues. ErikHaugen (talk | contribs) 00:04, 21 February 2015 (UTC)
Let's look at a notoriously complicated algorithm: Boyer-Moore string search. I have a bunch of unit tests for the article's Python implementation here, and still some bugs get through. A pseudocode implementation wouldn't have the tiniest chance of being bug-free unless it were copied from a published source (and even then, no guarantees) I don't know anything about the legal issues of copying pseudocode. I'm not sure I understand your second question. What do you mean by "this concern"? Andrew Helwer (talk) 00:41, 21 February 2015 (UTC)
If I may shout down from my ivory tower: pseudocode is perfectly amenable to a formal correctness proof—even much more so than a real implemenation—and such a presentation (pseudocode combined with a correctness proof) is the going standard in the scholarly literature. Assuming the bug in your code was not due to a basic failure in your understanding of the algorithm, it was likely caused (or managed to escape your attention) by the increase of complexity in the real implemenation as compared to pseudocode: pseudocode has a much greater chance of being correct and correctly understood than a real implemenation.
There's also the more pragmatic advantage that an n line psuedocode implementation will be read be a greater number of people than a 5n line implementation in programming language X, which would make it more likely that any mistakes get spotted and corrected.
(Your anecdote of course also nicely demonstrates why unit testing is fairly useless when it comes to demonstrating the correctness of your core algorithms and data structures: a limited number of hand-written testcases will almost surely miss some of the cornercases. With a formal proof, or at least some form of property-based testing, you are much more likely to cover those.) —Ruud 02:14, 21 February 2015 (UTC)
To be clear, I definitely don't believe unit tests are sufficient to ensure correctness. When you say formal correctness proof, do you mean the formal computer-checked way or the proofs-should-compel-belief non-formal way you see in papers? Because I've definitely read papers which have a proof of correctness but where the pseudocode is incorrect as exposed by a basic test. Example, a very useful and insightful algorithm, proved correct, but pseudocode that is just dead wrong. I feel I'm derailing this thread though. I concede you can get pseudocode correct enough that anyone writing code based on it will find & fix the bugs themselves. Plus, it's just plain easier to read than actual code. Andrew Helwer (talk) 03:02, 21 February 2015 (UTC)
Unit tests may not be sufficient, but they certainly help avoid many mistakes. I also believe that pseudocode is generally better than code for our purposes, but algorithms such as the ones discussed above that are too complex to have much hope of implementing correctly without testing may be an exception. —David Eppstein (talk) 03:26, 21 February 2015 (UTC)
Thank you for the feedback. I'm glad that the idea is supported, but I don't believe that I am the one who should be writing any pseudocode for most anything, as I don't see myself as qualified (again, I am not confident in the code I wrote for even BST's, which should be fairly simple). As sort of a side note, to address the :=, =, and == thing, I understand your point and am willing to change my own style; however, it shows an issue as to what style of pseudocode should be used. Preferably, it would be consistent across pages, but there is plenty of room for personal style considering as this is, by definition, not a strict language. I saw at the link given above that standardization has already been proposed but abandoned though. hwalter42 (talk) 03:40, 21 February 2015 (UTC)
Both forms, although informal proofs will of course make up the vast majority of correctness arguments you'll find. Nonetheless, they are often sufficently detailed that you should in principle be able to extract some more formal, or even computer-checkable proof, from them in for example Hoare logic. Any steps that require insight, such as comming up with loop invariants, should be derivable from the more informal proof.
Note that I'm not advocating including any formal correntess proofs in our articles, although I do think we can do a bit better on including informal/intuitive correctness arguments in our articles. Such arguments also help readers understand why a particular algorithm works, as merely opposed to how by giving the code. —Ruud 11:07, 21 February 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Pseudocode (in whatever flavor) is just another programming language – without compiler. Well-written C code should be the norm since it has been around since 1843 and likely will be around 2043. Besides, it is punishable by federal law in large parts of the world not to know it/being in the process of learning it for a student of computer science. As has been pointed out, pseudocode is an extra invitation to bugs. (There are enough of those in code that compiles.) Besides, not everybody knows pseudocode (whatever that is, definition please). YohanN7 (talk) 13:53, 7 April 2015 (UTC)

It is true that pseudocode lacks a compiler or any formal semantics. However, its expressive power does not suffer for it; English is not a formal language, after all. It is difficult to say whether there would be greater or fewer bugs in a C program compared to its pseudocode equivalent. For C we can check that it compiles and passes static analysis and unit tests, but bug-free C code is nearly unachievable (unless you're DJB or something). Let us consider: who is the audience for code in Wikipedia articles? I submit it is people who are trying to learn an algorithm. In my experience as a person trying to learn an algorithm, translating pseudocode to working implementation is where all the magic happens. Pseudocode correctness is just a nice-to-have, which could be accomplished through a high-level specification language such as PlusCal. Achieving consensus on use of a high-level specification language sounds like a lot of work, but if anyone is interested please start another topic and I will support it. Andrew Helwer (talk) 20:54, 7 April 2015 (UTC)
It really shouldn't matter what language an algorithm is written in unless it is being hidden say in object code nor provided. C and C++ are commonly known. C is close to a C++ subset. A few things are different. I have programed in many languages. Some are vary different. But on the other hand most algorithms are procedural.
I think we should try and be consistent what ever code is used.
Just for the record pseudo code has been used to describe directives and the inclusion of macros in some programing languages and assemblers. The "org" assembly directive is a pseudo instruction to the assembmer. Old terminology I know. But there are historical topics here.
I used the term pseudocode to describe instructions of a pseudo machine. A made up computer instruction set. It is part of a metacompiler. The compiler translates the source language into pseudocode, pseudo instructions. The pseudo instructions might be defined to best implement the language being compiled or generalized for translation to a wide range of real inctructions. pseudo instructions were much like an assembly macro that procedurally generated real machine code.
Things change. What I once called pseudo code is now something quite different. Another 10 years who knows. I just recently started editing. It is hard to explain, in writing, some concepts. I think linking terms to their topic is sometimes the best way to explain a subjects. The needed knowledge is found following those links. To bad we can not easly create flow charts for algorithms.
Oh wait we shouldn't ignore thar there is an international standard language for describing algorithms. It's called ALGOL. ALGOL has a publication form for communicating algorithms.
Steamerandy (talk) 07:57, 8 May 2015 (UTC)

Pseudocode copyright concerns[edit]

Branching discussion from above to the legal issue of using pseudocode from papers and textbooks. Anyone have ideas on this? I've been using pseudocode from this paper on the CRDT article. Andrew Helwer (talk) 04:17, 21 February 2015 (UTC)

Remember that it's not the algorithm that can be copyrighted (patented maybe, but that's a different discussion), but only it's expression. Various syntactic modifications you make to the pseudocode in order to integrate it with the article are thus likely to invalidate any copyrights. If this is not possible for some reason, the code is critical to the article and you explicily attribute the code to a the paper, then this would likely be fair use. —Ruud 10:46, 21 February 2015 (UTC)

Is there a page here for PARTITION[ING] INTO TRIANGLES?[edit]

It's one of the classic NP-complete problems. (talk) 07:09, 4 March 2015 (UTC)

3-dimensional matching, maybe? —David Eppstein (talk) 07:46, 4 March 2015 (UTC)
Two NP-complete possibilities I know of: graph partitioning of suitable graphs into triangles is NP-complete, e.g. [1], and minimum-weight triangulations. --Mark viking (talk) 11:24, 4 March 2015 (UTC)

Request for feedback on Talk:Zachman Framework#Lead sentence[edit]

The lead sentence Zachman Framework has been recently changed from

The Zachman Framework is an enterprise architecture framework...


The Zachman Framework is an enterprise ontology...

Which has been questioned at Talk:Zachman Framework#Lead sentence. I would be grateful if any of you could take a look, and comment on this topic. -- Mdd (talk) 15:39, 13 March 2015 (UTC)

Yes check.svg Done resolved by Kku, thank you. -- Mdd (talk) 12:03, 25 March 2015 (UTC)

Invention of BASIC[edit]

There is a discussion concerning who developed the BASIC programming language at Talk:BASIC#Sister Keller. --Guy Macon (talk) 19:31, 14 March 2015 (UTC)

Soft goal - cite[edit]

"Non-functional requirements (or quality attributes, qualities, or more colloquially "-ilities") are global qualities of a software system, such as flexibility, maintainability, usability, and so forth. Such requirements are usually stated only informally; and they are often controversial (i.e. management wants a secure system but staff desires user-friendliness). They are also often difficult to validate." is not cited! ( — Preceding unsigned comment added by (talk) 12:35, 24 March 2015 (UTC)

NooJ - linguistic development environment software[edit]

Hello folks. Draft:NooJ, about "linguistic development environment software as well as a corpus processor" has been submitted at Articles for Creation, and declined twice for its notability not being clear. The Draft's author has put a lot of work into expanding and improving the references, so it seems a pity to leave this Draft in limbo. Please could you offer any advice on whether this topic meets notability requirements. Arthur goes shopping (talk) 07:18, 2 April 2015 (UTC)

@Arthur goes shopping: Not exactly my area of expertise, but searching for this on Google Scholar [2] reveals some, although not an overwhelming number, of citations of the manual by scientists other than the developer. It might just pass AfD, the topic/content seems quite uncontroversial and the article a bit technical but otherwise not too badly written, so I would probably give it the benefit of the doubt. —Ruud 14:01, 2 April 2015 (UTC)
Thank you, I have now accepted the article and moved it to NooJ as a Start class Computer science article. We shall see what happens to it next. Arthur goes shopping (talk) 08:59, 3 April 2015 (UTC)


Could we have more info on this subject of virtual reality — Preceding unsigned comment added by MINECRAFT1103 (talkcontribs) 12:37, 7 April 2015 (UTC)

Request for comment on move[edit]

We're discussing moving Model 1 over here, and I'd like some input from this project on the proper new name of the article. Faceless Enemy (talk) 01:18, 14 April 2015 (UTC)

Quote_notation: overly optimistic[edit]

The article on "Quote_notation", although sort of interesting, is overly optimistic on the usefulness of this notation for general computation with fractions. There is an obvious problem that the length of a quote notated fraction is linear in its denominator, often even close to it.

This optimism is already there in the original article.

For example, the suggestion is that subtraction of two quote notated number is "just subtract". Here a bad counterexample: To subtract 1/19 from 1/17 (giving 2/323), you compute 2941176470588235'3 - 894736842105263159'9, and after subtraction you get a number with a repeating part of 144 digits, ending in ...4334365325077'4

This is not easy by any stretch of the imagination. However, the notation is still an interesting thought experiment, so I would suggest not to remove it, but just make it a bit more realistic.

"Software rot" page is a mess and should be rewritten[edit]

I think this is a relevant and frequently used concept, but this article totally misses the point by mixing performance and maintainability problems. Also the article lacks verifiability (no references for lots of statements). I think the best thing would be to delete and rewrite it. But I'm new here and I'm not sure if I can just do it or should I wait for other opinions? Any recommendation on how to proceed would be welcome! Realvizu (talk) 11:07, 28 April 2015 (UTC)

Nomination of Abdisalam Issa-Salwe for deletion[edit]

A discussion is taking place as to whether the article Abdisalam Issa-Salwe is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/Abdisalam Issa-Salwe until a consensus is reached, and anyone is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article. Cordless Larry (talk) 21:20, 2 May 2015 (UTC)