<p>To answer your question: my experience of using pseudocode is that it works perfectly well in combination with actual code. It would be like a photography teacher explaining the basis of composition by drawing instead of pointing at actual photos. As long as photos that use the rules are shown also, this is great. </p>

<p>Your experience raised a more important concern, one which I think that the other 1010 answers did not address. You said: </p>

<blockquote>
  <p>My experience has been mixed. It seems like the problem is that now
  the students think that the various algorithms <em>are</em> the java code.  </p>
</blockquote>

<p>Indeed. My experience of people has been that there are two kinds:  </p>

<ol>
<li>Those who can generalize about a subject  </li>
<li>Those who can not (yet)</li>
</ol>

<p>I had a student who thought he would be great at programming because he had done a lot of RPG2. His approach was to memorize everything - the book, my lectures, stuff he found on his own... Alas, his brain could not memorize everything. No one's can. We cannot function on the level of detail and master complex things, it is simply impossible. </p>

<p>So, your students who are trying to dig to China with a spoon need to learn to use larger concepts and tools. They need to do this by starting with small concepts and tools, and master them all as they go along. I don't know a single programmer who started out at a high level and never mastered the basics. It is impossible.</p>

<p>A program is nothing more than the coordinated operation of billions of transistors, possibly spread across machines linked by many technologies connected across large geographic areas. A mind is nothing more than the coordinated firing of trillions of nerve cells. But for us to understand, we need to be familiar with all of the levels. I think that this is beyond anyone, but what else do we have to occupy ourselves?</p>

CC BY-SA 4.0
2019-08-07T23:29:08.743Z
2019-08-07T23:40:30.287Z
2019-08-07T23:40:30.287Z
Scott Rowe
<p>"Pseudocode as first language" is a terrible idea. Some of the hurdles a newbie programmer faces is to understand that you have to spell everything out, precisely; that the computer does as told, not as it should; the need for variables (and names, and types/structures) to store data; to organize operations into the right order. Most of that can be glossed over in pseudocode, and there is no compiler/test run that shows mistakes.</p>

<p>Sure, as a help, as a way of sketching solutions for newbies a sort-of-our-language pśeudocode is useful; later, when they have overcome the first round of obstacles, it is an useful tool for design and communication, and the language can take second row seat.</p>

CC BY-SA 4.0
2019-08-08T21:42:29.800Z
2019-08-08T21:42:29.800Z
vonbrand
<p>Similar to @Vince, I think it's a good practice to do both. I don't really agree with the cooking recipe analogy, though. Pseudocode describes that the algorithm does, without going into detail how you do it.</p>

<p>I think perhaps a better analogy:</p>

<ul>
<li>Pseudocode: you need to put an egg into the flour mixture</li>
<li>Actual code: pick up an egg, crack it open on the side of the bowl, and drop the egg into the container. Don't forget you need to dispose the egg shell as well.</li>
</ul>

<p>There are so many ways to accomplish the task, and the actual code just gives the student an example of how to do it.</p>

<p>Presenting only the pseudocode <em>might</em> make some of your students loss. Presenting only the actual code would keep them in the box and get them focused too much on the details. A mixture of both would be my choice.</p>

CC BY-SA 4.0
2019-05-17T01:06:18.147Z
@DavidRicherby Most people in an algorithms course intend to actually write code for a living. There is no reason to deprive them of experience converting problem descriptions to actual code. The skill of making that translation is *fundamental* to being able to do much of anything useful in computing.
jpmc26
CC BY-SA 4.0
2019-05-17T11:51:22.827Z
Something like "you need to put an egg into the flour mixture" isn't "pseudocode." At best, it's a rather vague "user story," in agile-speak. "Pick up an egg" is pseudo-code. The commands you send to your robot chef to achieve that objective is the *actual* code!
alephzero
CC BY-SA 4.0
2019-05-16T08:27:30.527Z
2019-05-16T08:27:30.527Z
Art
<p>Actually I am of the opinion that you should <strong>not</strong> present your own code, but rather get the students to implement the algorithms you teach them, which you give in pseudocode, and give them the freedom to choose any one of a fixed set of languages that you are familiar with, such as C++/Java/Python. Really, the only way students can truly understand an algorithm is when they face the real task of implementing it, but the key ideas behind an algorithm can be sufficiently conveyed via pseudocode.</p>

CC BY-SA 4.0
2019-05-16T23:54:59.250Z
And perhaps even more importantly, don't go about the entire course shoving **one** arbitrarily-chosen programming language down students' throats; specially not Java. That's very off-putting. I've seen complaints about this all too often.
Marc.2377
CC BY-SA 4.0
2019-05-19T03:46:45.863Z
Implementation from pseudo-code is one of the more long term useful skills. Outside an academic algorithm design course, I have rarely needed to create an algorithm from scratch. I have often needed to look one up in various references, and implement it in whatever language I'm currently using.
Patricia Shanahan
CC BY-SA 4.0
2019-05-16T12:41:48.140Z
2019-05-16T12:41:48.140Z
user21820
<ol>
<li><p>Pseudocode helps a lot by removing anything unnecessary, and focusing entirely on the algorithm, which can already be hard to understand as is. It's also faster to express ideas : if a student wants to write a different algorithm than the one you taught them, it can be really cumbersome if they have to deal with every details of Java.</p></li>
<li><p>As others said, it's good for students to come up with their own implementation in code of the pseudo-code algorithm. They need to really understand it, while if they just paste code or learn it by heart they won't necessarily understand every subtlety.</p></li>
</ol>

<p>I think most universities do this already (mine did), but I think the best is pseudocode for the course, and real code for practical exercises.</p>

CC BY-SA 4.0
2019-05-16T15:28:41.797Z
2019-05-17T07:57:10.067Z
Teleporting Goat
<p>One of the key points here is that you are teaching to future <strong><em>engineers</em></strong>, even if at academic level. The very nature of engineering is solving problems by <em>implementing</em> a solution. </p>

<p>Therefore I think that presenting the pseudocode is useful to give your student the correct theoretical POV to frame the problem, BUT showing them an actual, working implementation is key to make them develop their engineering skills. </p>

<p>Much better would be to show them the pseudocode and make them <em>try</em> to come up with an implementation first, then show them yours. But this requires honing their skills first, probably. </p>

<p>As their skills improve, you may also dare show them <em>more than one</em> implementation, possibly in two or more languages. Of course this depends on their actual knowledge of the languages you are going to use. If they know only, say, Java, showing them an additional implementation in another language could backfire and confuse them more.</p>

<p>Of course, I'm assuming that it's not your duty to teach them another computer language, otherwise, it could be a useful approach: start with pseudocode, show a reference implementation in a known language (e.g. Java) and finally show them how to reimplement the algorithm in the new language they must learn.</p>

CC BY-SA 4.0
2019-05-16T15:12:48.870Z
2019-05-16T15:18:47.557Z
LorenzoDonati4Ukraine-OnStrike
<p>Neither alone is enough for a good dish.</p>

<p>I'd go with pseudo code in the lecture, and use homework to give students practice in turning pseudo code into real code.</p>

<p>Using pseudo code in the lecture has the pragmatic reason that pseudo code is, by nature, somehow vague. You want to use it as a tool to be able to concisely state ideas that still contain all important details, but abstract as many of the unimportant ones away.</p>

<p>Because of this, it takes  some time to gauge, as a student, how pseudo your pseudo code actually is allowed to be: <br>
As an example, at the start of the course, pseudo code shouldn't involve a (merge-)sort, but once you're done with that chapter, there's no harm in adding the line "sort the array A" without further explanation.</p>

<p>Therefore I'd say that the easiest way for a student to learn what is, and what is not, allowed in pseudo code, is by getting a feel for it, simply by osmosis over time.</p>

<p>And if some students have problems understanding your pseudo code, then they still have enough resources (books, or even interactive coding sessions of the algorithm) showing them how the algorithms would look like in an actual programming language.</p>

<p>On the other hand, to understand the design and working  of an algorithm, it helps immensely to have coded it yourself, at least partially, once. <br>
Therefore, by letting your students program the algorithm (or letting them finish a partially programmed algorithm) and then tasking them to "play with it", they'll get a good look on the other side of the medal as well.</p>

CC BY-SA 4.0
2019-05-16T18:31:09.410Z
2019-05-16T18:31:09.410Z
Sudix
<p>I see two very different reasons to use pseudo-code.</p>

<p>First, being precise. You want to describe an algorithm in details, without being dependent of the particularities of some programming language. That's the way algorithms are presented in the CS literature. Maybe you avoid a language war, but then, you are dependent of the particularities of your notations anyway, so it sort of defeats its own purpose.</p>

<p>Second, being vague. You want to explain ideas on how to do things, with more or less details.  Maybe what you want to show, is a succession of intermediary steps that lead to an algorithm, and later a program. Because you want to teach, not the version of algorithm X published by Y in 19xx, but <em>how to build</em> algorithms, and this generally requires several steps of refinement with, in the middle, some yet-no-so-well-defined actions.</p>

<p>Pseudo-code allows discussion of approaches to a problem, without solving it entirely. For example the (in)famous  "find the largest difference between 2 elements from an array".</p>

<p>One approach is</p>

<pre><code>largest = 0
for each pair (i,j) of indices
   if the difference between t[i] and t[j] is &gt; largest
       change largest
</code></pre>

<p>and another</p>

<pre><code>find the min and the max of the array
largest is the difference
</code></pre>

<p>such pseudo-code is precise enough to discuss the 2 solutions.</p>

<p>Same kind of discussion about "should we use incomplete/incorrect UML diagrams when teaching" ? </p>

CC BY-SA 4.0
2019-08-07T23:34:14.920Z
Your two pieces of pseudocode for solving a particular problem are an excellent example of how easy and instructive it is to compare algorithms. One requires half of n squared comparisons, the other 2 n comparisons in a linear scan of the array. Very nice.
Scott Rowe
CC BY-SA 4.0
2019-08-09T15:09:28.030Z
The first algorithm is a classical illustration of the "design by keyword" trap. "2 elements" => loop over all pairs.
Michel Billaud
CC BY-SA 4.0
2019-08-10T13:11:48.673Z
If I understand you - it is still early in the day - Anyone who sees "loop over all pairs" and does not immediately see a nested For loop (or equivalent) has never written a program. I didn't even think for one second about it as I read the pseudocode, and I saw that we only have to do the "upper triangle" because there is no point in both comparing x to y and also comparing y to x. But seeing that we only need to capture the max and min as we scan once was pleasant. This is why I find SQL so fascinating. Data is really amazing stuff. I despair of teaching these nuances.
Scott Rowe
CC BY-SA 4.0
2019-08-11T16:06:32.813Z
Blame the hour of the day. The "triangle" enumeration  is sort of a micro-optimization of the "square" (multiplicative factor 0.5 in a quadratic algorithm). The other solution is linear. Anyway the point was about the presentations of solutions, without showing all details.
Michel Billaud
CC BY-SA 4.0
2019-07-22T16:59:18.597Z
2019-07-24T11:36:53.590Z
2019-07-24T11:36:53.590Z
Michel Billaud
<p>I am a young professor teaching a data structures course for the first time. I'm teaching at an engineering college that provides an academic degree, but the focus is preparing future computer programmers, not academics. </p>

<p>Before the start of the semester I decided to present the algorithms as java code, instead of pseudocode. I felt that this would make the presentation more precise, and show the students how to put these algorithms to practical use.</p>

<p>My experience has been mixed. It seems like the problem is that now the students think that the various algorithms <strong>are</strong> the java code. They are complaining that, for example, I can't possibly expect them to know the counting sort algorithm, because how can they be expected to learn code by heart? So I am starting to understand the wisdom of using pseudocode.</p>

<p>My question, intended for other teachers, is: What has been your experience when using pseudocode vs using code?</p>

CC BY-SA 4.0
2019-05-16T21:19:51.253Z
"What has been your experience when using pseudocode vs using code?" -- this is going to get you a list of singular opinions. I recommend you ask for solid evidence instead, e.g. in the form of scientific studies.
Raphael
CC BY-SA 4.0
2019-05-16T21:22:41.567Z
You don't say what your _teaching goals_ are beyond the topic of the course. Those will heavily influence any didactic choice, and may just make the difference here. The background and focus of your students is also relevant, as is the form of exam you're going to hold. Say, some students know Java, others Python, and some C++. How fair is an exam requiring Java skills? How do Java skills reflect on their data structure expertise?
Raphael
CC BY-SA 4.0
2019-07-02T18:25:54.920Z
@Raphael Since this question has been closed here, may I recommend migration to [cseducators.se]?  It would certainly be welcome there.
Ben I.
CC BY-SA 4.0
2019-07-03T15:48:55.077Z
Do you have a standard textbook for the course? Generally I'd recommend following the path of the text; they've probably thought about the issues much longer than you have, tested it, provided resources in that form, etc.
Daniel R. Collins
<algorithms>
Is it a good idea to teach algorithm courses using pseudocode instead of a real programming language?
# Is it a good idea to teach algorithm courses using pseudocode instead of a real programming language?

(Asked by: username_0 on 2019-05-16)

I am a young professor teaching a data structures course for the first time. I'm teaching at an engineering college that provides an academic degree, but the focus is preparing future computer programmers, not academics.

Before the start of the semester I decided to present the algorithms as java code, instead of pseudocode. I felt that this would make the presentation more precise, and show the students how to put these algorithms to practical use.

My experience has been mixed. It seems like the problem is that now the students think that the various algorithms **are** the java code. They are complaining that, for example, I can't possibly expect them to know the counting sort algorithm, because how can they be expected to learn code by heart? So I am starting to understand the wisdom of using pseudocode.

My question, intended for other teachers, is: What has been your experience when using pseudocode vs using code?

**Tags:** algorithms

> **Comments:**
> **username_1**: "What has been your experience when using pseudocode vs using code?" -- this is going to get you a list of singular opinions. I recommend you ask for solid evidence instead, e.g. in the form of scientific studies.  
> **username_1**: You don't say what your _teaching goals_ are beyond the topic of the course. Those will heavily influence any didactic choice, and may just make the difference here. The background and focus of your students is also relevant, as is the form of exam you're going to hold. Say, some students know Java, others Python, and some C++. How fair is an exam requiring Java skills? How do Java skills reflect on their data structure expertise?  
> **username_2**: @username_1 Since this question has been closed here, may I recommend migration to [cseducators.se]?  It would certainly be welcome there.  
> **username_3**: Do you have a standard textbook for the course? Generally I'd recommend following the path of the text; they've probably thought about the issues much longer than you have, tested it, provided resources in that form, etc.  

---

## 8 answers

### Answer by username_6 on 2019-05-16. Score: 38 | Accepted answer

Similar to @Vince, I think it's a good practice to do both. I don't really agree with the cooking recipe analogy, though. Pseudocode describes that the algorithm does, without going into detail how you do it.

I think perhaps a better analogy:

* Pseudocode: you need to put an egg into the flour mixture
* Actual code: pick up an egg, crack it open on the side of the bowl, and drop the egg into the container. Don't forget you need to dispose the egg shell as well.

There are so many ways to accomplish the task, and the actual code just gives the student an example of how to do it.

Presenting only the pseudocode *might* make some of your students loss. Presenting only the actual code would keep them in the box and get them focused too much on the details. A mixture of both would be my choice.

> **Comments:**
> **username_7**: @DavidRicherby Most people in an algorithms course intend to actually write code for a living. There is no reason to deprive them of experience converting problem descriptions to actual code. The skill of making that translation is *fundamental* to being able to do much of anything useful in computing.  
> **username_8**: Something like "you need to put an egg into the flour mixture" isn't "pseudocode." At best, it's a rather vague "user story," in agile-speak. "Pick up an egg" is pseudo-code. The commands you send to your robot chef to achieve that objective is the *actual* code!  

---

### Answer by username_9 on 2019-05-16. Score: 26

Actually I am of the opinion that you should **not** present your own code, but rather get the students to implement the algorithms you teach them, which you give in pseudocode, and give them the freedom to choose any one of a fixed set of languages that you are familiar with, such as C++/Java/Python. Really, the only way students can truly understand an algorithm is when they face the real task of implementing it, but the key ideas behind an algorithm can be sufficiently conveyed via pseudocode.

> **Comments:**
> **username_10**: And perhaps even more importantly, don't go about the entire course shoving **one** arbitrarily-chosen programming language down students' throats; specially not Java. That's very off-putting. I've seen complaints about this all too often.  
> **username_11**: Implementation from pseudo-code is one of the more long term useful skills. Outside an academic algorithm design course, I have rarely needed to create an algorithm from scratch. I have often needed to look one up in various references, and implement it in whatever language I'm currently using.  

---

### Answer by username_12 on 2019-05-16. Score: 6

1. Pseudocode helps a lot by removing anything unnecessary, and focusing entirely on the algorithm, which can already be hard to understand as is. It's also faster to express ideas : if a student wants to write a different algorithm than the one you taught them, it can be really cumbersome if they have to deal with every details of Java.
2. As others said, it's good for students to come up with their own implementation in code of the pseudo-code algorithm. They need to really understand it, while if they just paste code or learn it by heart they won't necessarily understand every subtlety.

I think most universities do this already (mine did), but I think the best is pseudocode for the course, and real code for practical exercises.


---

### Answer by username_13 on 2019-05-16. Score: 6

One of the key points here is that you are teaching to future ***engineers***, even if at academic level. The very nature of engineering is solving problems by *implementing* a solution.

Therefore I think that presenting the pseudocode is useful to give your student the correct theoretical POV to frame the problem, BUT showing them an actual, working implementation is key to make them develop their engineering skills.

Much better would be to show them the pseudocode and make them *try* to come up with an implementation first, then show them yours. But this requires honing their skills first, probably.

As their skills improve, you may also dare show them *more than one* implementation, possibly in two or more languages. Of course this depends on their actual knowledge of the languages you are going to use. If they know only, say, Java, showing them an additional implementation in another language could backfire and confuse them more.

Of course, I'm assuming that it's not your duty to teach them another computer language, otherwise, it could be a useful approach: start with pseudocode, show a reference implementation in a known language (e.g. Java) and finally show them how to reimplement the algorithm in the new language they must learn.


---

### Answer by username_14 on 2019-05-16. Score: 4

Neither alone is enough for a good dish.

I'd go with pseudo code in the lecture, and use homework to give students practice in turning pseudo code into real code.

Using pseudo code in the lecture has the pragmatic reason that pseudo code is, by nature, somehow vague. You want to use it as a tool to be able to concisely state ideas that still contain all important details, but abstract as many of the unimportant ones away.

Because of this, it takes some time to gauge, as a student, how pseudo your pseudo code actually is allowed to be:   
As an example, at the start of the course, pseudo code shouldn't involve a (merge-)sort, but once you're done with that chapter, there's no harm in adding the line "sort the array A" without further explanation.

Therefore I'd say that the easiest way for a student to learn what is, and what is not, allowed in pseudo code, is by getting a feel for it, simply by osmosis over time.

And if some students have problems understanding your pseudo code, then they still have enough resources (books, or even interactive coding sessions of the algorithm) showing them how the algorithms would look like in an actual programming language.

On the other hand, to understand the design and working of an algorithm, it helps immensely to have coded it yourself, at least partially, once.   
Therefore, by letting your students program the algorithm (or letting them finish a partially programmed algorithm) and then tasking them to "play with it", they'll get a good look on the other side of the medal as well.


---

### Answer by username_15 on 2019-07-22. Score: 3

I see two very different reasons to use pseudo-code.
First, being precise. You want to describe an algorithm in details, without being dependent of the particularities of some programming language. That's the way algorithms are presented in the CS literature. Maybe you avoid a language war, but then, you are dependent of the particularities of your notations anyway, so it sort of defeats its own purpose.
Second, being vague. You want to explain ideas on how to do things, with more or less details.  Maybe what you want to show, is a succession of intermediary steps that lead to an algorithm, and later a program. Because you want to teach, not the version of algorithm X published by Y in 19xx, but how to build algorithms, and this generally requires several steps of refinement with, in the middle, some yet-no-so-well-defined actions.
Pseudo-code allows discussion of approaches to a problem, without solving it entirely. For example the (in)famous  "find the largest difference between 2 elements from an array".
One approach is
largest = 0
for each pair (i,j) of indices
   if the difference between t[i] and t[j] is > largest
       change largest

and another
find the min and the max of the array
largest is the difference

such pseudo-code is precise enough to discuss the 2 solutions.
Same kind of discussion about "should we use incomplete/incorrect UML diagrams when teaching" ?

> **Comments:**
> **username_4**: Your two pieces of pseudocode for solving a particular problem are an excellent example of how easy and instructive it is to compare algorithms. One requires half of n squared comparisons, the other 2 n comparisons in a linear scan of the array. Very nice.  
> **username_15**: The first algorithm is a classical illustration of the "design by keyword" trap. "2 elements" => loop over all pairs.  
> **username_4**: If I understand you - it is still early in the day - Anyone who sees "loop over all pairs" and does not immediately see a nested For loop (or equivalent) has never written a program. I didn't even think for one second about it as I read the pseudocode, and I saw that we only have to do the "upper triangle" because there is no point in both comparing x to y and also comparing y to x. But seeing that we only need to capture the max and min as we scan once was pleasant. This is why I find SQL so fascinating. Data is really amazing stuff. I despair of teaching these nuances.  
> **username_15**: Blame the hour of the day. The "triangle" enumeration  is sort of a micro-optimization of the "square" (multiplicative factor 0.5 in a quadratic algorithm). The other solution is linear. Anyway the point was about the presentations of solutions, without showing all details.  

---

### Answer by username_4 on 2019-08-07. Score: 1

To answer your question: my experience of using pseudocode is that it works perfectly well in combination with actual code. It would be like a photography teacher explaining the basis of composition by drawing instead of pointing at actual photos. As long as photos that use the rules are shown also, this is great.

Your experience raised a more important concern, one which I think that the other 1010 answers did not address. You said:

> My experience has been mixed. It seems like the problem is that now
> the students think that the various algorithms *are* the java code.

Indeed. My experience of people has been that there are two kinds:

1. Those who can generalize about a subject
2. Those who can not (yet)

I had a student who thought he would be great at programming because he had done a lot of RPG2. His approach was to memorize everything - the book, my lectures, stuff he found on his own... Alas, his brain could not memorize everything. No one's can. We cannot function on the level of detail and master complex things, it is simply impossible.

So, your students who are trying to dig to China with a spoon need to learn to use larger concepts and tools. They need to do this by starting with small concepts and tools, and master them all as they go along. I don't know a single programmer who started out at a high level and never mastered the basics. It is impossible.

A program is nothing more than the coordinated operation of billions of transistors, possibly spread across machines linked by many technologies connected across large geographic areas. A mind is nothing more than the coordinated firing of trillions of nerve cells. But for us to understand, we need to be familiar with all of the levels. I think that this is beyond anyone, but what else do we have to occupy ourselves?


---

### Answer by username_5 on 2019-08-08. Score: 1

"Pseudocode as first language" is a terrible idea. Some of the hurdles a newbie programmer faces is to understand that you have to spell everything out, precisely; that the computer does as told, not as it should; the need for variables (and names, and types/structures) to store data; to organize operations into the right order. Most of that can be glossed over in pseudocode, and there is no compiler/test run that shows mistakes.

Sure, as a help, as a way of sketching solutions for newbies a sort-of-our-language pśeudocode is useful; later, when they have overcome the first round of obstacles, it is an useful tool for design and communication, and the language can take second row seat.


---

