As a student, back in the day, I was exposed to high level programming languages that not only had a GOTO statement, but on which its use was common. I also did my fair share of programming in assembly code, but always had the impression that my understanding of the semantics of subprograms was enormously facilitated by my familiarity will programs constructed without them, in high level imperative languages, even though I never used them (or felt the need) in my life as a programmer, ever since.

In my experience as a teacher, the passage from non-modular to modular programming is always a struggle, and I keep asking myself the following question:

Would the careful and well-supervised reintroduction of the jump command in languages and environments devoted to introductory lessons in programming be of help students with the passage from non-modular to modular programming?

For clarity: the usage of the GOTO statement I am talking about here is restricted to programming environments used exclusively for teaching the basics of programming, while (or where) it is still done using imperative (monoparadigm) languages. Informed opinions based on experience and/or indications of research available on the subject (I didn't find anything substantial) are really welcome.

  • $\begingroup$ I would think that issues regarding how programming concepts may be understood and explained is sort of implicit, thus relevant, in much of what we do here. Understanding programming concepts is not the same as programming. This said, in a world that has loops, recursion, loop exits, returns, exceptions and various other devices, I am doubtful that goto is a proper drug to instill in young minds. But I do not know of research on this topic, and I am unlikely to trust it anyway, if only because of the difficulty of formulating the problem and the issues. OK at assembly level though. cc @DavidRi $\endgroup$
    – babou
    May 9, 2015 at 20:55
  • $\begingroup$ I don't understand your second paragraph. You say that “the passage from non-modular to modular programming is always a struggle”, and then you want to intensify preliminary teaching of non-modular programming? Why not start straight with modular programming then? $\endgroup$ May 9, 2015 at 21:49
  • 3
    $\begingroup$ I would argue that students shouldn't be taught non-modular programming. I'd like to know which first courses teach students this way these days. $\endgroup$ May 10, 2015 at 16:54
  • 1
    $\begingroup$ The first programs a student makes are non-modular. When they are presented to subprograms - especially when the term "function" is used - there is a collision between two conceptual metaphors (mathematical and programmatical) that creates a lot of confusion in beginners. If a subprogram is explained as a natural evolution from jumping and coming back from a different block of instructions, this confusion can be eliminated. That is my hypothesis. I am not advocating a return to the 1960'. $\endgroup$ May 10, 2015 at 17:01
  • 1
    $\begingroup$ Related question: cseducators.stackexchange.com/q/3696/204 $\endgroup$ Oct 10, 2017 at 22:27

2 Answers 2


This doesn't seem like a good idea. Normally, we teach people using a system with restrictive safety features and only remove those safety features when the learner has demonstrated competence: consider training wheels on a bike, children's safety scissors and so on. You're suggesting that we teach using a "dangerous" system (goto) and then remove the dangerous parts once the learner has demonstrated competence.

Also, I don't see how using goto would help the transition to modular programming. Modular programming doesn't tend to use goto, so it seems you're trying to aid the transition from A to B by introducing something that doesn't help with B. To use a rather melodramatic analogy, it's like proposing to help somebody transition from a tricycle to a bicycle by giving them a pair of scissors to use while riding: it introduces a dangerous habit that doesn't even contribute to the desired goal.

  • $\begingroup$ Modular or not, structured programming is what can eliminate GOTOs. $\endgroup$
    – SDsolar
    Mar 23, 2017 at 7:49

The two most common cases for using goto is to break out of nested loops to a specific level, or when there are multiple paths to common code. Such situations could be avoided in a beginner class, but it's always possible that the subject could come up. Some languages include a "continue to label" to break out of nested loops, but it's essentially a restricted form of goto. Java has reserved "goto", but so far hasn't implemented it.

Imagine how messy the end result would be if trying to remove the goto's used in the optimized bottom up 4 way merge sort (without heap) shown at the end of the linked to answer:



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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