Precipitous learning curve
Hi Charles,
There are a few things that would help someone new to Retro, but not to FORTH, and I would like to suggest them, in the hopes that they could make Retro Forth a little more attractive to, say, Fathers who are beginning to teach their 9-year-olds about programming, and who themselves have lots of experience.
First and foremost is the documentation.
If the Documentation reader were to retain where the user was when they switch to the split to try the given examples, it would reduce frustration immensely.
Because we’re new to Retro, if not to Forth, an early (very early) Link to a list of the differences between, say, an ANSI Forth (and yes, I know that no ANSI standard has been released) and Retro would be a tremendous help.
A quick description of the tabs, what they do and how you use them is in order, extremely early in the documentation.
I will admit that, having spent decades with the Forth83 interface, having an immediate mode that operates like a terminal is very helpful. The split allows one to see documentation and output at the same time, which is cool, but each entry disappears at the first space, and frankly, with no view of any part of the stack, it’s hard to tell that anything is happening at all.
While the prefixing idea certainly has merit (and your community have adopted it without great insurrections) there should be some means of discerning which prefixes have been added to which words. While it is pretty easy to decide that a function you are creating belongs among the ones that fetch a value or store it, some of the others aren’t so obvious from the other side. Should eq? Be system, math, text, comparisons, or yet some other subset of the dictionary? What did the programmer who assigned it think like... except we don’t know the programmer personally, and apparently we don’t know all the prefixes used in the basic Retro system.
Any of these conveniences can be given a visibility/actuation button to turn them on and off, so that, with all turned off, the program looks exactly as it does now, which is no doubt pleasing to the community of Retro users.
Words tab:
Pursuant to the problem of figuring out what the system-creator prefixed words with, or just finding the little buggers in the first place, there needs to be some kind of lookup. If it recognized subsets of words and made a list, it would become useful. Like the documentation, it _ought_ to be able to keep your place, and it might keep your last search, but currently, switching tabs returns the Words tab to the beginning.
Vocabulary words:
I spent some considerable time, back in the early 90s, arguing for inclusion of decompiling words and documentation words in the Standard: View, See, etc. You can limit those that decompile from the living code to keep them from decompiling _your_ code, pretty easily, but being able to see the code _we_ write is a must. Even Words, as much of a spew as it is, can be invaluable in the first contact with a new Forth, and frankly, as age settles in, is pretty valuable thereafter.
Those are my reflections on my first hour of experience. I have no doubt that, with enough weeks of reading the documentation and drawing charts and writing code on paper so I can test them immediate, that I will be up to speed with the rest of the community, but those necessities are counter to the principles that Charles Moore established as his reasons for creating FORTH in the first place. Not to mention that no 9-year-old is going to read the documentation for longer than about 2 minutes.
There are a few things that would help someone new to Retro, but not to FORTH, and I would like to suggest them, in the hopes that they could make Retro Forth a little more attractive to, say, Fathers who are beginning to teach their 9-year-olds about programming, and who themselves have lots of experience.
First and foremost is the documentation.
If the Documentation reader were to retain where the user was when they switch to the split to try the given examples, it would reduce frustration immensely.
Because we’re new to Retro, if not to Forth, an early (very early) Link to a list of the differences between, say, an ANSI Forth (and yes, I know that no ANSI standard has been released) and Retro would be a tremendous help.
A quick description of the tabs, what they do and how you use them is in order, extremely early in the documentation.
I will admit that, having spent decades with the Forth83 interface, having an immediate mode that operates like a terminal is very helpful. The split allows one to see documentation and output at the same time, which is cool, but each entry disappears at the first space, and frankly, with no view of any part of the stack, it’s hard to tell that anything is happening at all.
While the prefixing idea certainly has merit (and your community have adopted it without great insurrections) there should be some means of discerning which prefixes have been added to which words. While it is pretty easy to decide that a function you are creating belongs among the ones that fetch a value or store it, some of the others aren’t so obvious from the other side. Should eq? Be system, math, text, comparisons, or yet some other subset of the dictionary? What did the programmer who assigned it think like... except we don’t know the programmer personally, and apparently we don’t know all the prefixes used in the basic Retro system.
Any of these conveniences can be given a visibility/actuation button to turn them on and off, so that, with all turned off, the program looks exactly as it does now, which is no doubt pleasing to the community of Retro users.
Words tab:
Pursuant to the problem of figuring out what the system-creator prefixed words with, or just finding the little buggers in the first place, there needs to be some kind of lookup. If it recognized subsets of words and made a list, it would become useful. Like the documentation, it _ought_ to be able to keep your place, and it might keep your last search, but currently, switching tabs returns the Words tab to the beginning.
Vocabulary words:
I spent some considerable time, back in the early 90s, arguing for inclusion of decompiling words and documentation words in the Standard: View, See, etc. You can limit those that decompile from the living code to keep them from decompiling _your_ code, pretty easily, but being able to see the code _we_ write is a must. Even Words, as much of a spew as it is, can be invaluable in the first contact with a new Forth, and frankly, as age settles in, is pretty valuable thereafter.
Those are my reflections on my first hour of experience. I have no doubt that, with enough weeks of reading the documentation and drawing charts and writing code on paper so I can test them immediate, that I will be up to speed with the rest of the community, but those necessities are counter to the principles that Charles Moore established as his reasons for creating FORTH in the first place. Not to mention that no 9-year-old is going to read the documentation for longer than about 2 minutes.
Show less
Needs portrait orientation
This isn't the developer's fault, but the iPhone keyboard is effectively unusable in landscape orientation—and that means an app that requires significant typing, but doesn't support portrait orientation, is unusable too. It's a shame because the language seems attractive, but I just can't cope with it like this.
Show less
Looks good
Be nice if pressing return did an ‘eval’ instead of having to press that button everytime.