# Should the first Programming/Algorithms class be taught in pseudo-code?

When I was studying, my professors had different approaches when teaching programming to beginners:

• Choose a language with which the professor is comfortable and fulfills the course requirements but might not be so popular in the real world. I had this experience with Mathematica programming. We would spend lots of time dealing with this language and as a result less time dealing with the programming language per se.

• Teach in a flavor of pseudo-code. This makes it "harder" to commit errors cause by compilers, interpreters and syntax in general and allows the students to focus in the problem. Naturally has the disadvantage that you can't run your code anywhere.

What do most professionals and students prefer when teaching/learning algorithms and basic programming?

• would you consider flowcharts (like if/else flows) as a flavor or pseudo-code? May 23, 2017 at 14:57
• It seems to me that you need some programming language to actually run things and test ideas. It is one thing to understand what makes something work and another to actually execute it. May 23, 2017 at 15:07
• Are we talking elementary school, high school, university, adult education? Programming or Algorithm class? May 23, 2017 at 15:24
• The question can help to give some ideas about what the 'no-programming language' approach looks like: cs.stackexchange.com/questions/29830/… . May 25, 2017 at 22:00
• I second that this question should distinguish between basic programming or a basic algorithms, as both the audience and the learning goals often differ: does the student want to design algorithms or does the student want to do more programming? (Although the tasks are related, they are quite different still) May 25, 2017 at 22:08

# Yes, the first algorithms class should be taught in pseudo-code

(And teach logic tables too.)

If the objective of the class is to teach algorithms and programming, not a programming language, the pseudo-code is the way to focus on the objectives, not the tools. Flow charting can be included, but need not be either.

Programs written in pseudo-code don't have syntax errors, or compile-time errors. They don't have strict type-classing or confusingly abbreviated function names. They only have logic and design.

After a program is written in pseudo-code it can be "run" on your desktop, the real one, not the metaphor created by Xerox (yes, Xerox, in 1970). Doing such a so-called "Hand-check" helps find logic errors and develops a better understanding of programming theory than jumping right into a formal language, no matter how "simple" it is. It's also a convenient skill to have as a functioning programmer for the occasions when logic error do get compiled and the environment does not include a step debugger. Some employers still test for that skill. (see the University of Kent's remarks.)

For simple instruction on how to hand-check code see this from Dr. John Dalbey of CalPoly.

Lastly, to allow a veteran educator to weigh in I'll mention the blog of Alfred Thompson about Hand-checking.

Until computers can do what we mean we have to live with them doing what we tell them, and that's going to involve errors in how we say what we mean.

• This is the first answer I've seen that took on a first algorithms class, which is very different from a first programming class.
– Ben I.
May 30, 2017 at 12:09
• All I did was read the title. May 30, 2017 at 12:10
• @ecc You can teach programming without using the "word" algorithm, or the concepts behind it, but programs are algorithms. Doing so, however, short changes the students in both their programming skills and their life skills. Conversely, teaching algorithms does not require programs, or computers. A cake recipe is an algorithm, as is any set of instructions to do anything. Check out Wikipedia. May 31, 2017 at 12:29
• That's in response to part of what you comment to Choirbean above, about not teaching algorithms without programming. And sometimes "recipe" is used in computers anyway, such as the *nix make/build process is commonly called a recipe. May 31, 2017 at 12:38
• On the use of 'algorithm': computers were constructed to rapidly, reliably and automatically perform existing algorithms that were done by hand. Not realizing that amounts to not knowing what a computer is. It is a tool, to do things that we know how to do, but which are too time-consuming or taxing to be done by hand, just like a bulldozer does what we could do with shovels, and a car takes us places we could walk. I fear that the whole concept of automation has already become such a 'given' that people will start saying foolish things. 'Computer' used to be a job title.
– user737
Jun 16, 2017 at 13:29

No, it shouldn't. It's an appealing idea, but when kids are just starting in programming, one of the few straws they have to grasp at is that it is, on some level, very concrete. I type:

std::cout << "Hello World!";


... and out prints "Hello World!". Without the ability to run and troubleshoot code, I'm afraid that everything will become abstract, and most students will simply flounder.

You can choose a language with easier syntax, such as Python, or a visual language like Scratch, but the kids really need something to actually run and manipulate if they are to make early progress.

• The code example here is just way too abstract for a beginner IMO. May 23, 2017 at 15:26
• If you're teaching a first "Hello World" program, there will often be mysterious syntax that the kids won't understand at first. System.out.println("hello world");, printf("hello, world\n");, putStrLn "Hello World", pick your poison.
– Ben I.
May 23, 2017 at 15:33
• And this is a big problem. You will want to keep the number of exotic symbols to a minimum. Why ::, not just :? What is <? What is std and why not just call it Standard then? "I saw my brother use = when he was programming, was he doing it wrong?" Etc... There is a difference between a brainfuck code and print "hello world" or program HelloWorld; begin writeln('Hello World'); end.. Human readability is important. May 23, 2017 at 15:40
• You say the ability to compile is important. But why? As someone learning how programming works, the different programming paradigms, etc, why is it important that I deal with compiling code? An interpreted language seems much more practical. I hated when I had to spend so much time fixing my Eclipse setup to make it build my Java project so I could focus on the task at hand.
– ecc
May 24, 2017 at 7:48
• I was being super informal with the word "compile" and casting a large umbrella to indicate both, which is not technically correct. Plus the whole statement was stronger without it, so I removed the word.
– Ben I.
May 24, 2017 at 10:35

Textual programming languages exist to help humans write instructions for computers.

Given how many of them we now have access to, you should be able to find at least one, somewhere, that fits with the experience level and understanding of your students, and the set of problems you want them to work with or solve.

Pseudo code's main role at the moment appears to be for bridging the gap between programmers who are fluent in incompatible languages and need a way to express ideas that both of them can understand. That's not the situation with new programmers starting to learn, IMHO.

I think this heavily depends on the environment. Is this a science university? A middle school? An engineering high school?

Pseudo code has its uses. At university level, with years of programming to come, you should use pseudo code - they will need to learn it anyway, and they need to understand the theory without strongly connecting it to one programming language - mostly because all programming languages have their unique idiocy, and it is hard for a beginner to distinguish between the language being weird or the algorithm being complicated.

If you are teaching kids at elementary/middle schools, then pseudo code is just not rewarding enough. It still has its uses though. For example have them write a pseudo code for each other to use a vending machine (1: select beverage, 2: press button, 3: insert coin, 4: repeat until credit=price etc.). Can be a good introduction to the whole concept.

The problem is that by teaching algorithms through an actual programming language, you are also teaching the language itself. So, like I said, this heavily depends on the environment and the goal of the course.

• While this is not the most popular question so far, I think I like this one the best
– ecc
May 24, 2017 at 11:41

No, classes should favor actual programming languages.

Ideally, students should should be able to:

• Run code examples.

• Apply code analysis tools to code examples, both to better understand the examples and to become familiar with code analysis.

• Experiment with modifying code.

However, it's important to select a reasonable language. Unfortunately some instructors select pet esoteric or proprietary coding systems out of personal preference. While it's true that students should be able to apply the same skills to the languages that they actually care about, it's a huge disservice.

A good default language for a course should be:

• High-level, unless the course is specifically on low-level concepts.

• Provides benefits like pseudo-code while still being real.
• Be free to work with using reasonable tools.

• Good examples include Java and C#.

• Bad examples include Mathematica and Matlab.

• Have helpful, easy-to-use debugging tools.

• Students shouldn't have to wonder about why the code doesn't compile or where the mistake in their code is.
• Very quick compile times, so students can do rapid trial-and-error.

• Generally, prefer strongly typed languages, and avoid unsafe operations.

Personally I'd go for Visual Studio 2017 with C#. Or, if a significant portion of students use Linux/Apple, then fallback to Java.

• I would strongly advise against locking students to a vendor off the bat. Notice I'm not implying students are CS students. You can teach CS to other engineering students, for instance. My Mechanical Engineering friends had some programming and algorithms courses where they did algorithms is pseudo code on paper and also some exercises and projects in Visual Basic.
– ecc
May 24, 2017 at 7:45

Pseudo-code feels like one of those things invented before I learnt to code, as a response to the complexity of reading and to a lesser extent writing code in assembler (or even machine code).

When it was impossible to explain a program without recourse to explaining every single term (starting with 'every line needs a number, start off with increments of 10 so you can add more in later'), it made sense to start the explanations with a less formally structured code.

Now, code can be written using drag-and-drop templates, or in fairly readable readable language (with beginner friendly error handling) so there is really no need to introduce pseudo-code.

Where pseudo code still makes sense is in a scenario where you need a formalised but more abstract language - for example the architectural definition of an instruction set. Something which you want to be able to write a formal parser for, and still retain human readability.

Perhaps students should be required to at least learn to read pseudo-code.

Some algorithms or concept are unsuited for clear expression in some languages (e.g. the ones pre-requisite for the course). Those concepts might be more simply explainable using a pseudo-code that does not require the clutter of a lot of syntactic sugar or other gymnastics.

Perhaps they should be allowed pseudo-code for exam or quiz questions in those areas as well.

Pseudo-code is not an option. You have to have it.

The purpose of such a course is not about the expression of algorithms in a nearly ready to run form. It is about the work involved in their development. The strategies you use. The ideas you consider, try and abandon as they don't seem so good.

So how could we use a formal language to write down fuzzy ideas ?

Given a problem, like "compute how many leap years there are between y1 and y2", you have to try different ideas. And these ideas are not yet wholly developed. So it is much too early to put them under the form of code.

But you still have the need to keep the ideas in written form, if you want to remember/transmit them.

An idea may be

A. test all years between y1 and y2
count these that are leap years


another could be

B. use a formula about multiples of 4, 100 and 400.


This is not supposed to be a complete description of the final algorithm. But it is an idea which has to be written, as a first step of the work.

A second step would be to give more details. For the second solution :

B.1 use a formula f for leap years from year 0 to y
compute the difference  f(y)-f(0)


An a third step

B.2 f(y) = number of multiples of 4
- number of multiples of 100
+ number of mltiples of 400


A decent ready-to-program version emerges only now

B.3 function leap_years_from_0 (y)
=  (y / 4) - (y / 100) + (y / 400)

function leap_years_between(y1, y2)
=  leap_years_from_0(y2) - leap_years_from_0(y1)


In such a course, the important point is the journey between the problem and the solutions. It is not the exposure of algorithms/programs in there final version.

It is possible to teach algorithms in particular, and a lot about programming in general using a pseudocode. However, the pseudocode needs a firm definition or else it can lead to sloppy thinking. If a student is permitted to make "statements" in the pseudocode that imply, for instance that P=NP, then the statement isn't worth much, nor is the "algorithm" so expressed.

I'll note that Edsger Dijkstra wrote most of his papers in pseudocode, but it was carefully defined. David Gries wrote his famous book The Science of Programming using this same pseudocode.

However, each statement in the language (even the empty statement skip) was carefully defined using pre and post-conditions so that the effect of the statement and resulting programs were precisely defined. And even the pre and post-conditions are precisely defined.

This language (pseudo-laguage) can be fairly easily translated into other imperative languages, but it is harder to take advantage of the features of other paradigms such as functional or object-oriented.

So, yes, it can be done. It has been done. It has been done by masters. But it isn't a lot easier than using a "real" language. It has quirks, like any language. Some programs are harder than others, of course. It is even possible to write a compiler for Dijkstra's language (I've done so, actually), making execution possible. However, the reason for the language wasn't execution, but precise clarity of expression of algorithms with precise semantics.

One possible problem with learning algorithms this way, however, is the the resulting pseudo-programs tend to be rather monolithic. Complex programs have long statements with lots of structure. The method, if not carefully used, seems to de-emphasize building complex things out of small interacting parts. This isn't inherent in using pseudo-code, but the instructor needs to be careful about the use so that complexity doesn't overwhelm understanding. But the same is true in real languages. Not everything needs to be done in main.