<p>In my opinion, you shouldn't.</p>

<p>Whether it's true or not is debatable, but that's not the point. When you teach every "punch line" or "guiding line" should have a reason behind it. Why are you telling them this equation? What are they suppose to take away from it? What are you trying to achieve by telling them that?</p>

<p>If you are trying to explain what are programs to newbie students, in my opinion there are better ways nowadays to make this field more approachable, because today, they already know what programs are whether they know it or not. Because there are programs all around them.
I would go with showing them examples of these kind of programs and linking the common denominator. For example, in a way every app, website, online service, video game, smart watch, microwave etc... is a program.</p>

<p>Not only is this a more approachable abstraction, it makes it more exciting. If you can get a student to say "Wow, I can make THAT?" you've done your job.</p>

CC BY-SA 4.0
2018-05-09T15:54:26.033Z
2018-05-09T15:54:26.033Z
Yftach
<p>With one possible exception (<a href="https://en.wikipedia.org/wiki/Quantum_computing" rel="nofollow noreferrer">Quantum Computing</a>), I think that Wirth's observation is as valid today as when he wrote his book.</p>

<p>Don't however, confuse how one builds a thing with the thing itself. We work differently than we did in 1976, but not radically so. Even then, programmers and systems designers used a methodology. Back then it was called Structured Programming and almost all modern languages were influenced by those ideas. A  program was conceptualized as a composition of simpler "programs" according to a well-defined set of rules. </p>

<p>In object-oriented programming we still think of composition, though in a different way and we have a somewhat different set of rules. But the main framework is the same. </p>

<p>Likewise the daily practices of programmers has changed. In the past it was system test and code walk-throughs. Now it is unit tests and pair programming. But we still need to find and use practices that assure us that we have (a) built the correct thing and (b) built the thing correctly. Design Patterns help with this, but they still deal with the algorithms and how they modify and extract information from data. </p>

<p>Prolog isn't really very different. In a data structures course in Java, you deal with data that is relatively simple and write algorithms that may have some complexity. In Prolog it is reversed. You have a given algorithm (unification) and you tailor the (possibly complex) data to enable it. But it is still data + algorithms.</p>

<p>One thing that has changed, however, is that the problems that we solve now are more complex and often more flexible than those of interest in 1976. We have learned how to solve those problems and so we incorporate the solutions into libraries and then solve more complex problems, such as scaling for the cloud. But the essence is the same. </p>

<p>It doesn't matter whether you quote the title of the book, of course, nor should you give the complete history of computing to beginners, but they should understand the fundamental idea. </p>

<hr>

<p>I don't actually know enough about Quantum Computing to say that it is different, but it is the only possible exception that I know anything about. It is possible that it will change the game fundamentally. </p>

CC BY-SA 4.0
2018-05-10T12:25:15.053Z
Quantum computers are supposedly Turing complete, and no more. So just different algorithms, to take advantage of the hardware.
ctrl-alt-delor
CC BY-SA 4.0
2018-08-02T18:25:56.040Z
Take a peek at an off-the-beaten-path language like FORTH. It intertwines data and code.
vonbrand
CC BY-SA 4.0
2018-05-09T16:47:27.053Z
2018-05-09T16:47:27.053Z
Buffy
<blockquote>
  <p>Will you tell students that Algorithms + Data Structures = Programs now (21st century)?</p>
</blockquote>

<p>For an introductory course in a procedural or object oriented class I could see me mentioning that and then expanding on it, but in a functional or logic class it would be a footnote.  </p>

<p>For Prolog I note <a href="https://cs.stackexchange.com/questions/6618/how-to-implement-a-prolog-interpreter-in-a-purely-functional-language/6622#6622">Prolog = Syntactic Unification + Backward chaining + REPL</a> </p>

<p>The statement "Algorithms + Data Structures = Programs" is still valid as a bases for understating procedural programs, but that programming is more than just writing programs. To me your questions is people confusing syntax with semantics. In other words they are taking the word <code>Program</code> to mean <code>Programming</code> and I don't see it that way. A Program is part of programming, but programming is more than a program and in that sense I can agree with what people are thinking but disagree with them in their disagreement with that statement.</p>

<p>They should come up with a new statement like<br>
<code>Programming = Programs + Version Control + Test Cases  + Continuous Integration + Documentation</code>.  </p>

<p>Along those same lines there should also be one for functional programming like<br>
<code>Functional Programs = Algebraic data types + Pattern matching + Lambdas + Catamorphism</code></p>

<p>To move the concept of programming forward I don't feel test cases should be a part of programming but that programs should be provable and thus obviate the need for test cases and thus bugs, e.g. <a href="https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence" rel="nofollow noreferrer">Curry–Howard correspondence</a> or <a href="https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence#Curry%E2%80%93Howard%E2%80%93Lambek_correspondence" rel="nofollow noreferrer">Curry–Howard–Lambek correspondence</a></p>

CC BY-SA 4.0
2018-05-10T01:50:48.477Z
I also think these theories you mentioned at the bottom) are important, but in the production environment, its cost may be too high, you know. Some interviewer sometimes asks the interviewee to give reasonable test case(at least in Chinese).
Li Chen
CC BY-SA 4.0
2018-06-21T21:38:45.633Z
You have a limited notion of "functional programming". Also ironically you give unnecessarily procedural semantics for Prolog. I agree the poster's "fundamentists" are misreading "programs" as "programming".
philipxy
CC BY-SA 4.0
2018-05-09T15:45:04.470Z
2018-05-09T15:50:57.693Z
2018-05-09T15:50:57.693Z
Guy Coder
<p>The Wirth formula, <strong>Algorithms + Data Structures = Programs</strong> is still valid. It is also complete. A program is nothing more than algorithms acting on data structures. That formula does not make <em>explicit</em> the difference between a bad, error-riddled program and a good, error-free efficient program. Looking at the formula, however, can show how to improve the first and make it into the second.</p>

<p>Stating that programs are built of exactly two components, data structures and algorithms, means that the only way to improve a program is to improve one, or both, of its components.</p>

<blockquote>
  <p><strong>Algorithms + Data Structures = Programs</strong><br>
  <strong><em>Sloppy</em> Algorithms + <em>Mediocre</em> Data Structures = <em>Buggy</em> Programs</strong><br>
  <strong><em>Better</em> Algorithms + Data Structures = <em>Better</em> Programs</strong><br>
  <strong><em>Excellent</em> Algorithms + <em>Efficient</em> Data Structures = <em>Superior</em> Programs</strong>.</p>
</blockquote>

<p>The <em>Science</em> part of <em>Computer Science</em> in programming is finding the way to create the better, or excellent, algorithms and develop the efficient data structures. That's where the skills, whatever the instructor wants to focus on, come in to effect. Design patterns help to sort out the options, and provide an established pattern to follow when creating a new algorithm or data structure. Unit testing helps to validate the operational correctness of the written code. Low level knowledge of the target system <em>may</em> allow the coder to increase efficiency, and low level knowledge of the chosen language <em>might</em> allow the coder to utilize "tricks" or "quirks" built in to the language (be they bugs or features is unimportant).</p>

<p>Bottom line is that the only way to make a <strong>program</strong> better is to make its components better. There are only two components to work with; <em>data structures</em> and <em>algorithms</em>.</p>

<blockquote>
  <p>Will you tell students that <strong>Algorithms + Data Structures = Programs</strong> now(21st century)? </p>
</blockquote>

<p>Not only will we tell students that, we should have that on the door lintel
of every classroom and lecture hall where programming is taught.</p>

CC BY-SA 4.0
2018-05-09T16:05:15.697Z
2018-05-09T16:05:15.697Z
Gypsy Spellweaver
<p><strong>Algorithms + Data Structures = Programs</strong> occurs in 1976 (in Niklaus Wirth's book). In the past, we (teachers) may usually cite this equation to emphasize the importance of algorithms/data structures.</p>

<p>But, as far as I know, some <strong>fundamentalists</strong> don't agree on it. They think this equation is out of date and is possible to mislead students into overlooking other skills' significance (like unit test, design pattern, low-level knowledge...). </p>

<p>So, what do you think? Will you tell students that <strong>Algorithms + Data Structures = Programs</strong> now(21st century)? </p>

CC BY-SA 4.0
2018-05-09T18:08:37.450Z
From my experience of training adults to get jobs as programmers over the last few years, the equation looks much more like: bool hireableCandidate = computerFluency AND generalBusinessKnowledge AND multipleHighLevelLangs AND databaseDesign AND sqlExperience AND dataAccessProgramming AND windowsProgramming AND otherOSexperience AND webProgramming AND unitTesting AND pairProgramming AND teamSkills AND *-- System halted: Candidate Lifetime exceeded --*
user5106
<algorithms>
Will you tell students that Algorithms + Data Structures = Programs now(21st century)?
# Will you tell students that Algorithms + Data Structures = Programs now(21st century)?

(Asked by: username_0 on 2018-05-09)

**Algorithms + Data Structures = Programs** occurs in 1976 (in Niklaus Wirth's book). In the past, we (teachers) may usually cite this equation to emphasize the importance of algorithms/data structures.

But, as far as I know, some **fundamentalists** don't agree on it. They think this equation is out of date and is possible to mislead students into overlooking other skills' significance (like unit test, design pattern, low-level knowledge...).

So, what do you think? Will you tell students that **Algorithms + Data Structures = Programs** now(21st century)?

**Tags:** algorithms

> **Comments:**
> **username_1**: From my experience of training adults to get jobs as programmers over the last few years, the equation looks much more like: bool hireableCandidate = computerFluency AND generalBusinessKnowledge AND multipleHighLevelLangs AND databaseDesign AND sqlExperience AND dataAccessProgramming AND windowsProgramming AND otherOSexperience AND webProgramming AND unitTesting AND pairProgramming AND teamSkills AND *-- System halted: Candidate Lifetime exceeded --*  

---

## 4 answers

### Answer by username_8 on 2018-05-09. Score: 9 | Accepted answer

The Wirth formula, **Algorithms + Data Structures = Programs** is still valid. It is also complete. A program is nothing more than algorithms acting on data structures. That formula does not make *explicit* the difference between a bad, error-riddled program and a good, error-free efficient program. Looking at the formula, however, can show how to improve the first and make it into the second.

Stating that programs are built of exactly two components, data structures and algorithms, means that the only way to improve a program is to improve one, or both, of its components.

> **Algorithms + Data Structures = Programs**  
> ***Sloppy* Algorithms + *Mediocre* Data Structures = *Buggy* Programs**  
> ***Better* Algorithms + Data Structures = *Better* Programs**  
> ***Excellent* Algorithms + *Efficient* Data Structures = *Superior* Programs**.

The *Science* part of *Computer Science* in programming is finding the way to create the better, or excellent, algorithms and develop the efficient data structures. That's where the skills, whatever the instructor wants to focus on, come in to effect. Design patterns help to sort out the options, and provide an established pattern to follow when creating a new algorithm or data structure. Unit testing helps to validate the operational correctness of the written code. Low level knowledge of the target system *may* allow the coder to increase efficiency, and low level knowledge of the chosen language *might* allow the coder to utilize "tricks" or "quirks" built in to the language (be they bugs or features is unimportant).

Bottom line is that the only way to make a **program** better is to make its components better. There are only two components to work with; *data structures* and *algorithms*.

> Will you tell students that **Algorithms + Data Structures = Programs** now(21st century)?

Not only will we tell students that, we should have that on the door lintel
of every classroom and lecture hall where programming is taught.


---

### Answer by username_2 on 2018-05-09. Score: 3

In my opinion, you shouldn't.

Whether it's true or not is debatable, but that's not the point. When you teach every "punch line" or "guiding line" should have a reason behind it. Why are you telling them this equation? What are they suppose to take away from it? What are you trying to achieve by telling them that?

If you are trying to explain what are programs to newbie students, in my opinion there are better ways nowadays to make this field more approachable, because today, they already know what programs are whether they know it or not. Because there are programs all around them.
I would go with showing them examples of these kind of programs and linking the common denominator. For example, in a way every app, website, online service, video game, smart watch, microwave etc... is a program.

Not only is this a more approachable abstraction, it makes it more exciting. If you can get a student to say "Wow, I can make THAT?" you've done your job.


---

### Answer by username_3 on 2018-05-09. Score: 3

With one possible exception ([Quantum Computing](https://en.wikipedia.org/wiki/Quantum_computing)), I think that Wirth's observation is as valid today as when he wrote his book.

Don't however, confuse how one builds a thing with the thing itself. We work differently than we did in 1976, but not radically so. Even then, programmers and systems designers used a methodology. Back then it was called Structured Programming and almost all modern languages were influenced by those ideas. A program was conceptualized as a composition of simpler "programs" according to a well-defined set of rules.

In object-oriented programming we still think of composition, though in a different way and we have a somewhat different set of rules. But the main framework is the same.

Likewise the daily practices of programmers has changed. In the past it was system test and code walk-throughs. Now it is unit tests and pair programming. But we still need to find and use practices that assure us that we have (a) built the correct thing and (b) built the thing correctly. Design Patterns help with this, but they still deal with the algorithms and how they modify and extract information from data.

Prolog isn't really very different. In a data structures course in Java, you deal with data that is relatively simple and write algorithms that may have some complexity. In Prolog it is reversed. You have a given algorithm (unification) and you tailor the (possibly complex) data to enable it. But it is still data + algorithms.

One thing that has changed, however, is that the problems that we solve now are more complex and often more flexible than those of interest in 1976. We have learned how to solve those problems and so we incorporate the solutions into libraries and then solve more complex problems, such as scaling for the cloud. But the essence is the same.

It doesn't matter whether you quote the title of the book, of course, nor should you give the complete history of computing to beginners, but they should understand the fundamental idea.

---

I don't actually know enough about Quantum Computing to say that it is different, but it is the only possible exception that I know anything about. It is possible that it will change the game fundamentally.

> **Comments:**
> **username_4**: Quantum computers are supposedly Turing complete, and no more. So just different algorithms, to take advantage of the hardware.  
> **username_5**: Take a peek at an off-the-beaten-path language like FORTH. It intertwines data and code.  

---

### Answer by username_6 on 2018-05-09. Score: 2

> Will you tell students that Algorithms + Data Structures = Programs now (21st century)?

For an introductory course in a procedural or object oriented class I could see me mentioning that and then expanding on it, but in a functional or logic class it would be a footnote.

For Prolog I note [Prolog = Syntactic Unification + Backward chaining + REPL](https://cs.stackexchange.com/questions/6618/how-to-implement-a-prolog-interpreter-in-a-purely-functional-language/6622#6622)

The statement "Algorithms + Data Structures = Programs" is still valid as a bases for understating procedural programs, but that programming is more than just writing programs. To me your questions is people confusing syntax with semantics. In other words they are taking the word `Program` to mean `Programming` and I don't see it that way. A Program is part of programming, but programming is more than a program and in that sense I can agree with what people are thinking but disagree with them in their disagreement with that statement.

They should come up with a new statement like  
`Programming = Programs + Version Control + Test Cases + Continuous Integration + Documentation`.

Along those same lines there should also be one for functional programming like  
`Functional Programs = Algebraic data types + Pattern matching + Lambdas + Catamorphism`

To move the concept of programming forward I don't feel test cases should be a part of programming but that programs should be provable and thus obviate the need for test cases and thus bugs, e.g. [Curry–Howard correspondence](https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence) or [Curry–Howard–Lambek correspondence](https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence#Curry%E2%80%93Howard%E2%80%93Lambek_correspondence)

> **Comments:**
> **username_0**: I also think these theories you mentioned at the bottom) are important, but in the production environment, its cost may be too high, you know. Some interviewer sometimes asks the interviewee to give reasonable test case(at least in Chinese).  
> **username_7**: You have a limited notion of "functional programming". Also ironically you give unnecessarily procedural semantics for Prolog. I agree the poster's "fundamentists" are misreading "programs" as "programming".  

---

