_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm not sure that's a contradiction - I'm taking about the amount of thinking involved in the process, not the quality of the result. Take the Python snippet above: Simple to grasp, but still an amazing number ways to screw up if I'm not careful (starting with the whitespace indent). The Forth version of the same snippet (with a print(twice) command in the loop to see what we are doing) could very well be easier to keep bug-free if the user carefully chooses small words etc. Uh, off the top of my head: This runs with Gforth and Tali (well, once you've explained BOUNDS and 2* to Tali, which will be included out of the box with the next update), two totally different machines. Python won't even run on a 8-bit machine, so the question which language makes better use of limited hardware resources isn't even funny. Certainly bug-free, because I checked makelist and then .list.

My argument is not about which language gets you to bug-free code faster -- I have no reason to think you are not totally correct (my one large Forth project, the 65816 emulator, is far more stable than it has any right to be given my skill level). My argument is about which one requires more thought. I'm not sure the Forth version of the (admittedly trivial) Python example above could be called less complex or easier to understand.

(LATER ADDITION)

Actually, this might be a good example of how you can try to be clever in Forth for even more oompf. If we know that we're only going to have those three numbers, we don't have to muck about with cell sizes, and can just write On Gforth with 64-bit cells, that saves 21 bytes, and three bytes with Tali's 16-bit cells. A byte saved is a byte earned!

I think you can achieve the same with C, as long as the hardware has a few (simple) provisions, such as an easy way to access local data on the stack. The 6502 wouldn't really qualify, but something like an STM8 would be fine.

Garth, here's some of what I was referring to: http://www.ultratechnology.com/cm52299.htm

I had an interesting experience yesterday as I was trying to shove all of the F83 sources in to a single file. F83 works with Block files, vs text files. And it's core system comes in 5 files: KERNEL86.BLK, EXTEND86.BLK, META86.BLK, CPU8086.BLK, and UTILITY.BLK.

A Block files contains both code and documentation. Essentially the file is divided in half, and each code screen has an associated documentation, or Shadow, screen that's half a file away. So, if you have a file with 100 Screens, Code Screen 1's shadow screen would be Screen 51. In the editor, you can toggle between the 2 with the 'A' (Alternate) command. You can change the offset to suit you, but, you're working against the grain doing that.

Now, the Forth block commands have no concept of a file. So, the system has the trait of a Current File. Thus, when you enter 1 LIST or 1 EDIT or 1 LOAD, you will be working with the first screen of the "current" file.

F83 also has a nice facility called VIEW. If you type VIEW WORDS, it will list the source screen that has the "WORDS" word. You have source to everything, so it makes it easy to browse the source and the documentation. However, the VIEW word, under the covers, changes the Current File.

If you do:

You just loaded the first screen of KERNEL86.BLK, which is where the source for WORDS resides.

So, to simplify things, I was going to try and push all of the source in to a single block file, along with my own work, just to keep that from happening. To quote Forrest Gump: "That's good! One less thing."

So, I had to copy the existing block files in to a new monolithic one. But because of the nature of Shadow screens, and their relationship to the overall size of the file, I couldn't simply concatenate the files. I could, they'd just be more of a pain to deal with overall.

F83 also has the idea of the "INPUT" file, specifically for problems like moving screens from one to another. It also has the CONVEY word to perform the copy. CONVEY has the variable, HOPPED, which is used to offset the copy. Normally you'd do: 1 10 CONVEY, that would copy screens 1 thru 10 to screen 1 thru 10 in the new file. If HOPPED is set to 5, then the destination would be 6 through 15 (as HOPPED is added to each screen during the copy).

There's even a nice facility: 1 10 TO 5 CONVEY. Here, 'TO' is a bit of syntactic sugar to set HOPPED properly. This copies screen 1 10 to screen 5-14.

So, a copy session in the end would look like:


For my task, I need to break the original file up in to 2 pieces (the code, and the shadow screens) and relocate them to the new larger file. So, if NEW.BLK is 50 screens large, and OLD.BLK is 10 screens, I need to basically do:

Then, if I 1 EDIT on NEW.BLK, and hit A, I'll get the proper shadow screen.

Turns out, as shown, none of that is automatable. Not readily. OPEN and FROM are immediate words, so you can't simply stick them in a colon definition. The word TO is also an immediate word that parses the 5 (in this case) out of the input stream. 1 and 10 are on the stack, but 5 is not. So, this also is not easily put in to a colon definition. What starts as a simple automation task, now becomes an advanced Forth exercise.

F83 has a word CAPACITY, which gives you the size of the current file. I need that to split the files in two. But CAPACITY doesn't work on the INPUT file (OLD.BLK in this case), only the current file. And CAPACITY only works with the global FILE variable. Thankfully, there's a SWITCH word to move these back and forth. Also, the word TO behaves differently from HOPPED. For: 5 9 TO 50 CONVEY, naively you'd think HOPPED would be set to 50. But that's not true, it's set to 45. Because we want 5 to become 50, and HOPPED is simply added during CONVEY.

In the end, I finally got CONVEY-FILE written.

This would copy the code screens from OLD.BLK to starting at Screen 10 in NEW.BLK, and the Shadow screens to Screen 35.

This in all took about 2 hours to suss out, and now I get an I/O error when trying to load up the meta compiler from the monolithic file.

But what was interesting here was the fighting between words that are basically designed for interactive use and those used within other words. For example, perhaps it would have been better if CAPACITY were written as:

Then, perchance I could use (CAPACITY) in my code, rather than having to SWITCH back and forth between files. This goes to that cognitive load issue. "What file is current when I call CAPACITY?" Man, I tell ya, especially combined with the stack juggling, this little utility, which is, like 3-4 lines of code, boy was it an effort to type this stuff out.

A lot of that is practice, a lot of that is the nature of the F83 design in this case. The mixing of interactive commands and automating them. The premise that there is a difference between the two. (Lisp has different behaviors when LOADING and COMPILING, but they're less in your face as this is.) Some of that is F83 design choices, some of that is Forths nature to effectively allow such choices.

But all of that added up to being a bit of a struggle yesterday, for sure.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The magazine is a fun read. The ads alone are interesting from a nostalgia factor.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I guess it's just different strokes for different folks. I started out with BASIC and moved to 6502 ASM when I was 11 or 12. I then moved on to C (on DOS). There are times when it doesn't make sense. But, I never felt it was garbage. As I learned C, it helped me quickly learn C++ which helped me learn C# very fast. Then my company dropped C# and went to Java which I currently develop in. In all of those years, I moved from C to C++ to C# to Java with VERY LITTLE difficulty. Because they share so much in common.

On the other hand, I'm trying to give Forth a chance (several times actually). I guess it's the RPN that gets me. My human brain just doesn't compute that way and I've got 30+ years in programming in the "C based" world.

Anyway, in my experiences...I find the languages are the least of the problem. In my experiences, it's the frameworks that are usually bad. But it's deeper than that for me...again, in my experiences, developers generally want to reinvent the wheel because they think they can. So I see GIANT projects NOT USING the frameworks we all agreed on. Or, some programmer will abstract classes beyond belief because he read a book about it or a blog post and how he's doing it "the right way".

Sorry, went off topic there.

_________________
Cat; the other white meat.

I don't really understand what the problem with C is. I started with 6502 assembly language, well, hex code first, then some BASIC, which I qiuickly found terrible. Then Fortran, Pascal, etc. C arrived at some point and it was effortless. A few pitfalls, easy to stay clear of those. It's simply another procedural language. But much more standardised than most languages, due to where it came from.

At its most basic, C is portable assembly. Anyone comfortable with a macro assembler should be able to pick up basic C readily.

The most complex notions being dealing with types and pointers. Its easy to go off the rails wth complicated type declarations, and they can certainly be difficult to decipher. Add in complicated expressions, especially with pre- and post-fix operators, and it can daunting to understand exactly what may be happening.

But just because you can have "Obfuscated C" contests, or puzzles that go in to the nuances of operator precedence, doesn't mean you have to.

All of the arguments about Forth unreadability apply to C. If you don't want your Forth or C to be unreadable, don't write it that way.

My singular difficulty with Forth, specifically with an existing source code base, is that you as the reader need to have much more familiarity with the source code in order to understand it, simply because Forth does not make visible the argument structure of the different routines. You, as the reader, need to keep the runtime stack in your head as you read the code. And this requires that you have an understanding of what are the stack affects and requirements of each word. Add in some global variables, and its quite a burden for someone unfamiliar with the source code.

Reading C code, you still need to understand what individual routines do, but, outside of global variables, the data flow, along with the logic flow, of a routine is explicitly laid out in the source code. It's different when you're intimate with the code and the routines, but when dealing with strange code, C can be much more accessible than Forth, to me.

That's basically it. Of course, we're talking about K&R C and ANSI C, not the aberrations that followed.

As for Forth, I see absolutely nothing in that language for me.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Agreed. When I was a teenager, my brain was very receptive to new languages, and I quickly learned BASIC, 6502 assembly, 6809 assembly, Fortran, Pascal, IBM 360 assembly, C, 68K assembly (in addition to Spanish and a bit of French and Portuguese) ... then I ran out of teenage years, and my brain started getting less and less receptive. I really want to learn Forth and use it, but it's an uphill battle, because my 51-year-old brain is resisting my efforts ...

Mike B.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I read an interesting note about learning a new (spoken) language, to this effect: if you're the kind of person who wants to know precise definitions, it's a drawback. You need to have a go, and struggle through your difficulty in expressing yourself. To me, this seems the same in programming. Most languages have a lot of features and some dark corners, and most programmers become competent without exploring all of them.

As for RPN and Forth - or not Forth - that doesn't necessarily have much to do with it. In my case my problem with Forth has nothing to do with RPN - HP calculators are extremely natural for me. I moved over from TI first chance I got. And I actually like the RPN part of Forth. It's just that I've never managed to find a way to get Forth to solve the programming tasks I want to try it on. So I don't try anymore. It looks to me like if you stick to problems solvable by Forth, and just ignore the rest, then all is fine. But I'm short of those.
I don't know if anything of this has any connection with real languages - my gut feeling says 'no'. In any case, dictionaries aren't very useful for me when learning languages. I learned English without one, I only remember words when I understand the meaning from context. It's the same for the other languages I know, although I'm not that fluent in those.
Edit/Update: Thinking more about it, the RPN of Forth is not my problem, it's probably more my procedural brain. And that my designs, in general, only have a few places where I would create functions to do something with parameters and return the result, which for me at least is the one case which is easy to map to Forth.