

Hey CS Paper writers, please show your code - octopus
http://jacquesmattheij.com/Hey+CS+Paper+writers+please+show+your+code

======
socratic
Unfortunately, Jacques needs to answer a pretty basic question in order to get
his wish: why? Why should CS paper writers show Jacques (or anyone else) their
code?

We have discussed this topic on HN a number of times, for example:

<http://news.ycombinator.com/item?id=2735537>
<http://news.ycombinator.com/item?id=2006749>

Many of the comments in those threads do a better job summing up than I ever
could. However, briefly, literally all of the incentives are aligned against
publishing code and data.

If a writer's code is wrong, they are embarrassed (and there is no culture of
being embarrassed by not publishing code).

If a writer publishes their code and it is actually good, someone else can
scoop their follow-on results.

If a writer does not publish their code, and it is actually any good, they can
potentially commercialize it thanks to the Bayh-Dole Act.

If a writer publishes their code and people intend to use it, the writer needs
to clean it up, check it for correctness, and handle support requests. These
activities are probably more time consuming than writing the code in the first
place.

If the writer publishes their code, and other people in the writer's field do
not, the writer is usually at a disadvantage. Others will appear to have more
publications, the basic currency of academia. (Many people have great reasons
for not publishing their code or data, especially researchers embedded at
large companies making changes to large proprietary systems.)

So overall, yes, it would be great if CS paper writers gave out their code.
What they are doing is not reproducible science in the philosophy of science
sense.

But what is Jacques (or anyone else) doing to fix this system of incentives,
and what could anyone do?

~~~
skrebbel
In science, there are still such things are "good manners" and "common
scientific practices", not all of which are directly incentivised. For
example, every article contains references to other articles that helped
create it. Every article credits all authors, usually in a particular order
(which differs culturally per discipline). They're all fairly common sense,
and there are many more. Some are listed explicitly as rules for journal or
conference submissions. Some, however, are considered too obvious for that.

These are rules everyone follows. People get frowned upon when they are not
followed.

Unfortunately, when these rules came to be, there wasn't that much code
around. You can't print out your physics experiment setup. Additionally, every
additional piece of info, be it data, code, or whatever, would need to be
printed and shipped. This cost too much, which encouraged a culture in which
only the most important parts, findings and a brief story of how they were
obtained, were to be included in publications.

But then the internet came. The whole world adapted, but science culture
didn't. The internet allows large sets of information to be shipped along with
papers. This does not just hold for computer science. Entire data sets of
physics experiments could be included. Survey data, code, Matlab models, and
so on.

All this data is collected using tax payers' money, done for the greater good
of the world. It makes perfect sense to include it all with the publication,
online. In fact, it is criminally wasteful to make different teams collect the
same data, or do the same work, over and over again.

I think the only change necessary to make this happen is for a few influential
publications and conferences to require that all data, code, etc is published
online along with the paper. It can start in a niche subject area and expand
from there.

What Jacques (or anyone else) is doing to fix this system is yelling on the
internet about it, so that conference programme committees and journal
reviewers may at some point be swayed to add this little rule.

A rule that makes sense, just like "your paper must contain an abstract" makes
sense, just like "you must include references to all works you borrowed from
or built upon" makes sense.

~~~
Hyena
He's not actually saying they lack incentive so much as that there are
significant disincentives. The rest of sience contains an incentive, various
types of professional censure, for the behavior you describe. CS does not and
in fact contains significant ince tives for secrecy.

------
xyzzyz
I _really_ don't think that it's easier to understand algorithm by reading its
implementation than by reading its description. It's actually opposite --
frequently the idea behind algorithm is really hard to decipher if you only
have access to code and not words. If you don't believe me, take an algorithm
you don't know, read sample implementation (there are quite a lot on the
internet these days) and try to _understand_ how it works. I suggest trying
KMP and Boyer-Moore for text matching, or Miller-Rabin and AKS for primality
testing, or even RSA -- RSA is terribly simple in theory, but if you don't
have a clue how it's supposed to achieve its goal, and you don't have
background in number theory, then your chances of understanding it just by
reading the code are infinitesimal.

~~~
chime
Why can't we have all three when relevant? Description + formulas + code? I
understand why some algorithms (AKS, RSA) would not make sense if you just
spit out the C code raw but I think it would make the paper much easier to
understand if there was some code to go along with the formulas and
descriptions, especially if the description is hard to decipher like "analyze
the performance of the differencing algorithm on random instances by mapping
it to a nonlinear rate equation."

~~~
xyzzyz
In most (if not all) papers I read there was already pseudocode, which is
actually better than real programming language, because it lets you express
your algorithm in a concise way without all the real world overhead, like
initialization, allocation, etc. If you cannot implement algorithm yourself by
reading its description and pseudocode, it means that either you don't fully
understand what you just read, or your programming skills need some polishing,
and you should be rather reading textbooks than research papers for a while.

Also keep in mind that papers are written for the colleagues in the field to
read, and not for the laymen, so it's no surprise that authors use the
terminology familiar to people in the field. It makes no sense to write
research papers with laymen in mind, because 99.999% of them don't care and
the remaining 0.001% will learn terminology soon enough.

Also, you really should not expect that reading research papers will be as
easy as reading newspapers, don't you agree?

~~~
KaeseEs
Oftentimes, it is easy to overlook whether that real-world overhead affects
the asymptotic performance of your algorithm in either an ideal sense or a
pragmatic one. If memory allocation were free or memory were infinite, true
constant time rather than amortized constant time push back on dynamic
arays/vectors would be possible, etc.

Also, initialization often affects correctness, so it's much less frequently
skipped even in pseudocode for an algorithm.

------
bigiain
"Generally, academic software is stapled together on a tight deadline; an
expert user has to coerce it into running; and it's not pretty code. Academic
code is about "proof of concept." These rough edges make academics reluctant
to release their software. But, that doesn't mean they shouldn't. "

From:

<http://matt.might.net/articles/crapl/>

------
cperciva
Who says that we actually _have_ code? I think it took most of a decade before
anyone implemented the algorithm from my first paper.

~~~
alnayyir
>before anyone implemented the algorithm from my first paper

Link to both please? I am lazy and incapable of basic Googling. I sit in
shame, but also hope that you will fulfill my request.

A beer awaits you in SF regardless!

~~~
blaenk
His username lent itself to searching, so I doubt he'll mind me posting:
<http://www.daemonology.net/papers/>

~~~
alnayyir
First paper was pi-related.

The bsdiff stuff looks interesting (to me) though.

~~~
cperciva
I meant my first published paper: <http://www.daemonology.net/papers/fft.pdf>

------
ggchappell
I agree with the writer, in many ways. But it's going to be a huge uphill
battle.

I'm on the other side of this, too, as a researcher in algorithms. Earlier
this year, I submitted the first paper I've ever written, in which I would
consider some related code to be an essential part of my research. Now,
consider what this means.

\- I had some spend a _lot_ of time getting the code into shape.
Documentation, general clean-up, etc. This was time I could have spent writing
other papers. Publication output is a huge determining factor in academic
tenure & promotion decisions. Seriously, the way things are now, you're asking
people to risk not getting tenure, in order that you might have their code.

\- The idea of a published paper, is a _permanent_ record of the research.
Repositories for code that are of a similar permanent nature, are few & far
between. Some journals are starting to allow arbitrary attachments to papers,
which can them be obtained online. I submitted my paper -- along with the code
-- to such a journal. But this greatly restricted the list of journals I could
submit to. And it pretty much left out all of the truly prestigious ones.
Again, a problem.

------
phzbOx
Not to be harsh, but the code I've seen taken from "scientific" papers were
the worst code I've ever seen. One function of a couple of thousand lines in
C++ (But using a mix of C and C++ functions) using variables named with 1 or 2
letters.. without comments, gasp.. I still do nightmare about that (I had to
refactor that code.)

 _But_ I do agree with Jacques that I so much prefer a graph with a summary
than a couple pages of unreadable mathematical expression. A high-level
pseudocode of the general idea might also be great. Sometime, I feel like the
paper wasn't written for people to understand.. but as a way to make it seem
difficult. It's not rare that I talk with an author of a scientific paper and
can easily summarize an entire paragraph with a couple of simple sentences..

~~~
xyzzyz
_Of course_ it wasn't written for people to understand -- it was written for
their colleagues in their field, and _all_ they care about are these pages
unreadable mathematical expressions.

 _It's not rare that I talk with an author of a scientific paper and can
easily summarize an entire paragraph with a couple of simple sentences.._

And when I talk about math with my friends over a lunch, much, much more
information can be conveyed than by spending the same amount of time on
reading papers. However, it does not prove that papers are written in
unintelligible way, only that human-to-human communication is much more
effective than paper-to-human.

------
robryan
I would be interested to see more CS research happen in a more open source
like way, like how we see projects work on github where it is easy for anyone
with an interest in an area to get involved, run the code and contribute.

Obviously this wouldn't be possible in all branches of CS research and there
is the danger that these kind of projects would get stuck local maximas
without a few minds driving the research and the ability to understand it well
enough to make large scale changes.

Still a lot of good could probably come out of it, plenty of smart CS minds
that while they don't have time to commit to the reading and work required to
drive their own research project have the expertise to contribute to small
parts of other peoples.

~~~
xyzzyz
That's funny, because, you see, actual research really works like this.
Instead of Github you've got journals, and seminars on universities. The smart
minds contributing small parts to other people's research are graduate
students.

The thing is, actually contributing in the cutting-edge research is _much_
harder than helping FOSS projects. Most researchers I know think of their
problems day and night, while to be helpful in community software projects
it's enough to spend few hours on weekends.

------
cpearce
This won't fly in the real world. If an academic writer includes a link to
their code in their paper, when it goes through peer review before being
published, it will no longer under be a blind review; the reviewer will know
who wrote the code by virtue of the github account or domain it's uploaded to.
Blind reviews are important, as if you know you're reviewing a paper by
someone who rejected your paper, you're more inclined to reject it. That
really happens, people are that petty.

Additionally there's the risk that the reviewer will reject the paper, and
download the code and publish a paper about it quickly in some other
journal/conference.

~~~
xyzzyz
Your counterpoints are irrelevant. You can obviously attach code to the
article, so that there's no need to include any link or other similar thing.
If a reviewer wants to do the thing you described, the actual possession of
the code is not a big help for him -- what actually keeps him from doing that
is honesty, decency and the respect he has among his colleagues he would
instantenously lose.

------
j2labs
I would like more code simply to prove the things described in the papers. The
exploration just feels incomplete to me if I can't run some code and hack on
it to test how it changes behavior.

------
petercooper
I read a lot of CS papers and am not particularly strong on formal math (that
is, I have a lot of gaps) but I'd rather _not_ have actual code to demonstrate
concepts. Instead, I prefer it when they use pseudocode because it forces them
to boil their implementation down to the simplest parts possible than cut and
paste code into a paper.

------
chime
I'd be happy with just pseudo-code.

------
baddox
It seems to me like most CS research projects wouldn't necessarily have much
code behind them. Obviously, data structures and algorithms could, but
implementations are generally trivial once you've got the academic paper.

------
NY_Entrepreneur
Sorry. A peer-reviewed research paper in computer science is supposed to be an
original contribution to knowledge meeting the usual criteria of new, correct,
and significant.

Okay, how do we present knowledge? Text? Yes. Text with math as in, say, a
book on math or mathematical physics? Yes. Code? Nope! Sorry 'bout that!

Yes, coming from the programming side, many programmers have accepted that
code, especially with mnemonic identifers, actually is meaningful and a
substitute for good text possibly with good math. Sorry, guys: In principle,
it just ain't. In simple terms, the code is meaningless; code with mnemonic
identifer names and careful indenting is still meaningless and at best a
puzzle problem to solve to identify the intended meaning. Sorry 'bout that.
Yes, often in practice, with enough context from outside the code, can get by
with just mnemonic names and pretty printing. Still, it's just ain't
knowledge.

Really, for being knowledge, the code should be like the math in, say, a
physics text, that is, surrounded by text. The math does not, Not, NOT stand
alone and by itself is just meaningless. E.g.. F = ma is no more meaningful
than a = bc. For either equation, the meaning has to come from surrounding
text where the equation becomes just a nice abbreviation for what is in the
text. So, for code, the comments play the role of text in a physics book and
the code plays the role of the math in a physics book. As in a physics book,
the text (comments) are MORE important than the math (code). Again, code just
AIN'T knowledge. Sorry guys.

~~~
sophacles
I think you are missing the point. The article is not about "give us the code
instead of a paper", but instead about "give us the code as a supplement to
the paper". The basic argument is that sometimes text alone is not sufficient
to explain - a point you concede to by mentioning that the formulae exist in
textbooks along with the description. The reason they include those formulae
in physics books is because the text is one way of describing something, and
the math explains the relationships. Both have their strong points.

Take for instance many protocol standards: they come with a reference
implementation, because sometimes the text is harder to understand when you
can't compare it to code which actually does what is being described.

~~~
NY_Entrepreneur
I was trying to be short and clear.

Your

"The article is not about 'give us the code instead of a paper', but instead
about 'give us the code as a supplement to the paper'."

is an appropriate interpretation of the paper. But I can't have much sympathy
for that interpretation because the code can be so darned long and obscure.

Some 'pseudo-code' of, say, a dozen lines as a 'figure' is okay. In nearly all
cases, any code very close to something that actually runs in practice would
tend to be too darned long.

The 'knowledge' of the paper is supposed to be clear just from the paper. Then
the code is supposed to be 'routine'.

If the main body of the paper does not make the knowledge clear, then
including a few hundred lines of code has little promise of improving the
exposition.

There's a good history supporting my point in books by Knuth, Ullman,
Sedgewick, the paper

Ronald Fagin, Jurg Nievergelt, Nicholas Pippenger, H. Raymond Strong,
'Extendible hashing—a fast access method for dynamic files', "ACM Transactions
on Database Systems", ISSN 0362-5915, Volume 4, Issue 3, September 1979,
Pages: 315 - 344.

and more.

For your

"The basic argument is that sometimes text alone is not sufficient to explain
- a point you concede to by mentioning that the formulae exist in textbooks
along with the description."

I believe you are asking too much of the equations, not a lot too much but too
much.

In simple terms, even pure math is, usually is, at best is, is supposed to be
written in complete sentences in a natural language, say, English. E.g., in a
physics book describing Newton's second law, we discuss force, mass, and
acceleration, explain that force is a vector F, mass is a scalar m, and
acceleration is a vector a, say that force is the product of mass and
acceleration, e.g.,

F = ma

So, by the time get to the equation, almost don't need it. Of course, not ALL
writers write this way!

A long sequence of algebraic derivations is supposed to have a start much like
what I gave for F = ma and after that is just algebraic derivations, often
with not much need for more text.

For

"Take for instance many protocol standards: they come with a reference
implementation, because sometimes the text is harder to understand when you
can't compare it to code which actually does what is being described."

yes, there is a practical challenge there. Finally the Unix world decided to
'go empirical' and have 'code runoffs' or whatever they were called where
people just got together to see if the actual code, say, the TCP/IP stack with
SSL, would actually appear to work. Of course, that empirical approach was
always risky because it is a long way from a mathematical proof of correctness
or even a solid engineering document. And we've seen problems, e.g., with
security in DNS.

For more, the AI world decided to f'get about 'theory' or even usual
scientific documentation and make the criterion just 'does the code appear to
work'. This, too, has proven to be risky and, of course, is a big step back in
documentation quality from good applied math, mathematical physics, and
engineering of past decades. E.g., how the heck to know that the Manhattan
Project was on track before the first test? Sure: There were a LOT of
derivations and calculations; that is, the project didn't rely on just the
empirical approach. Indeed, the uranium bomb was dropped on Japan as the first
'test'; the engineering was so solid there was no doubt it would explode.

Sure, there is a big role for testing, but, still, the 'knowledge' in a
journal is supposed to be able to stand on its own without much help from
detailed documentation on code, electronic circuits, mechanical mechanisms, or
chemical reactions. In particular, in experimental science, the published
paper is supposed to be clear enough to permit others to reproduce the
experiment, and to do so without detailed photographs and drawings of
apparatus.

When I was an undergrad, one summer I worked in the lab of a famous scientist.
He explained to me how a scientist is supposed to keep a good notebook and
really good records. Then if another scientist wants to check details or
reproduce results, sending the notebooks and data is supposed to be an
obligation, and the materials are expected to be handled with great care and
then returned.

So, yes, at times, in practice, there can be more that is relevant than just
the published paper.

Still, communicating the 'knowledge' of a research paper with a few KLOC of
code is a bit much!

~~~
sophacles
I really think you are fighting a strawman here. Your argument is all over the
place too... Is the math supposed to be clearly explained in text or just the
starting conditions from which the rest of the formulae just tell the story
for you?

Moving on to DNS having security holes and other problems with protocols made
with reference implementations -- how is this relevant? Lots of scientific
papers get published that later turn out to be wrong, whole fields of study
sometimes look really good and push our understanding of the world but
ultimately go away as "the wrong approach". This is just progress, not a
fundamental flaw in putting making code available.

When you say the "knowledge of a paper" should stand on its own, without the
need for the circuits, code, etc to understand it -- this is true of many
fields, but not true when the paper is about the circuit, the code, etc. Then
that very thing should indeed be presented, otherwise no amount of text will
properly explain it, other than a 1000 words where a picture would suffice.

As for your famous lab scientist -- why is it ok that he wants to make
notebooks and other lab stuff available, but when we ask for code to be put in
a public repo when reviewing papers we are suddenly breaking knowledge?

An finally, about your last sentence -- supplemental code is not an attempt to
transmit the knowledge with the knowledge of a research paper. The word
supplemental means "in addition to", the paper should still happen!

A last, slightly tangential thing: No matter what you say about text being the
only way to transmit knowledge, there are plenty of occasions where a simple
digram transmits much more meaning to me than reams of text, I am visual
thinker and learner. Similarly there are times when a few lines of code can
tell me as much as paragraphs describing them. There are times when I see an
equation and get what the paper is trying to discuss. There are also times
when the text is invaluable, and without it I would be lost, no matter how
good the diagram or equations or code. The methods of knowledge transmission
are many -- to be stuck on a single type as the "true way" is a bit absurd
and/or pretentious.

~~~
NY_Entrepreneur
The resolution appears to be there are two quite different worlds: First there
is the world of peer-reviewed research papers in computer science where the
goal is to present knowledge that is new, correct, and significant and that
sometimes results in code. And second there is the world of commercial
computing that is heavily about just code. But these two worlds are very
different. In particular, the research papers are not trying to document or
describe code. Moreover, in the knowledge presented in a research paper, that
knowledge is supposed to be in the form of text, possibly with some math, but
not in code. E.g., the original paper with heap sort didn't need code; Knuth's
presentation of heap sort in TACP has only a little code, in his language MIX
which few people bother to understand, that is not essential.

"Is the math supposed to be clearly explained in text or just the starting
conditions from which the rest of the formulae just tell the story for you?"

Again, you are asking too much from the math. Again, 'math' is supposed to be
written in complete sentences. In particular there is no 'new language'. I
illustrated with F = ma: You are supposed to get nearly all "the story" from
the text and not the equations. Well written math doesn't ask a reader to get
"the story" "just" or even primarily from the equations. If you don't want to
accept this description of good writing in math, then so be it, and our main
difference will be right there and not "all over the place".

Again, yet again, once again, the knowledge is supposed to be in the text, in
well written paragraphs, in complete sentences, and there is no 'new
language'. For an equation such as F = ma, that is a part of speech, a noun.
And again, yet again, the surrounding text is supposed to be so good that the
equation is hardly needed. Again, yet again, one more time, please read it
this time, you are not supposed to have to dig the meaning out of the
equations in more than a peripheral sense.

"Moving on to DNS having security holes and other problems with protocols made
with reference implementations -- how is this relevant?"

Because, again, the code, including in a 'reference implementation', doesn't
mean anything. We shouldn't ask to determine correctness, or even the quality
of the design or engineering, just from the code, not even code with mnemonic
identifier names and many in-line comments. The 'relevance' is that we see
that the DNS code had security problems, that is, was not high quality design
or engineering, and the reason for those problems is that high quality design
and engineering are in text and NOT in code. So, with just the code, we have
no solid, rational support of the quality of the design or engineering.
Instead, about all we have is the code. Then to know if the code has high
quality, we just deploy it and wait for the bug reports. Then we study the
code, see where the problem is, patch the code, deploy it again, and wait for
more bug reports. NOT good. NOT high quality design or engineering.

We do NOT design or engineer airplanes like in a 'reference implementation' of
DNS. Instead, before the plane carries passengers, we have a mountain of rock
solid engineering, heavily in text, saying that the plane is safe. We do NOT
primarily determine the safety of an airplane by putting one million
passengers in it. In DNS, we determined the quality of the work primarily by
deploying it, using it in real networks, getting the bug reports, and then
fixing the bugs. So, the DNS engineering was shoddy work compared with nearly
all of the rest of engineering.

Broadly we just cannot expect to have delivered high quality software when
what is delivered is mostly just the software. Instead, the quality has to be
in a document almost entirely in text. In high quality? Yes. In common
commercial practice? No.

Fundamentally it is the text that really matters, NOT the code. Again, yet
again, given the text, the code is supposed to be routine. This holds in
'research level' 'knowledge'. Sure, this doesn't hold in routine commercial
practice.

"Lots of scientific papers get published that later turn out to be wrong,
whole fields of study sometimes look really good and push our understanding of
the world but ultimately go away as 'the wrong approach'. This is just
progress,"

No, you are not describing "progress" but are describing just mistakes, that
are sometimes costly, and are to be avoided strongly.

"When you say the 'knowledge of a paper' should stand on its own, without the
need for the circuits, code, etc to understand it -- this is true of many
fields, but not true when the paper is about the circuit, the code, etc."

No, not really: We're talking about peer-reviewed research publications of
'knowledge'. That 'knowledge' is not really supposed to be about the circuit
or the code. Instead, the circuit or code are supposed to be routine
implementations of the knowledge in the paper.

You want to elevate the circuit or code to the level of knowledge, and that is
backwards and wrong. Your goal of elevating code to the level of knowledge and
what is primary is not promising. In simple, blunt terms, so far without
serious exceptions, 'knowledge' is communicated in text, possibly with some
math, in a natural language. That's all we've got. There ain't no more.

"Then that very thing should indeed be presented, otherwise no amount of text
will properly explain it, other than a 1000 words where a picture would
suffice."

In the communication of knowledge, we don't depend primarily on pictures,
figures, diagrams, schematics or code. Instead we communicate knowledge in
text, possibly with some math. Again, good examples are in books by Knuth,
Ullman, Sedgewick, etc.

Again, yet again, once again, please try actually to read it this time, there
has been a long tradition in math that there should be no diagrams or pictures
at all, not even in vector calculus. Much of the motivation was to have the
discipline to make SURE that the content was in text, just text, with some
math, and NOT in pictures. Again, we didn't want the content to be in
pictures. This point is SERIOUS about keeping up the quality of the material.

For pedagogy, a picture can be terrific, but 100% of the content should also
be in the text.

"As for your famous lab scientist -- why is it ok that he wants to make
notebooks and other lab stuff available, but when we ask for code to be put in
a public repo when reviewing papers we are suddenly breaking knowledge?"

We're not. Put all the code in public repositories you want. Put in 1000 KLOC.
Fine with me. But the code in the repository is not going to be part of the
paper, e.g., it will not be reviewed in the peer-review process. Moreover, the
paper just MUST make sense with no reference at all to the code. Again, the
code is NOT the knowledge or the subject of the research paper. Again, the
paper is NOT about the code; it is not a paper describing the code; the code
is not the 'contribution to knowledge'. Instead, the code is at most a
hopefully routine implementation of the knowledge in the research paper.

"No matter what you say about text being the only way to transmit knowledge,
there are plenty of occasions where a simple digram transmits much more
meaning to me than reams of text, I am visual thinker and learner."

Fine. So are many people. But such ways of 'transmitting knowledge' are NOT
what we are talking about. We're talking about peer-reviewed research papers.
Tutorial presentations can be very different. Movies are very different. TV is
very different, even some of the TV cooking shows that try to be instructional
are very different.

Maybe the main point of misunderstanding is, practical computing is nearly all
about code, just the code, and, thus, you have accepted that computer science
research papers can be about describing code. No. Instead, for such papers,
any code is supposed to be just an implementation of the knowledge in the
research paper and routine. The knowledge in the research paper is NOT 'code'.

The knowledge in a peer-reviewed research paper is supposed to be rock solid,
and, again, yet again, we don't communicate that with pictures or code.

Pictures and code? In tutorials, fine. In commercial work, sure. In research
papers, only a few lines of 'pseudo-code' in a picture that is not essential
to the paper. Understand now?

------
zohebv
Most often they don't have any code. Most of the action takes place inside the
head and not inside the computer. What they have are proofs of correctness,
invariant enforcement, complexity bounds etc. I doubt that reading the code
will improve understanding of the algorithm anymore than a thorough
description of the algorithm.

------
tobiasu
But... computer scientists don't write code! That's not what they're studying,
it's not their job!

Writing code is what women do.

"Computer Science is no more about computers than astronomy is about
telescopes."

~~~
mayanksinghal
While I do not agree to the fashion in which the above comment was made, I do
agree with the sentiment.

I know a few computer scientists who are really good at algorithms and
theoretical computer science but will not write/be-willing-to-write code.
There are, many times, constraints because of lack of proper representation in
the language or because of added complexity in actual code than in pseudo code
(because of edge cases - unnecessary boilerplate code to just make the code
run etc.).

Additionally, many a times the paper might be presenting part of a larger
algorithm/solution and that part in itself might not be useful/compilable.

I think that pseudo code fulfills the need for most of the cases; at times
when it doesn't peer reviewers would ask for code and the same will be
provided if possible.

[edit: typos]

~~~
mayanksinghal
Oh and papers without implementation make up a significant part of a lot of
undergraduate course projects. I am actually looking for an interesting
research paper to implement for Digital Image Processing.

