I was recently reading a new, and mostly excellent, magazine Hello, World. There is an article on teaching goto. In essence, the author states that there is value in teaching goto as it helps to translate flowcharts into code.

I have always considered goto to be harmful. It results in code that is buggy and hard to read. Not just because I read it in a 1960 paper “Go To Statement Considered Harmful“ — Edsger W. Dijkstra, it is self evident (once you have tried structured-programming).

I have always considered flow-charts the same way. They are just the pictorial form of unstructured code. The UML of assembly language.

So the question:

Does the author have a point? Is there some value in goto or flow-charts?

I accept that:

• Flowcharts are visual, but there are visual structured representations that are better.
• goto can/has-to be used in teaching assembly language/machine code.

One of many links to the paper “Go To Statement Considered Harmful”

I was recently reading a new, and mostly excellent, magazine Hello, World. There is an article on teaching goto. The author states that there is value in teaching goto, as it helps to translate flowcharts into code.

I have always considered goto to be harmful. It results in code that is buggy and hard to read. Not just because I read it in a 1960 paper “Go To Statement Considered Harmful“ — Edsger W. Dijkstra, but because it is self evident (once you have tried structured-programming).

I have always considered flow-charts the same way. They are just the pictorial form of unstructured code (The UML of assembly language).

So the question:

Does the author have a point? Is there some value in goto or flow-charts?

I accept that:

• Flowcharts are visual, but there are visual structured representations that are better.
• goto can/has-to be used in teaching assembly language/machine code.

One of many links to the paper “Go To Statement Considered Harmful”

I was recently reading a new, and mostly excellent, magazine Hello, World. There is an article on teaching goto. In essence, the author states that there is value in teaching goto as it helps to translate flowcharts into code.

I have always considered goto to be harmful. It results in code that is buggy and hard to read. Not just because I read it in a 1960 paper, it is self evident (once you have tried structured-programming).

I have always considered flow-charts the same way. They are just the pictorial form of unstructured code. The UML of assembly language.

So the question:

Does the author have a point? Is there some value in goto or flow-charts?

I accept that:

• Flowcharts are visual, but there are visual structured representations that are better.
• goto can/has-to be used in teaching assembly language/machine code.

I was recently reading a new, and mostly excellent, magazine Hello, World. There is an article on teaching goto. In essence, the author states that there is value in teaching goto as it helps to translate flowcharts into code.

I have always considered goto to be harmful. It results in code that is buggy and hard to read. Not just because I read it in a 1960 paper “Go To Statement Considered Harmful“ — Edsger W. Dijkstra, it is self evident (once you have tried structured-programming).

I have always considered flow-charts the same way. They are just the pictorial form of unstructured code. The UML of assembly language.

So the question:

Does the author have a point? Is there some value in goto or flow-charts?

I accept that:

• Flowcharts are visual, but there are visual structured representations that are better.
• goto can/has-to be used in teaching assembly language/machine code.

One of many links to the paper “Go To Statement Considered Harmful”

I was recently reading a new, and mostly excellent, magazine Hello, World. There is an article on teaching goto. In essence the author states that there is value in teaching goto as it help to translate flowcharts into code.

I have always considered goto to be harmful, it results in code that is buggy and hard to read. Not just because I read it in an 1960 paper, it is self evident (once you have tried structured-programming).

I have always considered flow-charts in the same way. They are just the pictorial form of unstructured code. The UML of assembly language.

So the question:

Does the author have a point?, is there some value in goto or flow-charts?

I accept that:

• Flowcharts are visual, but there are visual structured representations, that are better.
• goto can/has-to be used in teaching assembly language/machine code.

I was recently reading a new, and mostly excellent, magazine Hello, World. There is an article on teaching goto. In essence, the author states that there is value in teaching goto as it helps to translate flowcharts into code.

I have always considered goto to be harmful. It results in code that is buggy and hard to read. Not just because I read it in a 1960 paper, it is self evident (once you have tried structured-programming).

I have always considered flow-charts the same way. They are just the pictorial form of unstructured code. The UML of assembly language.

So the question:

Does the author have a point? Is there some value in goto or flow-charts?

I accept that:

• Flowcharts are visual, but there are visual structured representations that are better.
• goto can/has-to be used in teaching assembly language/machine code.