2 added 553 characters in body
source | link

Don't teach it if you want Programmers (know what they're doing). Do teach it if you want Computer Scientists (know why they're doing it).

Obviously these two aren't mutually exclusive, but plenty of people learn how to code without understanding what they're doing at a lower level, and that's ok. If that's your goal, ignore goto; they'll never need to know it.

If you do want them to understand the why, then you have to teach it. If their code uses any sort of control flow, then at a lower level something somewhere is calling a goto (or something close), and CS students need to understand how that works.

EDIT: I just reread GOTO Statement Considered Harmful and it actually ends with:

The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.

I know most of us have focused on the goto side of this question, hopefully this sheds some light on the flowchart side as well.

This line also reads to me as a confirmation that goto should be learned as a concept, since describing a control flow is nearly impossible without it, but Dijkstra still advocates avoiding it in code.

Don't teach it if you want Programmers (know what they're doing). Do teach it if you want Computer Scientists (know why they're doing it).

Obviously these two aren't mutually exclusive, but plenty of people learn how to code without understanding what they're doing at a lower level, and that's ok. If that's your goal, ignore goto; they'll never need to know it.

If you do want them to understand the why, then you have to teach it. If their code uses any sort of control flow, then at a lower level something somewhere is calling a goto (or something close), and CS students need to understand how that works.

Don't teach it if you want Programmers (know what they're doing). Do teach it if you want Computer Scientists (know why they're doing it).

Obviously these two aren't mutually exclusive, but plenty of people learn how to code without understanding what they're doing at a lower level, and that's ok. If that's your goal, ignore goto; they'll never need to know it.

If you do want them to understand the why, then you have to teach it. If their code uses any sort of control flow, then at a lower level something somewhere is calling a goto (or something close), and CS students need to understand how that works.

EDIT: I just reread GOTO Statement Considered Harmful and it actually ends with:

The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.

I know most of us have focused on the goto side of this question, hopefully this sheds some light on the flowchart side as well.

This line also reads to me as a confirmation that goto should be learned as a concept, since describing a control flow is nearly impossible without it, but Dijkstra still advocates avoiding it in code.

1
source | link

Don't teach it if you want Programmers (know what they're doing). Do teach it if you want Computer Scientists (know why they're doing it).

Obviously these two aren't mutually exclusive, but plenty of people learn how to code without understanding what they're doing at a lower level, and that's ok. If that's your goal, ignore goto; they'll never need to know it.

If you do want them to understand the why, then you have to teach it. If their code uses any sort of control flow, then at a lower level something somewhere is calling a goto (or something close), and CS students need to understand how that works.