That other "code wizard" conversation
potatohead
Posts: 10,261
I wanted to start another thread because I agree with @"Peter Jakacki" and given my posts, that didn't make sense! @pilot0315 may find this discussion of interest too.
Basically, the approach I put out there is for people seeking more "what is what." It's about knowing what you don't know, and it's also about priority. But, people really do learn differently, so hold that thought.
After I wrote it, on my drive in I actually was thinking about FORTH, how Peter works, and that method not working well at all. Thankfully, he chimed in triggering this discussion.
The method I outlined is most useful for assembly language programs. It's utility becomes marginal the more structured and clean a language is, and the more interactive a language is.
Some of you may argue FORTH is not clean, or jokingly refer to it as a write only language, but I disagree. The actual core of FORTH is ultra simple. And given an approach like Peter uses, is very lean, clean and mean too.
I know @pilot0315 wants to learn assembly language. What I didn't know was their overall level skill may be a bit beyond where it works well. Happens!
Both @"Peter Jakacki" and I subscribe to the interactive school. "Just try it" really has value. There is the agreement.
Both of us are missing a little bit of what @pilot0315 needs, which is context. An operating system, loader, linker, and all that, from an assembly language, and P1 point of view, could be pretty confusing! More discussion is needed there, IMHO.
So, let's have a talk about how you learn how to learn! Others will benefit.
Basically, the approach I put out there is for people seeking more "what is what." It's about knowing what you don't know, and it's also about priority. But, people really do learn differently, so hold that thought.
After I wrote it, on my drive in I actually was thinking about FORTH, how Peter works, and that method not working well at all. Thankfully, he chimed in triggering this discussion.
The method I outlined is most useful for assembly language programs. It's utility becomes marginal the more structured and clean a language is, and the more interactive a language is.
Some of you may argue FORTH is not clean, or jokingly refer to it as a write only language, but I disagree. The actual core of FORTH is ultra simple. And given an approach like Peter uses, is very lean, clean and mean too.
I know @pilot0315 wants to learn assembly language. What I didn't know was their overall level skill may be a bit beyond where it works well. Happens!
Both @"Peter Jakacki" and I subscribe to the interactive school. "Just try it" really has value. There is the agreement.
Both of us are missing a little bit of what @pilot0315 needs, which is context. An operating system, loader, linker, and all that, from an assembly language, and P1 point of view, could be pretty confusing! More discussion is needed there, IMHO.
So, let's have a talk about how you learn how to learn! Others will benefit.
Comments
This is professional work, meaning I gotta get a specific thing or two done, and it's part of the startup that has me flat out hammered right now. I've got a bit of a lull, so I can pull out my P2 for a romp or two! I'm super excited!
Anyway, Python has the interactive "shell" that acts a bit more like a console to me, but that is a quibble. I am just plugging snippets in, learning this and that quickly, building a small app as I go. This is the strong agreement with Peter I mentioned. Everything I've learned, I have learned best when it's dynamic and interactive. You just go!
Fail, fail, error, success, error, fail, success, success, big fail, WTF was that, error, success.... you all know the drill!
Peter's FORTH is the first one I ever did anything useful with. I can't say enough how well done it is, and the thought he has put into how to apply FORTH to a Propeller is amazing!
Also, I did not actually intend for people to draw flow charts or anything super old school like that. For big chunks of assembly, it can be helpful to use flow to just chunk out the program. Like Spin, and other languages do this with structures, PASM can, and it's beautiful, but it won't always. Some dense code may just require picking through it.
I did intend to also help with priority.
When working interactive, I find it useful to take things as "magic" for a time. Get going, do stuff and not worry so much about understanding it all. Then, once I'm doing stuff, things happen, and there come the details, and those rabbit holes appear at a time when I am better equipped to handle them.
So, again, now that I've modeled an example of what this thread is, how do you learn how to learn? What I am looking for is nuggets. Tips. Tricks. Experiences. We've got a pile of smarts gathered here.
Curious minds want to know.
https://www.amazon.com/Principles-Compiler-Addison-Wesley-information-processing/dp/0201000229/ref=sr_1_2?crid=2MYN4MU2YOMHC&keywords=principles+of+compiler+design&qid=1562862791&s=gateway&sprefix=principles+of+compiler,aps,133&sr=8-2
The spin1 compiler and its clones (openspin,bstc,homespun) in particular are super simple. The operations you write in the source translate very directly to emitted bytecode.
Just look at the listing output from bstc or homespun to see what I mean.