8
$\begingroup$

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)?

Improve this question
$\endgroup$
1
  • 3
    $\begingroup$ 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 -- $\endgroup$
    – user5106
    May 9, 2018 at 18:08

4 Answers 4

Reset to default
9
$\begingroup$

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.

Improve this answer
$\endgroup$
3
$\begingroup$

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.

Improve this answer
$\endgroup$
3
$\begingroup$

With one possible exception (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.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ Quantum computers are supposedly Turing complete, and no more. So just different algorithms, to take advantage of the hardware. $\endgroup$
    – ctrl-alt-delor
    May 10, 2018 at 12:25
  • $\begingroup$ Take a peek at an off-the-beaten-path language like FORTH. It intertwines data and code. $\endgroup$
    – vonbrand
    Aug 2, 2018 at 18:25
2
$\begingroup$

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

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 or Curry–Howard–Lambek correspondence

Improve this answer
$\endgroup$
2
  • $\begingroup$ 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). $\endgroup$
    – Chen Li
    May 10, 2018 at 1:50
  • $\begingroup$ 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". $\endgroup$
    – philipxy
    Jun 21, 2018 at 21:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.