.
We can see the simplest example of imperative programming in QBASIC. BASIC is much maligned for being sucky. And it is, for a number of reasons. Writing programs in BASIC leads to messy code devoid of form or structure, peppered with goto statements. And as we all know, goto statements are considered harmful. This is actually a good point. The "goto" itself is unambiguous and unconditional. However, when we see a line number or label, we have no clue where control is coming from! We have no context by which to judge the contents of variables or the states of other things in the program. While we can, of course, theoretically figure this out by reading the entire source, we're all too lazy to do this, and even so reading the entire source scales badly with program size. .
Goto statements are not intrinsically evil in and of themselves, but overuse leads to dreaded spaghetti code, which is hard to understand and hard to maintain. While hard-to-understand and hard-to-maintain code might actually work, there is ample justification for just declaring the code bad to start with and avoiding it all together. Code that makes minimal assumptions and is well-structured, concise, tight, easy to understand, easy to maintain, and is written defensively to guard against common mistakes is a Good Thing. While something may be crocky and yet work, it's still a crock, and we ought to avoid such things. This leads to fewer bugs, greater understanding, maintainability, and - dare I say it - code reuse. Which is a whole other topic I won't get into here. .
Goto statements are still useful in places, of course - but generally, only for jumps that occur on a single page of code, only when masses of flags and tests would have to serve otherwise, and only when well-documented. Actually, all code should be well-documented. Therefore, the occasional goto is not bad, and it's probably overly nasty of Java to not have a working goto at all.
