3 ms·

> One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life. In fact GOTOs in BASIC were

> One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life. In fact GOTOs in BASIC were, I think, a big part of lowering the barrier to programming for the new and the young. It relieves the mental load of structuring the program, allowing you to concentrate on the logic and syntax. Not using GOTOs requires already having a mental picture of what the program should look like before you write it, or at least rewriting it multiple times as you go. As a Rust programmer, I probably spent 5-10% of my time restructuring branches to deal with Results and Options more elegantly, and it is the least fun part. While not related to program flow, it's an example of a Good Thing that makes coding less fun.

jermaustin1 3y ago
For me BASIC led to VB which led to VB.Net which quickly led me to C#. I did some real fun stuff in BASIC as a kid that I never replicated in later languages. In kindergarten or first grade, I picked up a book called something like "Make Your Own Computer Games" at my local library. Everything was GOTOs and LABELS. The librarian didn't want to let me check it out because it was beyond my understanding, but my grandma insisted. That night and for the following 2 days, on my Dad's work computer, I would type and retype these computer games into GWBASIC in MSDOS, and then type run at the end. There was no way to actually save the .BAS files, so any time I wanted to play one of these games, I had to type it. So I memorized them before I had to turn the book back in. I then started to combine games together. Like "Guess the Number" and "Hangman" which actually taught me more about programming than anything I learned later in life from education.
cookiengineer 3y ago
For me, as a golang programmer, it's almost the same like you mentioned. Additional mental overhead in golang is that you also need to implement everything in as-flat-dependencies as possible due to the compiler not having support to resolve single methods or recursive dependencies (and -injections). Usually I find myself rewriting the codebase at least 3 times until I have a modular enough architecture that does not have any unresolvable recursive dependencies. Usually it ends up in a folder structure with a top level structs, utils, actions, cmds, schemas, parsers, protocols etc. While it also embraces strong knowledge about the architecture, it also is a much higher threshold until you have a program working. Add to this the always occurring defined but not used errors and you can demotivate kids real fast, even though the language syntax and grammar could be very easy to learn (apart from what pointers, slices and reflections or memory allocations and callstacks are).

jermaustin1 3y ago

For me BASIC led to VB which led to VB.Net which quickly led me to C#. I did some real fun stuff in BASIC as a kid that I never replicated in later languages. In kindergarten or first grade, I picked up a book called something like "Make Your Own Computer Games" at my local library. Everything was GOTOs and LABELS. The librarian didn't want to let me check it out because it was beyond my understanding, but my grandma insisted. That night and for the following 2 days, on my Dad's work computer, I would type and retype these computer games into GWBASIC in MSDOS, and then type run at the end. There was no way to actually save the .BAS files, so any time I wanted to play one of these games, I had to type it. So I memorized them before I had to turn the book back in. I then started to combine games together. Like "Guess the Number" and "Hangman" which actually taught me more about programming than anything I learned later in life from education.

cookiengineer 3y ago

For me, as a golang programmer, it's almost the same like you mentioned. Additional mental overhead in golang is that you also need to implement everything in as-flat-dependencies as possible due to the compiler not having support to resolve single methods or recursive dependencies (and -injections). Usually I find myself rewriting the codebase at least 3 times until I have a modular enough architecture that does not have any unresolvable recursive dependencies. Usually it ends up in a folder structure with a top level structs, utils, actions, cmds, schemas, parsers, protocols etc. While it also embraces strong knowledge about the architecture, it also is a much higher threshold until you have a program working. Add to this the always occurring defined but not used errors and you can demotivate kids real fast, even though the language syntax and grammar could be very easy to learn (apart from what pointers, slices and reflections or memory allocations and callstacks are).