Well, for the time, I think I will stick with BASIC.....
Prince of Persia
Re: Prince of Persia
Hmmm...okay
Well, for the time, I think I will stick with BASIC.....
Well, for the time, I think I will stick with BASIC.....
Re: Prince of Persia
Whether assembly, BASIC, Pascal, or Intercal, what is more important than the language is the drive to program something. You have to have an application. You have to have a problem to solve.
Because, then, the goal is not to "learn the language", or "learn to program", rather, it's to solve the problem.
This tact is important because it's very easy to get distracted by tools, language features, etc. that very well may have nothing to do with the problem.
It also helps to work on solving the larger problem simply because there may be many approaches to getting it solved, but, in the end, any of them will work. By focusing on the problem, you can start to leverage what you already know, you get to incrementally, and organically, start including new things, etc.
When I first started playing with machine language, my code relied on "self modifying code". It was a naive implementation. But you know what? It was a working implementation. "Best Practice" suggests to not do it that way, but what did I know of best practice. Even better, later, when I DID learn the "right way", I had better knowledge of why, even though it was perfectly functional, my technique was not necessarily the best technique.
Working code, solving problems, is more important, especially early on, than "best practice". Despite what Dijkstra said, you can "unlearn" these things. Because when you learn the "better" way, you understand more of the "wrong way" (since you used it). Rather than following stuff by rote, CHOOSE to do things with a solid understanding of why you're doing it other than "this guy said so".
So, go off, and code. Write programs. Solve problems. Break things. Fix them again.
In hobby programs, failure is pretty much free.
There's a reason I don't build cabinets. I think I'd like to build cabinets, but...after you make the first set, how many more cabinets can you possible need? Very hard to become good at building cabinets if all you're going to do is throw them away as you learn to make them better. Well, it's expensive at least.
But code? Code is free. Cheap to store, cheap to break and fix. Easy to write a new program every day.
But you have to have problems to solve, because in the end, the problem is the goal, not the coding. Coding is just a distraction.
Because, then, the goal is not to "learn the language", or "learn to program", rather, it's to solve the problem.
This tact is important because it's very easy to get distracted by tools, language features, etc. that very well may have nothing to do with the problem.
It also helps to work on solving the larger problem simply because there may be many approaches to getting it solved, but, in the end, any of them will work. By focusing on the problem, you can start to leverage what you already know, you get to incrementally, and organically, start including new things, etc.
When I first started playing with machine language, my code relied on "self modifying code". It was a naive implementation. But you know what? It was a working implementation. "Best Practice" suggests to not do it that way, but what did I know of best practice. Even better, later, when I DID learn the "right way", I had better knowledge of why, even though it was perfectly functional, my technique was not necessarily the best technique.
Working code, solving problems, is more important, especially early on, than "best practice". Despite what Dijkstra said, you can "unlearn" these things. Because when you learn the "better" way, you understand more of the "wrong way" (since you used it). Rather than following stuff by rote, CHOOSE to do things with a solid understanding of why you're doing it other than "this guy said so".
So, go off, and code. Write programs. Solve problems. Break things. Fix them again.
In hobby programs, failure is pretty much free.
There's a reason I don't build cabinets. I think I'd like to build cabinets, but...after you make the first set, how many more cabinets can you possible need? Very hard to become good at building cabinets if all you're going to do is throw them away as you learn to make them better. Well, it's expensive at least.
But code? Code is free. Cheap to store, cheap to break and fix. Easy to write a new program every day.
But you have to have problems to solve, because in the end, the problem is the goal, not the coding. Coding is just a distraction.
Re: Prince of Persia
BigDumbDinosaur wrote:
or abominations such as Java and Python. 
For the record...I have no love for Oracle and prefer OpenJDK when I can.
Cat; the other white meat.
Re: Prince of Persia
BigDumbDinosaur wrote:
The problem with starting at a high level, e.g., BASIC or one of the other "hand-holding" interpreted languages is too much is automatic, making the mechanics of what is happening opaque. That's fine if your goal is to crank out a working program as quickly as possible without dealing with too many details. Trouble is, you aren't going to learn a whole lot about computers that way.
On the other hand, if you start near the bottom (symbolic assembly language, to be specific) and learn how to encode algorithms, data structures, and methods and procedures in a low-level environment, you will find doing such things in the higher level environment a piece of cake. By the time I learned K&R C (c.1980, when I had my first taste of the UNIX environment) I already had a decade of programming experience, virtually all of it machine and assembly language. It took me longer to learn the idiosyncrasies of the C compiler than it did to master the language itself.
So there is much to be said about starting with the basics (not BASIC!) and learning just what is going on when the cursor is blinking and the machine is awaiting your input. That's how I started and it caused me to develop programing styles and philosophies that are applicable to any language, be it C or abominations such as Java and Python.
On the other hand, if you start near the bottom (symbolic assembly language, to be specific) and learn how to encode algorithms, data structures, and methods and procedures in a low-level environment, you will find doing such things in the higher level environment a piece of cake. By the time I learned K&R C (c.1980, when I had my first taste of the UNIX environment) I already had a decade of programming experience, virtually all of it machine and assembly language. It took me longer to learn the idiosyncrasies of the C compiler than it did to master the language itself.
So there is much to be said about starting with the basics (not BASIC!) and learning just what is going on when the cursor is blinking and the machine is awaiting your input. That's how I started and it caused me to develop programing styles and philosophies that are applicable to any language, be it C or abominations such as Java and Python.
