text:
Is publishing runnable code instead of pseudo code shunned?
In Computer Science is it preferable to describe algorithms using pseudo code rather than real code? If so, why?
I've talked to a few academics who think so but I can't understand why. Some of the arguments I've heard:

"Pseudo code is shorter."  Given a modern language like Clojure or Python, the real code is often not much longer. Even if it is, (electronic) paper is cheap.
"Not everyone can code in Python."  True, but well-written Python code isn't harder to read than pseudo code. Plus, Python is standardized - someone's personal pseudo code isn't.
"In CS, we focus on algorithms - not implementations."  True, but also showing implementations doesn't take away from that focus.
"It's favoring one language over another."  True, but that is a right I as an author have, isn't it?
"It looks amateurish."  That's subjective.

The main advantage with real code is that you can run it and see for yourself if it works or not. You don't have to wonder whether you have made a mistake in implementing the pseudo code.
So what are the arguments for pseudo code?
To make it clear what I mean by real and runnable code, see the code in the following articles:

An Effective Implementation of the Lin-Kernighan Traveling Salesman Heuristic
Fast Minimum Storage Ray/Triangle Intersection
Watertight Ray/Triangle Intersection

The first and second contains C code. Helsgaun claims it is "c-style pseudocode" but it is to my eyes almost indistinguishable from real C code. The difference I can see is that it uses α, β and ∞ as variable names. The third contains C++ code.

Comments are not for extended discussion; this conversation has been moved to chat.

I would go further and say that we should move away from publishing articles as pdf (or LaTeX) documents at all and towards runnable document formats like Jupyter or literate Haskell etc.. Knuth already argued for literate programming, and nowadays this is really feasible. A good example of an executable book is Programming Language Foundations in Agda. But I'm afraid this is not really a mainstream opinion...

Submit the "real" program as an artifact:  https://www.acm.org/publications/artifacts

you can provide both pseudo-code and real-code and get the benefits of both without any downside.

As a very related topic, mathematicians are expected to explain their paper using words.  The mathematical proofs they write are useful, no doubt, but they explain in words as well, which does much to minimize the risk of a syntactic blunder.

For those that don't realize, I want to point out that Python uses whitespace as an important language feature to create blocks of code.  Seems like that alone makes it a questionable choice for a publication that you might not always have total control over the format of.  Also, the Traveling Salesman paper seems to have psudeo code and "runnable" code that wouldn't run because it uses special symbols like infinity.

You know, if I wanted a nice demonstration of why runnable code is worse than pseudo that second link would be a perfect example

"well-written Python code isn't harder to read than pseudo code": I'm sorry but this is simply not true. I keep hearing this from Python people, but as someone who came to python relatively late, I can assure you it isn't the case. I think too many Python folks simply forget that they have internalized the language's syntax and no longer realize that it isn't as obvious as they think. So yes, python is easier to read for the non-initiated than some other languages, but it isn't as obvious as pseudocode. Not even close.

@JackAidley I agree. Authors probably see it too, and that's why they had to add a comment to each line of their code. Try separating the comments from the code. Real all comments together, then all code together. Which one tells you more about how to solve the problem?

@DmitrySavostyanov I don't understand your complaint about comments. Do you think they make the code harder for you to understand?

@BjörnLindqvist The OP uses the links to give examples of readable code. In the second reference, the comments are readable but the code itself is (imho) not. Taken separately, comments provide more value than the real code.

@DmitrySavostyanov The comments are part of the code, you can not consider them separately. Is the code (including the comments!) hard for you to understand?

@BjörnLindqvist I don't think one can really claim that the code is readable if each line has to be explained with a comment. Note that pseudo-code normally does not require commenting.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler, 2008.

Is publishing runnable code instead of pseudo code shunned?

Not that I know of, but this probably depends on the specific subculture of the respective field.

In Computer Science is it preferable to describe algorithms using pseudo code rather than real code?

It was (see Owen's answer) and sometimes still can be (see considerations below).

If so, why?
[...]
So what are the arguments for pseudo code?

As many of the other answers already state: Other than naive runnable code, pseudo code aims to be easily read and understood without bothering the reader with unimportant (for the presented aspect) details. And it usually succeeds at these goals.
As you yourself state, runnable code also has its benefits. So let me side-step the issue by claiming that
with some effort you can get the benefit of both
(and without actually providing both, pseudo code and separate runnable code, as syn1kk suggests.)
Ideal code in papers (and, if feasible, elsewhere) is pseudo-pseudo code: Code that has all the positive properties of pseudo code, but happens to be runnable (and to actually do what it seemed it would).
It is my firm believe that all sufficiently well-written runnable code is indistinguishable from pseudo code: If anyone can tell that certain (actually runnable) code isn't pseudo code because it isn't as readable and as easily comprehensible as pseudo code, that runnable code isn't structured well enough, yet, and should be refactored.
How to get pseudo pseudo code
How do you achieve runnable code that is as easy to read as pseudo code?
There are several aspects to consider and fulfilling all of them may not always be easy or feasible, or sometimes not even possible. (This can be a valid reason to use actual non-runnable pseudo code instead of runnable pseudo-pseudo code.)
Choose the right language
What language is best suited depends on several things:

The problem domain
Your solution approach
Your audience
The possibilities the language offers for (re)structuring your code

Note that for some combinations of these, no programming language may (yet or sometimes even ever) exist that allows you to write sufficiently well-written code. For obvious practical reasons, you'll also have to factor in your command of the respective language (how skilled you are in applying it).
Make your code extremely clean: Refactor, refactor, refactor
If there are implementation details that obfuscate the core idea of the algorithm you're describing, extract them (e.g. to constants, variables, methods or functions), so that you can replace their "how" (their implementation) by their "what" (the name of the newly extracted code-thing). If appropriate, choose not to show the extracted implementation or assignment in the in-paper code excerpts. Take extreme care in naming the extracted things, so that their purpose (not necessarily their implementation) is extremely clear and obvious from their name and call signature.
On the other hand, if an algorithm is too scattered between different parts of the code to be readily understood, you may have to selectively inline code instead.
In all of that, aim for a single level of abstraction per code unit (e.g. function) or, at least, the right levels of abstraction to best show and explain the algorithm. Though apply the somewhat related single-responsibility principle only with care: Over-applying it (or interpreting "single responsibility" too narrow) can scatter and thereby obfuscate your algorithm. Note that in that regard, the right balance for code to present in a paper will most probably be different from the right balance for code in a (to-be-)maintained software product.
With any sufficiently optimizing compiler or interpreter, none of these refactorings should too adversely affect performance. But when the focus is on presenting an algorithm rather than implementing it in a production system, this shouldn't be of too much concern, anyway.
Make your code obvious to interpret
The correct interpretation of your pseudo pseudo code shouldn't rely on knowing your chosen programming language, or its version, variant or dialect. Thus be wary of what language features you use.
Each language feature that is common to many programming languages (known to the audience) and that in the chosen language has a similar syntax to many other programming languages could just as well be also a feature of a pseudo code dialect and can thus be used in pseudo pseudo code, unless the chosen programming language has an unusual and non-obvious semantic for it. Even a not-so-common or language-specific feature, or one with a not-so-common syntax, can be used without problem, if its semantics are sufficiently self-evident from its syntax and keywords and their relation to natural language.
Non-obvious language features are best omitted, but can be used when combined with explanations in code comments or in the paper's prose. (Just as it would apply to non-obvious features of a chosen pseudo code dialect.)
The same goes for language specific idioms: Avoid or explain them, if you have to expect them not to be obvious to your audience.
Alternative: Make pseudo-code runnable
The above two sections assume that you start from working runnable code. Of course you can also start from pseudo code and modify it to actually be runnable (and hopefully to do what it seems to do) in a suitable programming language. Note though, that you can end up with very non-idiomatic code for the target language that way, which may not be what you want. Of course, refactoring can usually fix that.
Explain your code
Just like you would have to explain (in prose, code comments or callouts) certain aspects of your code if it was presented in pseudo code, you have to do that if it's written in pseudo pseudo code.
The advantages of pseudo pseudo code

As readable and comprehensible as pseudo code
If the used language (incl. version, variant or dialect, if applicable) is specified:

it is runnable and usable
it is testable both manually and by automated tests
it is profilable

Some of these advantages benefit you as the author, as you can for example make sure(r) the algorithm as presented is actually correct. Others benefit your audience who might want to assess your algorithm.
Whether these benefits are worth the significant work that is required to achieve pseudo pseudo code vs. just pseudo code or on the other hand not sufficiently well-written runnable code, is up to you to decide.
Oh, and let's not forget the moral benefit: Whether "it looks amateurish" or not, you can be confident that it isn't, due to all the skill and hard work it requires.

If you can make pseudocode runnable or code as easy to understand as pseudocode, that should be the optimal solution. But I believe it is often not possible without losing brevity or clarity or both. Eg computer friendly E_dagger_x(x_i,y_i,z_i) is much less readable than typical mathematical form and possibly even leads to confusion whether you have E_dagger_x as a separate entity to E or perform a transformation on E. Also, algorithm often has many steps like "pick eigenvector of A": main code would be indeed identical to pseudocode, but wouldn't run without that function added.

You’ve presented a fantastic argument for why most authors don’t include real code in addition to pseudocode — It’s too much work for too little (perceived) benefit.

There are cases where real code is preferable, and cases where pseudocode is preferable. You shouldn't rely on a simple iron rule, but rather on judgement of what is appropriate to the situation.
Some things to consider:
Programming languages come and go. In the 60s, Fortran was considered a really nice and readable programming language, much easier to read than Assembly. But if you'd written an article using Fortran code samples instead of peudocode, it would be harder to read for us now. Right now, Python looks pretty good to us, but will it still look that good in the future? If I handed you a piece of Python code with the following code in it:
a = 3 / 2

What is the value of a? Is it 1 or 1.5? Because Python 2 and 3 handle integer division differently. Now, I've gone more or less native programming in Python 3, so I actually had to look up which of the division operations in Python 2 and 3 are different and which aren't. Just to show you, using real code in a paper may reduce the shelf life of your paper.
Pseudocode lets you abstract stuff away In pseudocode you can just state something like:
WHILE stopping criterion not reached DO
    (stuff)

And then later on in your paper you can argue about different possible stopping criteria for your algorithm. You could do that with actual Python code too, but the result would be basically that you're twisting your Python code to do what pseudocode does by nature.
You can be pretty standardized in pseudocode Just use the various algorithm typesetting options for LaTeX.
You can use mathematical notation in pseudocode Using mathematical set notation is a lot more universal than relying on all of your readers understanding Python set operations. Consider:
a = set([1, 2, 3])
b = set([1, 2])
c = 1 if b.issubset(a) else 0

versus
A ← {1, 2, 3}
B ← {1, 2}
C = 1 if B ⊆ A
    0 otherwise

Someone not familiar with Python looking at the first example will be wondering: is [1, 2, 3] a ... maybe a list? Well the list [1, 2, 3] isn't the same as the list [1, 2], so the set A and the set B contain different elements so B can't be a subset of A.
Algorithms vs. implementations Suppose in 2019 you write an interesting algorithm in Python 3 using some state of the art libraries. In 2025 I come up with an alternative algorithm for the same problem in Go and want to compare performance to prove that yours is better. To get a fair comparison, I'm going to have to implement my algorithm in Go or yours in Python. Suppose by then nobody uses Python for high performance stuff anymore because Go does it better. (It might, I dunno.) Now I have to go research the seven year old libraries you used to find out exactly what functions you used and which Go functions are equivalent to them. That's very hard. So quite likely, the Go implementation I make of your algorithm won't be all that good. And big surprise! My algorithm benchmarks better than yours!
Now instead if you'd used an implementation-independent description of your algorithm, things might turn out better for your publication.

So the two big disadvantages of using real code are: it limits the shelf life of your publication, and you reach a smaller audience.
So when should you use real code?

When the topic of your paper is not the algorithm, but the implementation or the programming language. Maybe you're trying to show that Python is a really good language in which to solve problem X because with libraries Y and Z you get an easy and efficient implementation.
It's absolutely encouraged to also publish your real code as an appendix or, better yet, in a repository where people can download your code and suggest improvements. A nontrivial algorithm is probably too big to copy by typing by hand or even copy-pasting out of a paper anyway. As soon as you start getting into something like a new Deep Learning algorithm, you're probably looking at multiple files or even nested packages.

The discussion about Python (and other) code has been moved to chat. Please read this before posting another comment.

Indeed. I would have written that pseudocode mostly should be on higher abstraction level than real code (and therefore used in papers)  If it isn't on higher abstraction level, then it is probably unnecessary detailed, which distracts the reader and makes the paper harder to read.

These are very good points! In my field (data science) it is common for a paper to describe a new algorithm in pseudocode and then implement it in R or Python. That gives readers the best of both worlds.

In my research, I often write algorithms, which may contains statements like:

Find a dominant subspace of a given hermitian matrix A with relative accuracy Ɛ.
Find a nonnegative solution of this system of equations / inequalities.
Sort these eigenvalues from large to small in modulus, discard small ones and reshuffle the eigenvectors accordingly.

These instructions are perfectly simple and clear to anyone doing Numerical Linear Algebra, regardless of their favourite programming language. I see no reason to use a particular programming language in the paper and risk capping my readership. I believe that the natural language is faster to read and understand. Particularly, it allows me to talk clearly about what is the purpose of each step, rather than about how to achieve it. There are often more than one way to, e.g. "solve a linear system", and the use of pseudo-code allows me to distinguish between "solve it somehow" and "solve it using this particular algorithm".   Hence, I use pseudo-code which allows me to better express nuances like this.
I always provide actual code alongside the paper in an open repository, which readers can  clone and explore, saving them a bother of retyping the code from the pdf / printed version of the paper.

You could write a method call that says it does that in its name and then don't show that except in your appendix. This way it's valid code and says what it does without actually doing it. In some languages you can even use spaces in the method name.

@findusl and then you are again limited to some special kind of notation and have to drag parameters into the call etc. It is not as good to read and convinient.

@findusl I could, but it would arguably makes it harder to read for humans and harder to use as a program for computers. Your idea seems is a compromise between two worlds, while I suggest to provide separate description of the algorithm for human readers (pseuso-code, or how you call it) and separate code for computers (repository), not one fit all.

Pseudo-code is forever; real languages change all the time.
If you'd published a paper with an algorithm in Python in the Python 2 days there is a significant possibility that the "executable" code that you wrote then will no longer operate correctly if people run it under the latest release, even in less dramatic cases the advance of new libraries and algorithms is likely to leave readers confused as to your archaic choices. Imagine if papers from 40 years ago had used the languages of the day; would you understand the subtleties of some Fortran or Pascal code? Programmers then made the same claims for understandability you make about Python.
So pseudo-code is better because will clearly express the key ideas just as well in a hundred years.
Pseudo-code expresses the intent of code better than real languages
In order to write working code I must, nearly always, carry out a number of steps in order to get the program to work that are not required in order to set things up, format things or whatever, these steps can be ignored or simplified in pseudo-code in order to communicate the important information.
What's more, in real languages I must make decisions about how data is stored, which algorithm is adopted for sorting, etc. that are incidental to the algorithm discussed in the paper. By including these incidental choices in your description of the algorithm you guide implementers towards making choices that may not be optimal, either because better choices are now available or because the choices you made are unsuited for their target environment.

Good point about languages changing. As one example, many algorithms depend on the difference between integer and floating point division. In Python 2, variable type was used to determine which operation / performed. In Python 3, the operations actually have different symbols ( / vs. // ) Someone not aware of what is in some sense Python trivia might see / in some Python 3 code and assume that integer division was intended whereas in Python 3 it is always floating-point division.

Human languages also change.  But not as fast as programming languages.  (Although I have been rather amazed at the evolution from “I said” to “I went” to “I was like” that all happened within my lifetime).

@WGroleau: Yes, that is true, so perhaps "is forever" exaggerates the matter. Even so, I've read biology papers from a hundred years ago without any major difficulties.

@WGroleau: I would disagree.  Subcultures have always had their slang, which most often dies out without affecting the standard language.  Kind of like versions of programming languages, or sometimes the languages themselves.  I recall learning, way back as an undergrad, about languages like Snobol, Forth, and Prolog, yet who uses those today?  Indeed, the main language of instruction back then was Pascal, while C was this odd thing that you picked up on your own...

Having attempted unsuccessfully to read Chaucer in the original (not to mention several post-grad linguistics courses), I’ll stick to my statement—including the “not as fast” part.

+1, I've had reason to be reading some very old papers lately.  I am very appreciative the authors did not assume I would be able to read or execute FORTRAN77.

Pseudo-code is forever – take my upvote!

@Affe: Running Fortran 77 is no problem.  GCC contains a perfectly usable compiler, and there's still a good bit of running code around.  Now if you're getting into Fortran 66 or earlier... Well, you just haven't lived until you've tried to figure out code containing assigned & computed GOTOs :-)

But what's the rules for pseudo code? If the author states that all examples are in Python 3 I can look it up. With pseudo code I have to guess if 3/2 is 1 or 1.5.

The arguments that you have heard are all possibly correct. I have been a reviewer and author of many computer science articles, I would like to answer this question in my way and the way I feel.

Pseudo code is shorter. Given a modern language like Clojure or Python, the real code is often not much longer. Even if it is, (electronic) paper is cheap.

The pseudo-code is short and clearly understandable. Pseudo-code helps in decoding the idea very clearly as compared to a whole code. I am not going to spend a few hours of my time understanding your code. For example, to sort a CSV file based on third column, you may have written 3 lines, which I don't really care about. I just need to understand that the file has to be sorted. Second, what if I don't like the language in which the code is written. There could be a huge bias in such review and interest.

Not everyone can code in Python. True, but well-written Python code isn't harder to read than pseudocode. Plus, Python is standardized - someone's personal pseudo code isn't.

This is just a claim that Python community is for everybody. This is true for many other languages as well: Matlab scripts, R scripts, Java scripts; some people (e.g. myself) love UNIX Shell scripts as well.

In CS, we focus on algorithms - not implementations. True, but also showing implementations doesn't take away from that focus.

I agree to this. But, looking at the whole code does not make sense. Read the first point.

It's favoring one language over another. True, but that is a right I as an author have, isn't it?

You should understand that you are writing the paper for "the world except yourself". So, you are nowhere in the intended readers' group. You should write something which the readers will read not to get annoyed with.

It looks amateurish. That's subjective.

Indeed.
Verdict: You can always give full code in your paper (as in the Appendix or in Supplementary material). But, you must give an algorithm/pseudocode in the main paper.

+1 for "what if I don't like the language..." We had a paper rejected in which the reviewer explicitly noted that they felt that because our implementation was presented in language X, it was difficult to understand. While this was likely not the real cause of their rejection, using pseudocode wouldn't have opened us up to that attack.

@deckeresq Unless they decided they didn't like the formatting/style of your pseudocode instead.

@JAB Ha, very true!

I like the current three top answers right now (by @ObscureOwl and @DmitrySavostyanov and @JackAidley). But I feel like there is one option that is not being represented.
You can provide both the pseudo-code and the real-code.

Most likely the real-code is too long to be provided in-line in your paper.
So you would provide the pseudo-code in the paper.
Then the real-code as an addendum or supplementary-download or URL.

Providing both gives you all the benefits of both AND more.

You have all the benefits of pseudo-code.
You have all the benefits of real-code.
So your readers can more easily understand your paper by reading the pseudo code and understanding the intent and then if they are super serious they can then go to the real code and start using it.
The code is easier to understand because they already have the pseudocode which explains the low-level implementation.

Lastly providing both ensures long-term understanding (pseudo-code does not go obsolete) AND short/medium term your research gets more adoption, more usage, easier to reproduce your results.

More short-term adoption/usage/reproducing means longer-term more impact on others and more long-term usage.

Example #1
https://academia.stackexchange.com/a/140990/349 is a great example where the pseudo-code is much more readable/understandable/intent-is-obvious ... implementing this in code would take lots of lines of code and could get ugly quickly and take up too much space in a paper... so you would definitely want the pseudo-code... but if you were serious and wanted to use the paper... having the real-code would save me many hours... in some cases many hours/weeks/days/months of recreating the pseudo-code.
Example #2
Here's another example. http://www.fftw.org/fftw-paper-ieee.pdf The FFTW algorithm is for computing the Fourier Transform. The paper talks about algorithms but the implementation is also very important. So the paper provides mostly pseudo-code and a tiny bit of code. And if you want the source you can get that as a supplementary download.

Indeed this was an xy-problem! Write pseudo-code in the paper and attach real code as supplementary. Simple as that. This should be the too answer.

Indeed. A good compromise is to use very clean pure pseudocode to explain the principle of your algorithm. Meanwhile, in your real code implementation, you pull out all the stops to optimize it and do well on benchmarks.

@ObscureOwl the solution by @Dmitry is really what pushed me to write my answer because i'm all for seeing code... but his example is a great example of when code would really really drag down a paper (implementing each of his 3 bullet points in code would take 30-200 lines of python/matlab... and would detract from readability of the paper a lot).

@ObscureOwl but at the same time... not having that code available after reading the paper can mean no one can reproduce his results or no one can use his ideas because the secret sauce isn't in the pseudo-code but is instead in the implementation. for instance maybe there are some key threshold values that aren't in the pseudo-code.

As a dev reading published paper, having both is a awesome. I am used to read code. It is far easier for me.

In my experience as both an author and a reader it is highly preferable to use real code rather than pseudocode whenever possible. I have never had a reviewer complain when I used real code rather than pseudocode.
Moreover, real code is advantageous not only because the reader can run it themselves but also because the author can run it and make sure they haven't got bugs in their presentation.
However, making real executable code good for presentation as an algorithm is often still quite difficult:

Correctly executable code is not necessarily intelligible.  It needs to be carefully cleaned, commented, and arranged.
If the paper includes analysis, the code variables need to match the analysis variables, which can be problematic with more complex mathematical notations ("x_hat_sub_i_prime")
Line lengths often need to be much shorter to fit in a paper column, which adds additional reformatting and often ugliness.
There are often "uninteresting" but necessary parts of code, like packing and unpacking information from data structures.
Code often gets entangled with dependencies, environment, and context.
Some languages just seem to be inherently "wordy" and difficult to make compact listings with.

Given all this, I think many authors may just find it easier to bang together some iffy pseudocode rather than try to get real code to be both presentable and correct.

If it wasn't for your first paragraph, I might read this as an answer in support of pseudocode over real code. You provide no less than 6 reasons why pseudocode can be preferable, but just one in support of real code - you can run it. As long as you can write the pseudocode without bugs, there are several advantages to describing an algorithm with pseudocode and providing the actual code in a supplement, and zero drawbacks.

I agree with you. I should have specified that the code is well-formatted and not "dumped" into the article. :) Like the example links I added to my question.

@NuclearWang I don't know about you, but I have confidence that nearly all untested code has bugs, including pseudocode. I've certainly spent a lot of time trying to figure out incorrect pseudocode from others' papers as well. Thus, in my opinion that "just one reason" heavily outweighs all of the others.

Well. nearly all tested code probably still contains bugs. Thats what I can say as a Softwaretester. And yeah your answer is more pro-pseudo than pro-implementation.

@jakebeal It is absolutely certain that authors have their own runnable code - they have produced results with it. Pseudocode is merely a summary of that tested and used code. If you don't trust them to write a correct summary of their code, then you have no reason to trust their text, equations, results or anything else - all that might contain as serious issues as pseudocode or even their actual code.

I've just started writing a Python pseudocode debugger... I'm gonna be rich!

@ZizyArcher After publishing dozens of papers on algorithms, I can say with absolute certainty that I do not have, and have never had, runnable code for any of them. Nor do a majority of my colleagues for their algorithms.

Pseudo code lets you focus on the important bits of the algorithm and summarize the rest.
Real code often starts with load some libraries, read in some data, then format/ rearrange it the way you need, no need for that in pseudo code.
Your algorithm might consist of multiple separate steps, some of which are standard, well-understood and boring, others are the key innovation in your paper. In pseudo code, the boring bits are just one-liners that describe what needs to happen. The juicy bits are as detailed as they need to be. In real code some of the standard details will be longer than the actually important pieces.
So in summary, in pseudo code the reader can easily see where the important bits in your code are, with real code this is much harder (not impossible, just harder).

I wanted to make this point about abstracting the boring stuff away, but I think you said it better.

I would say this is more convention, as this seems really quite field-dependent. In "combinatorial" discrete algorithms papers, I almost never see real code. Well, a notable exception is Don Knuth's TAoCP, but not everyone is Don Knuth, right?
However, in a field I work in (functional programming), presenting real, runnable code is the norm. Much of the research is really language dependent, so not surprising, but even the language-agnostic work (e.g., purely functional data structures) are typically presented using a real functional programming language like Standard ML or Haskell. Sometimes this do create some confusion, but since functional programming as a field (although arguably still mostly part of TCS) is quite implementation- and programming-oriented, most people actually want to see real programs.
So IMO this is really more convention than anything, and it really depends on the field. Most combinatorialists care about the algorithm itself on a high-level as well as its complexity, but functional programmers (or perhaps "logicians") care a lot about whether the algorithm can be implemented correctly and elegantly, hence the discrepancy.

There does not have to be a clear distinction.
The most important part of pseudo code is, that it should be clear to read. So you do not want to deal with constructs that are not part of the actual algorithm and you do not want to deal with syntax constructs, that are useful in a programming language, but not easy to understand when you do not know the programming language.
Is this pseudo code or real code?
if a == b:
    a = a % b

This is valid python code. But it is also some readable pseudo code.
What about this one?
for i in range(10):
    print(i)

I would say this is no (good) pseudo code, as the for construct is not obvious.
You may be able to get the for i in part, but what does range(10) do? Even range(0, 10) is not really clear, because it is not obvious that 10 is not part of the range.
In addition, you need to keep in mind, that math and computer science often differ in starting the indices with 0 or 1.
so I would say this is much clearer, but no valid code:
for i = 0 .. 9:
    print(i)

There are other ways to express the intent of the for loop, that are similar clear and easy to read. Here you could try to use the C syntax for(int i=0; i < 10; i++), or maybe even omitting the int.
What belongs to good pseudo code is a clear human readble listing of the input and output. So don't
int i = 0;
i := i+1
return i;

But rather use
// input:
// i: an integer number that should be incremented
// Algorithm:
o := i + 1
// output:
// o: the integer number incremented by 1

Note that I avoided re-using i to store the result, but used a variable o that is only used to store the output. This allows for omitting the return statement as well, so the reader does not need to think about what return does and where does it return to is not relevant to the algorithm.
In contrast to the example at the beginning, I used := for assignment, to make more obvious that it is an assigment operation and no mathematical equation.
Of course your personal style contains a lot of your opinion about clean pseudo code. If you are unsure, you may want to stick close to the different pseudo code packages in LaTeX and use them similar to the examples in their documentation.

To add to this, I would try to avoid the ambiguity over whether a single "=" means comparison or assignment.

Indeed. I already had := in the last pseudo code example, but I now added a note about why I use it in this example when I used = in the python/pseudo code example at the beginning of the post.

There was a time when pseudocode was the clear choice, since programming languages were so crude. The 60's and 70's, but later than that -- it takes time to safely assume a language is in general use, and at the time, not using pseudocode just felt weird. I remember pseudocode including such pie-in-the-sky constructs as: "foreach", for-loops, loops at all (as opposed to an IF with a backwards GOTO), 2D arrays, if's with else's, functions with parameters, variable names longer than 2 letters, a working string library. Essentially, pseudocode was a better, superior language.
Some academics don't code all that much, and probably have the same memories as I do, where "turn this pseudocode into a FORTRAN program" was a non-trivial assignment. For my part, I remember writing out pseudocode around 2010 (old habits), realizing it was 99% working C++ and that pseudocode isn't a thing anymore. You're just thinking and writing in your favorite programming language, with a few shortcuts here and there.

But my favorite programming language is pseudocode!

For a time in the late sixties, CACM required that algorithms in articles should be written in Algol.  They dropped the requirement when it turned out that people were submitting algorithms developed in other languages, and not tested in Algol (because they happened not to have an Algol compiler installed at their sites.)  A consequence of this behavior was that almost none of the published algorithms were compilable, and many contained substantive errors caused by authors' misunderstanding of Algol semantics.
I think CACM editors were aware of the compiler situation when they set the requirement, but hoped that the existence of a clear standard would result in unambiguous pseudo-code.
At any rate, this example shows:
    * Even with a big standards document describing it, pseudo-code is hard to write
    * Quality control is easier with executable code.

I say this without meaning to disrespect anyone, but many academics are not keen programmers - they don't enjoy programming or care about details. Programming isn't what they signed up for, or isn't the main focus of their work. They may see code as a "necessary evil", rather than as the contribution or appreciate its design. The code is perceived as being unimportant and low-level. This is all subjective of course: I may be in the extreme minority but I personally find Java code easier to understand than UML diagrams.
In my view, the entire discussion is about syntax. There's a reason why you can copy-paste Python code and nobody will bat an eyelid (hint: it's widely known even by amateurs), whereas you can't with languages that have a steeper learning curve and more nuances. It just so happens that when people see code they don't like (or, more likely, can't understand, perhaps in part due to unfamiliarity with the syntax), they may miss a large part of the contribution.
Pseudo-code is inherently designed for procedural algorithms requiring simple constructs IMO. It can sometimes be a lot more expressive to write executable code depending on what you're demonstrating. Also, it means you won't have to invent your own syntax, since most pseudocode "standards" only have basic imperative constructs.

The "cool" languages of today won't be  in 50 years. If you think they are, how is your FORTRAN IV? Your COBOL?

@Buffy Whilst I agree languages evolve over time (generally towards higher-level constructs), it must be borne in mind that the contributions of a given piece of work/research are appropriate for their time period, and expressed using available tools. If what you do is heavily dependent on certain programming paradigms, language constructs or what you're trying to demonstrate is a style of programming, then surely it's fine to use actual code? Pseudocode to me is only for mathematicians and abstract theoretical works, rather than real software

The pseudocode of Edsger Dijkstra is perfectly understandable today. Unlike Algol. And, "real" software (Python, say) is a pseudocode translated by a compiler into something actually runnable. You are being a bit naive here.

@Buffy Of course Dijkstra's stuff is understandable - pseudocode was practically designed for that kind of stuff. At the end of the day everything is 0s and 1s - we have to choose the appropriate level of abstraction to communicate our contributions. What I'm saying is that in many cases, academics think ALL code should be pseudocode, even when it is clearly not appropriate and would actually remove many important details pertinent to the contribution

Also, if "real code" is just pseudocode as you say, then why do we have so many languages? Why not just have one single pseudocode standard? Clearly, simple constructs in most pseudocode are not expressive enough in many cases. That's why we have languages with different tools, it's why we have DSLs and language engineering.


text:
Late letter of recommendation for grad schools
One of my recommenders has not yet submitted recommendation letter for my PhD application. Unfortunately, he lost his brother and has not been able to "take care of his professional duties for some days". The application was due on Dec 15 (today is Dec 28). What should I do?
I have submitted my application for PhD programs at UIUC (CS), CMU (RI), GaTech (ECE), TAMU (CS), UMich (CSE), and McGill (CS). Do any of these programs even consider PhD applications (or admit students) with 2 recommendation letters?

Find someone else who can write you a reference.

@astronat It won't be a strong one

Thank you all for suggestions. Another professor promptly agreed to write a recommendation letter for me.

I'm sorry about this situation. I suggest that you find someone else who is willing to write you a letter within a short timespan.
Talk to the programs to which you have applied to understand how they will consider a late letter of recommendation. Many programs are very lax as to when a letter of recommendation arrives, but will begin sorting and analyzing candidates the day after the deadline (some even before!). Tell the programs, either by phone or by e-mail, that your reference has just recently informed you that something personal has occurred and that it is unlikely they will be able to provide you with a letter, but that you have already arranged with another person to submit it. Ask about how and if your late recommendation will be considered, and whether your application will suffer from it. Also ask how you can include an additional reference in the system if it is not directly available through the system.
I know that some programs will look into candidates even if their file is incomplete. However, they will only officially admit you once all documents are in place. Some will reach to you to let you know that you are missing a document, but the best way to know is to ask them directly.
If you don't ask someone else to submit a letter, the worst case scenario is that your application won't be considered at all. If someone else submits a letter, the worst case scenario is that you may be competing with a lukewarm letter, which is still better than not competing at all. If the original reference submits their letter, you will have four letters, which is better than two strong and one lukewarm, but not much worse than three strong, and significantly better than just the two.

You are the applicant here, you should be the person able to answer this question.
Look at the guidelines of your applications and confirm whether the recommendation letters are a mandatory item for your candidature to be considered or if it is optional. In general, recommendation letters are optionals.
In which concerns your recommender, I would not bother him in this sad moment. Try to ask to another professor to write a recommendation letter for you instead, if you really need one more letter.

In general, recommendation letters are optionals. - This is not the case for any of the programs that I know of.

@FBolst my experience is from Europe and Latin America where  the lack of  a recommendation letter would not exclude the applicant. At the end, the CV is the most important factor to be accepted or not in the universities I know.

It seems to me that policies in the US differ by institution and department. I do not imagine that many admissions committee members are spending winter holidays reading letters of recommendation. So If your recommender of choice submits his letter within the next weeks, that may be good enough. // Sometimes 'deadlines' apply to applicants, sometimes to both applicants and recommenders; there is no use asking this week; admin assistants around during the break will likely not want to go on record as saying deadlines are flexible. // Yours will not be the first or last letter to arrive 'late'.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Getting a funded PhD vs starting up my own research idea
What's your opinion on this question? I have MSc in Computer Science (spec. in Natural Language Processing) so I don't need any materials to work with that I can not get by myself. My fears of going into funded PhD is that I would be forced to publish papers that does not scientifically matter or have any impact. I've asked several scientists and they claim that it is called the "salami" effect where instead of publishing one good paper you publish multiple small ones (hence cutting the salami) mainly because the funding body puts pressure on you.
Personally, I would not like to spend 3-4 years doing this but at the same time I am not sure how serious the academic community will take my work. Also, funding my self would probably mean that I have to apply some of my research ideas in bussiness context. I am aware that there is possibility of me submitting research proposal but still I am afraid that some of my ideas will be rejected or stolen.
I've also heard that PhD is not about ideas and it's more about learning to become independent researcher. For some reason, this seems like a very discouraging statement since it lowers the bar about one having higher success with research during his/her PhD studies. I don't think I need this since I've already worked independently for my MSc, albeit I was not 100% satisfied with my results.
By my own research idea, I mean that I have an idea where my research field could be improved and I am curious about whether it will work or not. I have also done some research during my MSc in that particular field. Currently the idea is bit broad and lacks scientific rigour and is not formally defined. To do this, probably it would take me a bit more time to dive deep into the mathematics and figure it out. The idea can also have practical importance which means the method can be used in a Natural Language Processing app like a chat bot (to improve experience for example)
I would really appreciate your opinion on this matter since signing up for PhD seems like big life investment. Thank you.

Any research you are doing is improving the field - whether it is a publication with an impact factor 20 or impact factor 3, and whether it never makes it to publish because it is a "negative result". You are actively innovating. Period. And that is something to be proud of!

Could you describe more what own is?  Do you already have a topic to research?

Thank you both. I updated the question details about what I mean by own research idea.

Most people do externally funded research in order to be able to pay not only equipment and conferences (and later, students), but also in order to pay their landlord and cashier at the supermarket.  Won't you need any of this?

I can live with my parents for a while or I can do a small part time job, it would not be a big issue

Signing up for a PhD is definitely a huge life investment and I am glad you're not taking it lightly. I am getting mine in biological sciences, so we are similar in the length of a program, the funding mechanisms, and the publishing realm. I can't speak from experience of a masters program, though, or from computer science.

When you are getting your PhD you're working with an advisor on their funded projects. Now, that does mean that you are becoming an independent researcher, but I argue that it does not mean that I have not been contributing my own ideas. I am very involved with my experimental design, data collection, and spin off projects. It is like you pick a lab/advisor with a "theme" that you like - and from there, you can develop aims that will complement their focus, but are your own "flavor".
Many funding mechanisms require that you are employed by a university/government/company. Here in the US, this is shown by a DUNS number on your application. Since I have experience only with a university, I do not know of funding mechanisms/grants that are available for those who are not "in the system". Additionally, to get the rather large grants, you must have a PhD and gone through the tenure track.

I have a bit of knowledge of the "spin off" business side of things through a few classes, which makes me wonder maybe you are a great candidate for starting your own company. You could get funding from investors, still work on your own projects, and contribute to the community.
In my field (biological sciences), academic journals would very rarely, if ever, publish you in high tier journals as a MS without a PhD as the corresponding author.
Good luck - I can't stress enough how much I respect you thoughtfully considering your career path this way. I am confident you'll make the right choice for you.

Nice answer but OP refers to self funded.  +1

Thanks for the encouragment. I will try my best to make the right choice.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
WHEN to get teachers and counselors gifts/cards for writing college recs?
I asked two of my teachers for college recommendations towards the end of my junior year in high school. My counselor is automatically going to write a recommendation also. I am assuming they are going to write it over the summer. When should I get them thank you cards/gifts? I have researched all over and have found information on what to give but I don't know when the best time is. Should I give it right after asking them? Or maybe wait until senior year is over? Please help thanks

Sorry, your question is about high school etiquette, but this site is about graduate school and research at universities (and etiquette there tends to be very different from high school). It's not a bad question, just out of the scope of this site. (See the [help/on-topic].)

My preference for thank you's/gifts was to give them after acceptance. That way you can tell them where you were accepted, in addition to expressing thanks for their time! Letter writers are interested in hearing that they are helping you get where you want to go (an added bonus for having their time and effort appreciated)!
My two cents anyway.

authors: Александър Йосифов


text:
Low productivity and diminished mental health
I am a fourth year PhD student in CS department. After experiencing a series of events that transpired, my mental health diminished significantly. I've lost motivation and interest in my work.
Here's the story. After my first year, the faculty member I worked with was found to be committing fraud, and no longer served at the university. He and me had a relatively good relationship. I learnt the event on the local news. No one in the department spoke to me on what to do.
I was confused, and I did not know what to do at the time. I thought the best choice was just to continue looking for advisors. I knew what I topic wanted to do, and I had worked out some results by myself. I asked a faculty member who's most related to the topic, but could not receive any useful advice. Several month later, I found the result I obtained was already found several years ago, by people in a research community outside CS. (The topic I worked on is arguably interdisciplinary. ) I feel the faculty I've been talking to wasn't of much help, as he wasn't even able to point me in the right direction. Perhaps the topic I've worked on does not belong in their specialty.
At this point, my mental health already began to deteriorate, but I tried to keep my faith in research and academia. I also tried branching out and try different topics that might align better with the faculties. Since I had no advisor, I had to learn everything about the basics of research by myself. I also worked on several topics by myself, and uploaded some single authors papers of my work to arXiv. I was happy that my work received some citations.
I branched out and looked into some new research topics, continued looking for advisors, and connected with a faculty member. Several months later, a former student of his reported on social media that the faculty was involved in academic misconduct cases. I was shocked when I learnt this. I am now 2.5 years into my program. My mental health is beginning to deteriorate even quicker.
After 1 more year of struggling, I've just begun my fourth year. I now have an advisor and he seems to have a good personality. I've accepted the fact that I cannot do what I'm truly passionate about at this university, and I've convinced (or at least trying to convince) myself that research isn't about what particular topic I'm working on, but rather it's just a training process where one learns new stuff. My advisor has some topics that he would like me to work on. I wouldn't say I'm passionate about them, but as I've said, I think I'm beyond a point where I have the freedom / privilege to work on whatever I want.
However, my mental state has been in bad shape for a long time and has not begun to recover. I talked to counseling center at my university, but didn't found it to be of much help. Now, I find it extremely hard trusting other people, and I find it extremely hard establishing trusting relationships with faculty members. I have had a bit of phobia of talking to people ever since the faculty I worked with in my first year was found of fraud, and the phobia has gotten worse as time progressed and all these other events transpired. I've gotten to a point where checking messages / emails can be an extremely painful experience: my heart races and breathing becomes heavy, something close to a panic attack. Sometimes I would even be afraid of checking messages from friends and family. In terms of research and work, I find it extremely hard to concentrate and hard to produce results.
I could use some help getting out of this situation. Should I quit my PhD and consider graduating with a Masters degree? Should I continue pursuing research? Is there something wrong with my thinking and should I change my state of mind? Any advice appreciated.

If it's worth anything, it looks to me as if you've played your cards pretty well, so you have that to be proud of. The thing to do now is to take @Buffy's advice below.

And it might be helpful to know you're not alone. Anxiety, depression, etc., are pretty common issues, and I'd imagine more so in intellectually-based careers. You've been through a fight. Get some rest, recover with the help of someone in your corner.

The most important thing, right now, is to talk to a mental health professional. Many universities will provide help for this. At one place I know of, professors in the psychology department are skilled at it also.
Note that what has been done to you isn't your fault. I wonder a bit about the general competence of your faculty, actually. If you aren't in a place that puts a time limit on your degree then get your mental health fixed and then continue, even if it is at a different university. Or, at least, wait until you are able to make more rational decisions before you make any life-affecting ones.
The best, and only valid, advice will come from a professional with whom you can explore your state of mind and the reasons for it.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Is it ethically justifiable to conceal a fatal conceptual flaw in a thesis to avoid an unaffordable 2-year setback if the flaw is the advisor's fault?
A couple of decades ago I graduated from a Russian university with an MS in physics, and my MS thesis contained a critical flaw. In short, the thesis was about static perturbations in a certain physical system, but the system itself is unstable in the very same model, with the instability length being comparable to the characteristic size of the static perturbations in question. The whole investigation didn't make any scientific sense, because the assumed physical system can't be physically realized in the first place.
I discovered the flaw a few months before submitting my thesis. It happened rather accidentally: I wanted to formally prove that the system is stable, but the result of my calculations showed that the opposite is true. I had never heard from my supervisor, who had given me the problem for my thesis, or from his colleagues that the system may be unstable. Everyone simply did not even think about that possibility.
After I discovered the flaw, I faced the dilemma as to what to do about it.
My final choice was to tell no one, even my supervisor, and simply go on to get my MS degree, deliberately failing to mention my stability analysis and its outcome in my thesis and thereby concealing the flaw. I did so because getting my MS degree asap and moving abroad for PhD studies was my highest priority. If I had raised the issue about the flaw, I would have had to start my MS project over, if allowed at all, and spend two more years to get my MS degree.
I should have performed the stability analysis at the very beginning of my MS project, but I didn't, and it's partially a fault of my supervisor, who directed my work in a very rigid way, giving me very specific tasks and deadlines. He never told me to check whether the system is stable. The official research plan, which he and I signed, did not contain any mention of a stability analysis. It was my own initiative to try to prove that the system is stable, because I felt that this was needed to make my investigation complete. I didn't even talk to my supervisor about my idea to perform the stability analysis. After I discovered the flaw, I was sure that if I talked to my supervisor about it, he would say the whole MS project had to be canceled. A product of the Soviet era, he was ruthlessly strict in terms of norms and ethics and had little compassion towards students.
After I submitted my thesis, my supervisor insisted that I write and publish an article based on the thesis. I didn't want to do it, but I had to. After all, I needed good recommendation letters from my supervisor, so I had to obey. The article was published in a reputable American journal and was later cited about 20 times. Writing that article was the most unpleasant experience in my scientific career.
To clarify, neither my thesis nor the paper claimed that the system is stable. That the system is stable was an implicit inherent assumption of the model, and
it was quite a popular model at that time. The model was invented and used for other purposes well before I even started my MS project. That is, my advisor gave me a known model that no one knew to be faulty at the time, and asked me to use it for a new purpose. As explained above, I accidentally discovered and deliberately concealed that the assumption that the system is stable is wrong and can be shown to be wrong in the framework of the very same model, so the model is inherently self-contradictory regardless of the purpose of its use.
As I expected, no one found the flaw, so I successfully got my MS degree in Russia, moved abroad, got a Western PhD degree, and some years later published an article explaining the flaw. In that article, I explicitly wrote that the model and all articles based on it are invalid science. I cited some articles, including my article based on the MS thesis, as examples of invalid science. No one published a comment in response. In private conversations, my colleagues confirmed that my conclusion about the flaw is correct. And the faulty model practically stopped being used after that.
Many years have passed since then, and I have built a solid career and have articles published in Physical Review Letters, even as the first author, but I still feel uneasy about the fact that I started my academic career with a misleading MS thesis and deliberately concealed the flaw in order to graduate smoothly.
I understand that what I did is a research misconduct, but the question I'm still struggling to find the answer to is whether my research misconduct was ethically justifiable under the circumstances. My colleagues say it was, but I'm unsure whether they are frank about it, so I really want to hear what other people have to say. I want truly impartial answers from people who do not know me. This is why I'm posting my question here.
Here are some additional details:

If I had not concealed the flaw, I would almost certainly have not become a scientist at all, because I could not afford two more undergraduate years in Russia. My parents didn't want to help me financially any further, so I had to get my MS degree asap and move abroad. At that time (late 1990s), living in Russia was very hard because of an economic crisis. Besides, even if I had found a way to finance the additional undergraduate years in Russia, the delay of my graduation would have harmed my chances to win the prestigious Western PhD stipend that I won.

Formally speaking, my MS thesis and the article based on it might be seen as not containing any flaw, because I was given a specific physical model and investigated static perturbations within the framework of that model as requested; the fact that the model is faulty is a separate, although related, thing.  The message of my thesis was essentially that if we take that model and make those calculations, we get those results. It was a valid message per se. I was just an undergraduate student who had to do what the supervisor said. He gave me the model and requested certain calculations. I did them absolutely accurately and wrote up the results.

My MS project wasn't a significant research project anyway. It was rather a training project to learn how to do calculations and write up results. Even if the model were not faulty, the article would not have had any considerable impact. No one used the results of that project. People merely cited my paper.

The only harm due to me concealing the flaw was that a number of scientists continued using the same faulty model for other purposes, unsuspecting that the model is faulty. If I had told them that the model is faulty, they would have spent their research efforts for something more useful. But that would have put my own career in danger, because exposing the flaw too early might have resulted in a retraction of my MS degree and a subsequent termination of my PhD studies. I didn't want to take that risk.

Was my research misconduct ethically justifiable under the circumstances? Or should I have reported the flaw right after I discovered it, even at the huge expense explained above? Or what should I have done after I discovered the flaw?

Various clarifications have been edited into the (now very long) post; some answers and opinions have been moved to chat. Please see this FAQ before posting a comment below this one.

Honestly, this sounds more like a philosophical / personal ethics question than an professional ethics question.
The "academic ethics" answers are what you already know: Withholding important relevant information when you publish something is definitely wrong. And, having done that, calling attention to it later (which you did) was the right thing to do.  Beyond that, I think you're left in the messy world of being an imperfect human with competing needs and obligations and motivations.

"...you're left in the messy world..." as are we all.

Just to make the advice formal, you were most likely wrong in not bringing the issue to your advisor when you noticed it. But, given your point 2, that might not have changed anything. On the other hand, it might have delayed your degree while you came to a more complete result.
But, with few exceptions, such as those that literally harm other people, such errors in the past can and should be left in the past. This is especially true if you have learned from them and don't intend to repeat them. Panic is understandable and usually forgivable for such things. In some religions, for example, there is the concept of "forgiveness" that don't require public confessions. No one is perfect. No one always does the right thing. But if we learn from our mistakes we do can better the next time.
So, your ethics at the time are questionable, and you likely committed a violation. But, let it rest.
And, you aren't responsible for the fact that others used the same faulty model. That is on them. Had you developed the model yourself and hid its flaws (misrepresented them) then the issue would be more serious. But if it was accepted at the time then it is an artifact of scientific enquiry.
You may have an opportunity, actually, though it would be awkward to exploit it. If that model is still being used, leading to suboptimal results, you could make your misgivings known. It shouldn't require a confession of guilt to do so either.

You are probably too hard on yourself in point 1.

"And, you aren't responsible for the fact that others used the same faulty model." - you mean, except for publishing that model with a known flaw, and willfully concealing the fact from everybody?

@Steve The model was invented and used for other purposes well before I even started my MS project. My advisor gave me a known model, which no one knew to be faulty at the time, and asked me to use it for a new purpose.

I disagree that it was wrong not to bring it to the adviser, on an absolute scale. What is wrong is a system that would require a student to "do again a thesis" if such a flaw would have been detected.
What is furthermore wrong is the adviser that is forcing him to write a paper.
He is at the end of a chain with a flawed advisor in a flawed system. He did wrong, but definitely less than anyone else in this story.

"You may have an opportunity...  you could make your misgivings known" -- but this was already done by OP: "some years later published an article explaining the flaw. In that article, I explicitly wrote that the model and all articles based on it are invalid science... And the faulty model practically stopped being used after that."

@Mayou36 Let me express my agreement with you. It is often forgotten that the point of a thesis - MSc, PhD, whichever - is NOT to contribute to science. It is to demonstrate the student's ability to conduct proper scientific research. Conducting an in-depth analysis of a system for years, and then making an autonomous discovery that the fundamental physical model, that has seen widespread usage, has an inherent and fundamental flaw that invalidates or limits it - what else could prove this ability more? And yet, the focus is way too often on the result, and not the work.

@Mayou36, re, I don't know and shouldn't assume the OP's pronouns, but it's not obvious that the right pronoun for OP (whose username is 'Sandra') would be 'he'.

@ LSpice I absolutely agree, this is a language bias. "Student" in my native language refers to the male version of student while the female has a different version. My bad!
@Neinstein I can just return it: detecting a flaw in a widely used system as a small sidework you do: amazing! That's the type of student I love! That's someone you can work with in science. As you said, properly, scientifically figure out that longstanding believes in the field are wrong... the ones that did this the most we often can call now "nobel laureants". That's the message a students should learn.

@Steve I thought the same thing. I sometimes read answers here and I'm surprised how often things seem to be someone else's fault. You're a referee and you miss a glaring error in a paper? Well, it's the author's responsibility and how can you be expected to find it? You're only an expert in the field, after all. Publish a flawed paper knowingly? Well, it's really the reader's fault for not checking every detail. Didn't check every detail and cited a paper? Well, who has the time and it got published after experts checked it so it's probably ok. Not your fault.

You had a tough choice to make under difficult conditions. To me what you did seems reasonable, I might have acted similarly in your place.
You did publish the flaw, just not as soon as you discovered it. Unless it was being used in real-life systems and people came to physical harm because of the flaw during that publishing delay, I don't think you have too much to beat yourself up about.
It might have been possible to include the flaw in your thesis (I personally feel it would have made it stronger, not weaker, if other people were using the model without being aware of the flaw), but I guess we'll never know how things would have gone for you if you'd done that.

One option is to focus on the future not the past. Can you do something to make sure no one junior to you is in that position?
An ethical test I was taught is to imagine what you did is one day printed as a scandal story in the New York Times. To put it in a bad light:
"Famous professor concealed fatal flaw in early research study. Morals questioned"
What would you want your truthful response to be?
You could already have in the article:

"Friends of Dr. X note that they were in a precarious position at the
time, not in charge of the direction of the research, and published
their findings once they were in a secure professional position and able to do
so."

But even more than that one might hope to be able to add:

"Students of Dr. X rushed to defend them. 'Dr. X has always run their
lab so that no student would ever be in that position.' The student
continued, 'Dr, X. always has us double-check our studies for those
kind of fundamental flaws, and ensures that anyone whose study does
fall apart just before submission is helped to graduate, or given the
extra funding they need. They have become a champion of data honesty
in the field, and they passionately support journals that help
scientists publish their 'failures' to encourage honesty in research."

I've laid it on a bit thick, and I'm not in the sciences, but hopefully this is helpful: is there something you can do to take the responsibility you feel (earned or not) and pay it forward?

I don't think that your MS thesis has a "fatal flaw".  While I do recognize that being physically possible is nice, it's not necessary.  There is the entire field of abstract mathematics and I've never heard anyone seriously claiming that it's immoral and/or "academic malpractice" to be a mathematician.  You never claimed that it were stable, just that if it is, then it will behave in that way describe by you.
In fact, many contributions to physics are actual physically impossible.  To give my favorite example:  The schwarzschild (simple black hole) solution of general relativity (and the associated properties like the schwarzschild radius) implicitly requires a fully empty universe, which is impossible, still it's well known and important.

Your assumptions about the cost of telling your advisor about the flaw are very likely wrong. Discovering that a widely used physical model is flawed is a contribution which is definitely strong enough for a master thesis. So, to answer your question, you should have told your advisor, submitted your proof of instability as a thesis, received a well deserved excellent grade, and gone on with your career. The second best thing would be to tell them after your graduation was sealed, but before submitting the paper.
Regardless: for a young student, feeling confused and scared about the situation is understandable, and, in legal parlance, it is clearly a mitigating circumstance. It does not nullify the fact that there was a misconduct, though. Even if nobody "used" your result, it did its share of the damage: the more papers about the model are published, the less conceivable it is that it may be invalid. However, by now, if there were any such damage, you have clearly undone it. And even the most heinous crimes, which this one is not, usually have statute of limitation.

Yes, I thought about that at the time and saw a big problem: it takes only a couple of weeks to prove the instability, while my MS project was supposed to be two years long. My discovery of the instability invalidated all the results I had obtained in the previous one-and-a-half years. Those results had already been mentioned in my formal reports on the progress of my MS project. Furthermore, it was a negative result in the sense that a certain model is invalid. Nothing positive. And I might have been blamed for not performing the stability analysis earlier.

The solution you propose might have worked, but, given the rigid bureaucratic system and my close-minded advisor, I highly doubt it would have.

I think the main idea of this answer is an interesting opinion, but not necessarily valid in any given individual case. It is the advisor who decides these things, not we. There is/was serious risk involved.

@Buffy, I agree it's hard to tell not knowing the university and its customs. But the whole system may have seemed more hostile and rigid to a student than it really were. Having studied in Russia at about the same time myself, I've not heard of any examples where a strong student with a publishable result in their thesis was not allowed to graduate. Of course, the atmosphere where you are afraid to tell the advisor is not healthy anyways.

...on general grounds, you cannot assign open research problems as master thesis topics and not have any safety net in the case it doesn't work. I've seen all kinds of failed projects, including e.g. discovering at the last moment that the results of the thesis are not new, and people still graduated...

The general question:

Is it ethically justifiable to conceal a fatal conceptual flaw in a thesis

No, it's not justifiable to do so, regardless of the circumstances.
In some extreme circumstances (e.g. gun-to-your-head, not the circumstances your predicament) it might be excusable, but not justifiable.

to avoid an unaffordable 2-year setback if the flaw is the advisor's fault?

People who are not you, nor your advisor, nor in the same department/university as the both of you, should not have faulty research misrepresented to them because of inter-personal or intra-institutional issues between the authors of the research.

Your specific case
I agree with Ernest Bredar's answer: Your M.Sc. was not fatally flawed. It was somewhat flawed. Not to mention the fact that your analysis might apply in a somewhat-similar situation where the system is stable.

I didn't want to do it, but I had to.

You didn't have to.

I still feel uneasy about the fact that I started my academic career with a misleading MS thesis and deliberately concealed the flaw in order to graduate smoothly.

Luckily, your ethical misdeed did not seem to lead researchers along invalid paths, and once you published the extra paper, you may not have been "absolved", but you cut off the possibility of future "damage" of your action, which is about the best you could hope for.
Yes, you did something wrong. No, you probably would not have lost your M.Sc. over it (AFAICT). You'll just have to acknowledge that you are not a morally perfect person - and also, that not all crimes, let alone misdeeds, are punished; so you can't be purified or excused by suffering or punishment.
Try to use your sense of guilt as a motivator to do right by others, and to encourage your students to be honest and forthcoming, on the one hand, and forgiving on the other. That's a sort of penance, or atonement, that to me seems fitting.

There are already better answers in this thread but as mentioned elsewhere, this is more to do with personal ethics/philosophy. In this sense citing Nietzsche seems pertinent (needless to say, when taken with a grain of salt):

One is healthy when one can laugh at the earnestness and zeal with
which one has been hypnotized by any single detail of our life, and
the bite of conscience is like a dog biting on a stone.

That which happened already happened, and moreover, could not have possibly happened otherwise.
Another point that I didn't see emphasized here is that rather than brooding away and being remorseful about this event, which has absolutely no value after all this time, and what is more, benefits no one, you could actually think of ways of benefiting others to make up for whatever you feel you have to make up for.
Indeed you seem to be in a position to spread some valuable lessons. E.g. you could sensibilise coworkers to be lenient and flexible to students in such situations and, what is more, lecture the students about both sides of the coin as you most clearly elaborate in your questions here.
Finally, it might be worth mentioning (another ethical standpoint) that frequently great things have muddy/dark beginnings. I would highly recommend once studying Heraclitus' unity of opposites.

You are in the clear, provided you have never published anything you knew to be flawed at the time you handed in your final checked page proofs.
The grey area here is that MSc and PhD theses do count as a publication of sorts, although most people will know that there usually are many loose ends and (too) many theses are extremely rough around the edges.
If the thesis is available online or on a shelf in the university, then someone may consult it and be led astray or at the very least waste some of their time. And this something you should feel uneasy about (but not too uneasy... there is a strange herd instinct in academia where everybody keeps working on the same thing everybody else does, long after the flaws have become well known to anyone able to understand the point). You can write a short erratum, outlining that there is an important caveat on the results of the thesis, and ask the library or whoever manages your MSc thesis as a public resource to ensure that the erratum is physically or electronically merged with the thesis.
This is essentially how you would fix a flaw with a publication in a physical journal, where the flaw has become apparent to you after its appearance in the public domain.
There is no logical reason why this should not work, except that you are operating within the Russian system, which can be horribly inflexible and unreasonable...
As to whether you earned the MSc, yes and no. You demonstrated sufficient ability to the satisfaction of the evaluators at the time, so yes. Still, you ought to have had the scientific courage and frankness to inform your supervisor, so no.
You were afraid to speak up at the time fearing it would engender a whole lot of trouble for you with no positive outcome for anyone at the end. I understand that. I have had a Russian PhD student who was traumatised by her former Russian supervisor, and she described him in almost the same words you are describing yours.

Please read the question carefully before posting…in this case, OP states that they did publish an article that they knew to be flawed.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Can e-learning self assesment tools be incorporated in engineering education?
Grading homeworks and continuous inventing of new homework problems is time consuming work. Based on positive homework we run pretest elimination. Eg. students who solve homework can attend semestral examination. Those tools are not enough to make students realize what level of knowledge they posses and the ratio of students writing exams in eg. mechanics classes is very high comparing to total number of those who pass tests.
Can e-learning systems be used to guide engineering students through learning process and which methods have been shown succesful, besides homework assignments? Do selfassesment tests help?

Why have you lmited this to engineering? The use of e-learning and these issues are most likely across the board - it may be other’s experience in different fields is relevant...

Because engineering classes have some specific problems eg. many answers are in form of the sketch, great number of social or other studies deal with written answers, very little sketches.

By sketch are you including first angle projection, third angle projection , isometric as well, do you think artists sketch? Do other classes require diagrams such as biology for example ...

Free body sketches, hand calculations etc.


text:
Hugely important database replete with errors
I am about to finish my PhD in bioinformatics. I am trying not to give out too many details, so I won't be very specific.
In the field I am working in, there are two extremely important databases being used. During my MSc internship, I chose one of the two databases, decided to stick with it and never looked back. However, as my PhD approaches its term, I find more and more errors in this database.
I only contacted the database team once to tell them I thought I had spotted an error and to ask them whether my reasoning was correct. They took more than 2 weeks to reply and only said they had fixed the error without providing other explanations. Intrigued, I looked more closely at the data and started "reverse engineering" the database: I don't know how everything is internally articulated but I start getting a pretty good picture of how they do it. It's a very old and big database that keeps getting bigger and richer. The scientists behind the database are constantly trying out many new things to enrich the data. They keep some changes and discard others.
Now here's the problem: these attempts at enriching the data are badly integrated. The database is never checked for internal consistency. It is highly inconsistent, and I can prove it with a systematic approach. I can point out actual problems and potential problems, with suggestions to discard dangling references.
They also license their data. Some of it is freely available and some of it can be obtained with an academic or a commercial subscription. If they sell their data they might as well sell clean and coherent data!...
Many database maintenance operations seem to be handled manually and with no regard to existing data. Their enrichment methods seem to be based on in-house scripts that the team praises in different publications and that can be used in web forms, but for which the source code is never available. The whole database seems to use a very old and messy design and I have the feeling they never had engineers in their team. The team itself and their research... well, they are not really transparent. The website only has a feedback form. One can never know what problems have already been reported and fixed. There is no changelog. They can change what they please, when they please and in any way they please.
My PhD adviser encouraged me to pursue this investigation and warned me not to contact the database team any more because we will need to figure out what to do. According to my adviser, even though I'm right, this investigation alone does not warrant a publication. In any case, it will at least make a chapter in my PhD thesis.
What I want to obtain is to get these problems fixed. What I would like to obtain, but I don't think it's likely to happen because of the aforementioned lack of transparency, is to get a paper co-published with the authors behind the database, or at least a collaboration for my lab.
Side note: my PhD research is utterly uninteresting and advances a boring method of doing something nobody wants to do and that will therefore never be used. If I manage to link my name to updating and correcting this database, then my PhD will have served a purpose.
Do you have any experience and advice on how to best handle this delicate kind of issue?
EDIT: I want to thank everybody for their contribution. I will select the most helpful answer. The answers and comments I received pointed me to the right direction. I want to make the issues known once I finish writing up my tool on consistency checking. How exactly I will go about making the errors known is something I still need to decide on. A few final notes:

As one of the comments pointed out, it is only fair for the bioinformatics community depending on this database that such errors be known. Maybe making them public will lead some research groups to reevaluate the degree of this dependence.
I did not mean to start a stir on computer science vs engineering.
My PhD is valid and defend-able as it is; it's just not innovative, but that is another story. Pointing out inconsistencies in a public database is not what my PhD is about and will not be used to "save" my PhD as it doesn't need to be saved. :-)

Comments are not for extended discussion; this conversation has been moved to chat.

@user3638629, Re " If they sell their data they might as well sell clean and coherent data"; Hmm, often once you have the word "sell", to them it's all about the "maximize revenue, minimize cost" chant.

There are many critical scientific resources out there that have massive known flaws, but are still useful because the flaws don't prevent people from getting high value from the resources. GenBank, for example, is the predominant source of genetic information in the world and is also known to have many mislabelled sequences.
From what you have written, it is not clear whether something like this is also the case with the resource that you are dealing with.  The course I would recommend you take depends on 1) the degree to which the flaws are known and 2) their degree of impact on scientific conclusions derived from the database. The key cases that I see are:

The flaws are well-known and researchers are able to work around them: Here, there's nothing you really have to do, and the maintainers are unlikely to be particularly responsive to your complaints, since their system is "good enough" and they likely have other priorities.
The flaws are well-known and difficult to work around: This seems the least likely case, as why would people use this database and not the alternative that you mention? If it is so, however, you should probably just finish your thesis and move on: a paper on the flaws isn't interesting if they're already well-known, and while you should report your problems to the maintainers, you'll just be one more instance of the issues they already know about.
The flaws are not well-known and likely to cause serious problems in most research: In this case, a publication about the flaws is likely to be of interest and worth doing. It might or might not cause the database to be fixed, but it is likely to be important to alert researchers using the database to the problems in their work, creating pressure for the database to be fixed or people to migrate elsewhere.
The flaws are not well-known, but not likely to have a serious impact: This is likely to be the case if you are using the database in a very different way than most others, such that your research is more strongly impacted. In this case, talking about it in your thesis seems sufficient. You should document the problems you had and the flaws you discovered, but you are unlikely to get them corrected because you are not their target market.

Notice that in all of these cases, I assume that the database is unlikely to get fixed. That is because the persistence of the problems over time and the non-professional curation that you report indicate an organization that is probably missing either the resources or the incentives to make the fixes you would like, even in collaboration---although you might turn out to be pleasantly surprised.

Very insightful, thanks for this classification. To my knowledge and surprise, there aren't any reports for the problems I identified. So I would say the flaws are not well known. As to impact... I need to reflect on this. The database lends itself to both purely visual and programmatic exploitation. Visual users won't see any problems. Programmatic ones will.

You should contact the person above the database team.
The database that you describe seems to be huge and complicated. As such any modification on it can be relatively big and complicated.
I've already worked in a place with an atrocious database. The relying architecture was simply badly designed. Everyone was aware of it, however we decided to leave it that way.
Why? because improving it meant recreating and redesigning the whole thing and then migrating all of the data from the old one to the new one. We estimated that it would take us months, if not years, of work to end up with a nice database.
At the end of the day, it was decided it was both less expensive and less of a hassle to correct by hand all of the errors created by the database than to improve the underlying system.
Which is to say, that there is a possibility that they are aware of a certain number of these problems but choose not to solve them and not to inform the users as it could leave a bad image. Imagine them answering you :

"We know our database has a lot of problems, but we're fine with it. Too bad for your errors."

Interesting. I can understand the decision to keep an old and bad design if the effort required to rebuild everything is deemed too important. Even if it involves correcting problems manually, as you say. What strikes me, however, is the team in my example not learning from reported errors and not attempting to run checkups to make sure the data is left in a consistent state once modifications are operated.

I’m not sure your advice applies in our field. “The person above the database team” is likely an institute director since the relevant PI will be involved in the database’s creation (if not directly then by association: the database likely doesn’t have a “database team” per se; instead, it will be managed by the researchers themselves), and their purpose is purely administrative.

@KonradRudolph And for smaller or more specific databases, the original "person above the team" might not even be in the team anymore and the whole database might be floating in a futureless "we do what we can" state.

@KonradRudolph The "person above the database team" is whoever controls the purse strings. ;) The point this answer is making is that whoever maintains the DB needs to understand that the DB has flaws that lessen its value to end users so that there is some possibility they might consider addressing it a priority. Whether that means allocating funding, instructing someone to spend the time, or whatever details are involved really don't matter; the point is that someone who can allocate resources has to care before something will be done. That applies in all walks of life.

@jpmc26, thats exactly the idea I meant to get across and probably better explained than what I did.

@everyone If you want to include any wording I used in your answer or paraphrase it or anything of the sort, please feel free. Comments exist primarily for the improve of posts, after all. =) (I do not care if you credit me or not; I tend to find that such credits clutter up the post.)

It is injudicious to describe your own PhD project as boring. It sounds like you are not able to go beyond what is currently known.  Well, it takes all sorts.  Maybe you can teach what is known to those who don't know later.
Anyway I see no gain in getting into conflict with external groups.
You need to quantify what impact the database errors have on the results of your work and ideally show they are minimal or that you can detect them when they occur. And that should be the most minimal part of your presentation. Using that issue to fill an empty void isn't going to pass muster.

Aha ok, I read your question; and here my thoughts. You may like it or not but here they are:
Pure Engineering Is not Research: Ok this might be debatable to some, but if you go to your PhD viva and say well "I fixed the database", you will have a hard time explaining your role as a researcher.
Supervisor Issue: If what you said is the truth, it is the supervisor and his/her to keep the integrity and semantical correctness of the DB. Your supervisor must manage this situation and it is not your job to do so.
What if you cannot do your research with corrupted DB: This is where the head of research group should weigh in and suggest perhaps an extended deadline where you can do your research and finish your thesis.

Thanks for your thoughts. Clarification: my supervisor is not related to the DB team and does not maintain the DB. Pure engineering is not research, true, but too often engineering is brushed aside when research is involved as if it were some kind of unwanted wart. But I digress. My PhD contribution is mainly research but it might contain some engineering aspects such as "I fixed the database".

"Pure engineering is not research": I'm not sure about that. Fixing up a database might not be considered a theoretical development in the bioinformatics world, but it's certainly a very relevant piece of information to be conveyed to the field of researchers that use the database. Thus, it might not be considered "research" in one field, but I would think it should be considered information that should be distributed to the field of researchers that use that database.

"Pure engineering", like restructuring the database so it is properly normalized, probably won't do much for your research career. However, identifying problems with published data--and finding ways to mitigate these--could yield something publishable: @skymningen linked to one such example above.

As a point of evidence that what could be considered "pure engineering" can be considered research, here's a paper in a respected statistics journal that's basically a bug report on Excel.