You can navigate up and down the menu with the arrow keys and pick the keyword you want with the ENTER key, or you can just press the corresponding number/letter (which is much faster). You can also left-arrow and right-arrow to related submenus. For example, that "I/O" next to "CTL" is this menu:
There are never more than 3 submenus associated with any key, so you either get the menu you want, or you are only a single left or right arrow away. Menus (except the "Catalog" of all commands) have a maximum length of 35 entries, so you can always select a menu item by typing its corresponding number or letter (assuming you already know it). The worst case is 4 keypresses: faceplate button (like PRGM, MATH, or LIST), left- or right-arrow (if you need a non-default submenu), the ALPHA key (to type a letter), and the letter of a command more than 10 entries down in the menu.
This is exactly the way that all menus work on the calculator, and all of the actions you can pick at the REPL are also valid program entries. The more familiar you are with using the calculator in general, the easier it gets to program them. I wrote a lot of TI-BASIC in high school in the early 2010's, and had a lot of the menus memorized. Typing the programs in was definitely not the hard part.
The only times you use alphabetical input when writing TI-BASIC are:
* writing string literals
* typing a one-letter variable name
* referencing a custom-named list that hasn't yet been created, or has been deleted and already deleted.
It's interesting to note that this is essentially a domain-specific structural editor; each keypress is a full lexical token that happens to be valid in the TI-BASIC programming language, and a different input mode is triggered for full alpha/numeric input. That's how one can cope with an input method that's as low in bandwidth as a fiddly calculator keyboard.
Eh, not really. The calculator won't stop you from creating syntactically-incorrect programs. You can enter any nonsense you like. Errors are detected at runtime. You get one of 8 (I think?) error codes, and can Goto the line that the error is on. Figuring out what is actually wrong is up to the user, and often requires consulting the manual.
While I was in high school, some people figured out that they could write notes in their calculator as programs, and covertly reference them during tests. The calculators didn't care at all about having unquoted strings and nonsense math stored in the programs, because the students never ran them. The teachers caught on to this and started checking that calculators were wiped before tests.
This is a fairly typical approach for old-school BASIC. Back in 80s, most BASIC microcomputers used a similar approach to entering tokens, despite having proper alphanumeric keyboards. For example, look at the keyboard of this ZX Spectrum:
It's not just input, either: many of those systems stored programs in pre-tokenized binary form, as well. It makes a lot of sense when your RAM and storage space is that limited.
Debugging wasn't too bad. The constraints I remember running into all the time are:
* The editor is on a 16-column 8-row display, but the leftmost column always starts with the a ":" and the top row always has the name of the program, so it's more like a 15x7 display.
* There are only 27 numeric variables (A-Z and Theta), and X and Y get manipulated whenever you do plotting commands, but you can use the "Answer" variable to pass arguments and results to and from program calls.
* There are only 10 string variables, but they are not limited in length (except by total available memory), and you can use eval() on substrings (commence evil laughter!).
* Lists have a maximum length (I think 999 items?), but because numbers take up a variable amount of memory, you might run out of memory before the list is full. Or not, it depends!
* Same deal with matricies. Finite size (maybe 99x99?), and stored sparse in memory. The number of cells you can write to depends on what numbers you're writing.
* All variables are global. (Recursive programs require you to manually save and restore state.)
* TI-Basic's interpreter is REALLY slow. Not just because it's a Z80 running at 8 or 12 MHz, it really is inefficient. I learned good tricks (memoization) and terrible ones (omit trailing parentheses, commas, and double-quotes) to make programs faster.
* Comments make your code slower (and change the content of the "Answer" variable).
Between all of those, I spent way more time writing (and running) programs than debugging them. Fun times!
This is exactly the way that all menus work on the calculator, and all of the actions you can pick at the REPL are also valid program entries. The more familiar you are with using the calculator in general, the easier it gets to program them. I wrote a lot of TI-BASIC in high school in the early 2010's, and had a lot of the menus memorized. Typing the programs in was definitely not the hard part.
The only times you use alphabetical input when writing TI-BASIC are: * writing string literals * typing a one-letter variable name * referencing a custom-named list that hasn't yet been created, or has been deleted and already deleted.