I mostly agree with ShardPhoenix. Actually learning a language is essential to learning the mindset which programming teaches you.
I find it’s easiest to learn programming when I have a specific problem I need to solve, and I’m just looking up the concepts I need for that. However, that approach only really works when you’ve learned a bit of coding already, so you know what specific problems are reasonable to solve.
Examples of things I did when I was learning to program: I wrote programs to do lots of basic math things, such as testing primality and approximating integrals. I wrote a program to insert “literally” into sentences everywhere where it made grammatical sense. I used regular expressions to search through a massive text file for the names of people who were doing the same course as me. Having the goal made it easier to learn the syntax and concepts.
However, that approach only really works when you’ve learned a bit of coding already, so you know what specific problems are reasonable to solve.
This struck me as slightly odd.
In my experience, people who do not have at least a decent grasp of the concepts involved in programming will not even be able to imagine the kinds of problems that are not reasonable to solve. They will, on occasion, think up things that they believe is “simple”, but would in practice require the equivalent of a whole Google department working on it for years before it can get done. If that’s what you meant by knowing what problems are reasonable to solve, then that’s fine.
However, even such large, Google-scaled projects could still present a good way to motivate yourself and start looking up and learning stuff about coding.
I believe I went with the wrong interpretation of “solve”. I read it as something much more open, in the sense of “figuring out the problem’s key elements”, which would mean “needing to solve” google-scale projects and then them being “reasonable to solve” is equivalent to doing the research and experimentation required to figure out all the important structural elements of the problem, and what kind of team exactly would be working on which problems in order to implement the full solution.
If I interpret “solve” as in “fully functional” (coded, runs, performs the desired operation without bugging for the standard test cases), then what you said and what I said reduce to approximately the same thing.
I mostly agree with ShardPhoenix. Actually learning a language is essential to learning the mindset which programming teaches you.
I find it’s easiest to learn programming when I have a specific problem I need to solve, and I’m just looking up the concepts I need for that. However, that approach only really works when you’ve learned a bit of coding already, so you know what specific problems are reasonable to solve.
Examples of things I did when I was learning to program: I wrote programs to do lots of basic math things, such as testing primality and approximating integrals. I wrote a program to insert “literally” into sentences everywhere where it made grammatical sense. I used regular expressions to search through a massive text file for the names of people who were doing the same course as me. Having the goal made it easier to learn the syntax and concepts.
This struck me as slightly odd.
In my experience, people who do not have at least a decent grasp of the concepts involved in programming will not even be able to imagine the kinds of problems that are not reasonable to solve. They will, on occasion, think up things that they believe is “simple”, but would in practice require the equivalent of a whole Google department working on it for years before it can get done. If that’s what you meant by knowing what problems are reasonable to solve, then that’s fine.
However, even such large, Google-scaled projects could still present a good way to motivate yourself and start looking up and learning stuff about coding.
I’m pretty sure we exactly agree on this. Just out of curiosity, what did you think I meant?
I believe I went with the wrong interpretation of “solve”. I read it as something much more open, in the sense of “figuring out the problem’s key elements”, which would mean “needing to solve” google-scale projects and then them being “reasonable to solve” is equivalent to doing the research and experimentation required to figure out all the important structural elements of the problem, and what kind of team exactly would be working on which problems in order to implement the full solution.
If I interpret “solve” as in “fully functional” (coded, runs, performs the desired operation without bugging for the standard test cases), then what you said and what I said reduce to approximately the same thing.