IRC channel logs
2026-09-01.log
back to list of logs
<siraben>aggi: a TI-84+ does have a keyboard and yes... you can type on it! <siraben>but it's a terrible experience to be writing Forth on such a device where a mistake crashes and clears your work. unless you want to add stack checking etc. and add 30-40% call overhead <xentrac>19:55 < aggi> reminds me, besides FORTH and LISP in the early days BASIC interpreters were common <xentrac>I think BASIC has always been more popular than Forth, and BASIC been more popular than Lisp since the 01970s <xentrac>but BASIC leaves a lot to be desired for writing things like assemblers or compilers <xentrac>20:28 < aggi> seems to me, C just isn't a most favorable choice for an interactive/shell-type language (FORTH and LISP seem neither btw.) <xentrac>I think interactivity is Forth's strong point actually <xentrac>it may be worth reading this post if you're interested in the question: <xentrac>it specifically talks about what's wrong with languages like C and Python as interactive user interface languages <xentrac>Lisp is a little more flexible there; although it does require some extra parentheses, which are annoying for interactive use, it's possible to dispense with most other punctuation <xentrac>or, if pmem reads from the input stream: pmem 0 bkpt 0 0xbff <xentrac>Lisp with macros or fexprs: (pmem 0 bkpt 0 #xbff) <xentrac>oops, my Forth line should have read <xentrac>on a different note, I think that RPN is more favorable for interactivity than infix syntax. Consider the expression screen[col + width * row]. When you're almost done typing it, it's "screen[col + width * row", at which point an interactive interpreter still can't carry out any operations --- the thing following "row" might be an operation with higher precedence than multiplication, such as (in <xentrac>many languages) exponentiation, function call, field access, or array indexing <xentrac>so it can only give you a limited amount of feedback even in the ideal case; it could display the contents and maybe type of screen, and the values and types of col, width, and row <xentrac>by contrast, with a Forth interpreter, you might type "screen col + width row * + @". This is assuming that "screen" is a "create"d array of characters and that the variables are "value"s or "constant"s rather than "variable"s <xentrac>with this approach you get instant feedback on each operation as soon as you type its name, so you can, in theory, see if you got it wrong. On, say, an HP-48 calculator, this somewhat more the case than in Forth itself; arrays are a different runtime type from integers, and each keystroke is executed immediately <xentrac>whereas in Forth everything is just an integer, and nothing executes or displays until you hit Return <xentrac>Forth's UX is still sort of stuck in the 01970s when everything had to work on teletypes, because you might not have a video display terminal, and direct-manipulation text editing hadn't yet been invented <xentrac>I think you can do significantly better even on a video display terminal; my last example above isn't actually JS+HTML but rather Python and a character-cell terminal emulator <xentrac>but now that we have megapixel multitouch hiDPI displays that can display full-motion video connected to gigaflops processors, we could probably do better than RPN and text for interactive commands