4 ms·
> somehow GOTOs and line numbers would turn you into a bad programmer for life I think the opposite. It's super simple to understand as a beginner and is a low
by gregmac 3y ago
> somehow GOTOs and line numbers would turn you into a bad programmer for life
I think the opposite. It's super simple to understand as a beginner and is a low barrier to entry. The key is likely aligning when to introduce someone to a more structured language with when the are hitting the limits of GOTO - like just have finished writing an awkward large program that could be significantly simpler, spent hours debugging a problem caused by lack of scoped variables, or are trying to modify something they wrote a few months ago that has dozens of GOTOs. These are the things where ideally the light goes on and people "get it".
On the last point, I think that is really what makes people great. Go back and try to work on code you haven't looked at it even thought about in 6+ months. If you've only been coding a couple years, you'll gain a ton of insights into what (not) to do to write maintainable software, in the same way students learn why we don't use GOTO.
- BariumBlue 3y agoGood point actually - when teaching absolute newbs, I found they'd often confuse the point of a while with a for with an if block. GOTO is super unambiguous and probably a better introduction to program control flow while they get used to manipulating and juggling variables around
- tialaramex 3y agoI would suggest that Rust's only actual loop, (using the keyword loop) is unambiguous while also being structured. You can (and during development I sometimes do) just write loop until it's apparent what you actually meant and then rewrite - also the Clippy linter will point out various obvious idioms e.g. for or while let loops if they are written as legal but unidiomatic loop constructs. So that aids pedagogy. Your loop works, but the linter explains how an experienced programmer would express the same loop more clearly. Computed GOTO is often possible in BASICs. In one sense that's awesome, this is a very powerful technique, but in practice it's so unstructured that you shouldn't ever use it so why even offer it? "That's how the machine works". Yes it is, which is why we don't write raw machine code when we can.
- ddingus 3y agoI think it should be used when one needs a fast, deterministic field of branches. When I used them, I would use boolean in the math to insure the input value was bounded properly. X = (Y > 5) and Y (for systems setting true to -1 all bits set) X = Y * (Y > 5) (for systems setting true to just the value 1) Basically an in-line compare where the actual numeric value result of the comparison is used in a math expression rather than as an input to an if-then construct. And these two ideas map directly to assembly language, which given the speed of the machines back in the day, made sense. People were going to be using assembly sooner or later.
- nsxwolf 3y agoYou didn’t have to go straight from BASIC to a more structured language - you could learn about GOSUB first.
- gregmac 3y agoDoesn't that still use unscoped global variables, though? That, to me, is the thing that causes unmaintainable spaghetti code more than anything else (in any language).