2025-04-22 14:22:12 <cleobuline  > tout le monde fait la sieste ?
2025-04-22 14:43:27 <user51      > After a week of no programming, I'm kind of struggling to see what's Forth's niche outside of (1) resource-constrained environments and (2) writing a forth.  I'll even accept (3) "you need to write more forth", but.
2025-04-22 14:46:23 <user51      > The factoring aspect which seemingly always comes up sometimes feels like a virtue out of neccesity, and it feels rather backwards once you get to 32-bits.  I'll be frank and say that I'm 100% a desktop user, so perhaps forth just isn't my niche.
2025-04-22 14:51:02 <vdupras     > Forth is not impervious to irony. The irony is that its constraints are strengths. Virtue out of necessity pretty much sums it up. It's hard to grok, but this process actually has tremendous value. Analogy time:
2025-04-22 14:52:00 <vdupras     > Bike versus motorcycle. At face value, you're better off with a motorcycle. However, forcing yourself to use a bike will force you to train your legs.
2025-04-22 14:53:11 <vdupras     > At the end of the day, a biker with good legs will enjoy the flexibility of their bike and find the motorcycle quite bulky, event if, yes, on the motorway, it always goes faster
2025-04-22 14:54:00 <user51      > vdupras: Nice to see you here, your nick came up up every once in a while when I did forth searches.  :)
2025-04-22 14:55:20 <vdupras     > so in short, as frustrating as it seems, it's (3): train some more. There's really something to it.
2025-04-22 14:55:44 <vdupras     > I think Lisp might be a better gateway drug
2025-04-22 14:56:31 <vdupras     > because it has this same kind of "genius" behind it. But IMO, Forth is more fundamental in its "doing computing as it should be" approach
2025-04-22 14:58:45 <user51      > vdupras: I'm totally willing to buy it without the analogy; in the past I did wonder if the constraint can be a good thing.  That is, it might encourage a solution that otherwise wouldn't have been considered.
2025-04-22 15:03:07 <vdupras     > Now, traditional Forth has been outpaced by hardware gains. I've heard Chuck Moore say that the ideal hardware is something like a 16-or-so-bit machine. I agree and traditional Forth is a perfect fit for this perfect machine
2025-04-22 15:04:15 <vdupras     > Bigger machines are needlessly complex. They are monsters. But we've already made them! The world is already flooded with them?
2025-04-22 15:04:17 <vdupras     > *them!
2025-04-22 15:05:43 <vdupras     > Doing traditional Forth on those machines work, but it does feel underpowered compared to everything else.
2025-04-22 15:06:35 <vdupras     > Because simplicity is at the heart of the Forth way, it's difficult to justify "filling in" that space with complexity because it's all spurious
2025-04-22 15:06:47 <vdupras     > But comparatively, it looks bad
2025-04-22 15:08:06 <vdupras     > So an interesting path I've been taking, which is at odds with traditional Forth, is to ask myself "what if I try to take the revolutionary Forth recipe but accept a certain amount of spurious complexity? How powerful would that system be?"
2025-04-22 15:27:38 <crc         > user51: I don't have a particular niche for forth, but do find it useful & enjoyable in my daily programming
2025-04-22 15:40:45 <crc         > it's not necessarily a practical choice in many cases, but I like it, and it's one of a few languages that a single developer can fully understand & manage
2025-04-22 15:42:59 <crc         > and it's useful for some things involving interactive or low level development
2025-04-22 15:43:00 <crc         > (e.g., I've been writing a small printer driver & application for a label printing project for work, and the interactivity makes it easy to iterate  & debug things)
2025-04-22 15:43:55 <qbit        > hi!
2025-04-22 15:44:15 <crc         > I will note though that my Forth isn't exactly a traditional model. I do build up & use various abstractions that make it more useful to me.
2025-04-22 15:44:19 <crc         > hi qbit
2025-04-22 15:47:04 <anthk_      > hello qbit
2025-04-22 15:47:51 <M-Sci       > Welcome qubit.
2025-04-22 15:49:43 <anthk_      > in forth, I like pforth/pfe, but I like eforth+subleq
2025-04-22 15:55:52 <anthk_      > also, muxleq it's much faster than subleq, and even on my shitty netbooks forth it's almost instant
2025-04-22 16:00:41 <anthk_      > https://github.com/howerj/muxleq/
2025-04-22 16:01:06 <anthk_      > you can reuse the 'hd file' from https://github.com/howerj/ffs with muxleq too
2025-04-22 16:16:47 <xentrac     > haha
2025-04-22 16:17:58 <xentrac     > anthk_: GForth includes a block editor, I think, which I think is written in Forth, maybe even ANS Forth
2025-04-22 16:18:45 <anthk_      > yes, I know, but pfe it's lighter, even if it doesn't have an editor
2025-04-22 16:18:52 <anthk_      > xentrac: would the editor work under pfe?
2025-04-22 16:19:15 <xentrac     > I think the block editor in F83 is also pure Forth, because they tried to keep the asm down to a dull roar to make it portable between 8080, 8086, and 68000
2025-04-22 16:19:49 <M-Sci       > anthk_: W/Transport_triggered_architecture : Memory-Mapped ALU ?
2025-04-22 16:21:15 <xentrac     > user51: I think historically the niche was self-hosted hardware bringup, because it gives you a scriptable interactive shell for reading and writing I/O ports
2025-04-22 16:22:55 <anthk_      > xentrac: open firmware the best 'example' for something better than UEFI
2025-04-22 16:22:59 <xentrac     > anthk_: I'm sure you can port any block editor in Forth to PFE without too much difficulty
2025-04-22 16:23:41 <anthk_      > block format just looks a literal byte dump
2025-04-22 16:24:04 <xentrac     > yeah, openboot/ofw is cool.  in that case the niche was "architecture-independent device drivers"
2025-04-22 16:24:20 <anthk_      > the olpc had a builting wifi connecting tool
2025-04-22 16:24:40 <anthk_      > and I think telnet too, and an http client?
2025-04-22 16:24:54 <anthk_      > so someone bored could write some IRC and gopher client in ofw too
2025-04-22 16:25:26 <anthk_      > now I see people implementing these hacks under uefi... and it's far more difficult
2025-04-22 16:28:08 <anthk_      > on powermac days, people set some ofw settings to fake some devices/versions
2025-04-22 16:28:14 <anthk_      > in order to install further OSX releases
2025-04-22 16:29:30 <anthk_      > btw, the forth error codes, are an standard?
2025-04-22 16:39:18 <xentrac     > there's a list of standardized ones on https://forth-standard.org/standard/exception
2025-04-22 16:41:19 <xentrac     > user51: are you familiar with (ROM) monitors?
2025-04-22 16:42:21 <xentrac     > I was reading the TENEX user manual for its EXEC and the DEC 10/50 monitor manual this weekend, and I had an interesting epiphany
2025-04-22 16:43:55 <xentrac     > on TENEX, Forth, traditional BASICs, ITS, the 10/50 monitor, RT-11, and similar systems, you're sort of locked in a room with a program
2025-04-22 16:45:44 <xentrac     > the idea is that the computer (or virtual machine, in some cases) has a program in memory ("core"), and you can load a saved program, save the current program, start running it, stop it, modify the program, load new pieces of the program from disk, examine its memory, modify its memory, resume running it, etc.
2025-04-22 16:46:41 <xentrac     > and we're sort of used to that kind of interaction these days with the Python REPL or the browser JS console
2025-04-22 16:47:27 <xentrac     > and we can do it for C programs with a debugger
2025-04-22 16:48:46 <xentrac     > but on a lot of these old operating systems, this was just the normal way of interacting with the machine, even with machine code.  If there was a debugger, it was typically in the same memory space with the program
2025-04-22 16:50:51 <xentrac     > in most cases you could save a core image that you could restore later, though Forth lacks that ability (preferring that you recompile), and BASICs only saved the program, not its current variable values
2025-04-22 16:52:12 <xentrac     > early microcomputers like the Altair and IMSAI, as well as most mainframes in the 50s, had hardware switches and lights you could use to start and stop the CPU, examine and change memory, etc.  The oldest mainframes actually had one light on the front panel for every bit of memory in the machine
2025-04-22 16:53:25 <xentrac     > the "monitor" was a software replacement for those switches and lights: a small program that allowed you to start and stop the main program, examine and change memory, etc., using something like a terminal instead of dedicated front-panel hardware
2025-04-22 16:55:08 <xentrac     > nowadays we're sort of accustomed to the user being outside the room, only interacting with their program by sliding slips of paper under its door
2025-04-22 16:56:00 <cleobuline  > xentrac:   there was MacForth plus wich was able to save turnkey
2025-04-22 16:56:41 <cleobuline  > it was a very complete system
2025-04-22 16:57:01 <xentrac     > but at the time it was normal to operate a computer sort of like you'd operate a lathe, with your hands moving its parts around.  and some early timesharing systems like the 10/50 monitor, ITS, and TENEX carried that forward
2025-04-22 16:58:11 <xentrac     > cleobuline: sure, a lot of these systems could save a core image with a complete runnable program
2025-04-22 16:59:06 <xentrac     > and then launch it with little or no user interaction
2025-04-22 17:01:10 <xentrac     > I was reminded of this by anthk_ talking about OpenFirmware, because on Suns you always had a ROM monitor available; you could always stop the operating system and get back to the monitor prompt.  OpenBoot (later renamed OpenFirmware) was a new superpowered monitor that replaced an older, more limited one
2025-04-22 17:02:00 <xentrac     > L1-A would stop SunOS and scroll some of your desktop off the screen to show you the monitor prompt
2025-04-22 17:02:24 <xentrac     > L1 was labeled "Stop" on later Sun keyboards
2025-04-22 17:35:56 <M-Sci       > Something liek a Quake Console :p ?
2025-04-22 17:39:39 <M-Sci       > Speaking of Blocks, why does nobody even mention Open-Channel SSds, which give direct access to device's structure?  AFAIK Exokernel, AKA libOS, would also not stand in Your way.
2025-04-22 17:42:36 <M-Sci       > "dump", which could then have a better name, should provide more information about memory.
2025-04-22 19:03:11 <anthk_      > openfw under the OLPC project: https://wiki.laptop.org/go/Forth_Lessons
2025-04-22 19:03:50 <anthk_      > by comparison, UEFI shells are a turd
2025-04-22 19:06:05 <anthk_      > inb4 "is not user friendly"
2025-04-22 19:06:14 <anthk_      > put a text based menu with choices and everone could use it
2025-04-22 19:06:57 <anthk_      > similar to the text gopher client with selectors like this
2025-04-22 19:06:59 <anthk_      > -> item
2025-04-22 19:07:01 <anthk_      > another item
2025-04-22 19:07:05 <anthk_      > foo bar and so on
2025-04-22 19:07:54 <anthk_      > in the end, a uefi bios UI it's just a chaotic menu (as most BIOSes do)
2025-04-22 19:19:03 <MrMobius    > is there a word like CREATE that can be compiled into a word and takes the name from the next word rather than input? ie : foo CREATE bar ;
2025-04-22 19:25:27 <xentrac     > anthk_: yeah.  being a much better ROM monitor wasn't the main business justification for openboot tho
2025-04-22 19:26:19 <xentrac     > Sun was reacting to the trend where peripheral board manufacturers would ship boards with BIOS extensions on them, unless I'm confabulating
2025-04-22 19:26:43 <xentrac     > the BIOS extension code was 8086 code
2025-04-22 19:26:57 <xentrac     > this obviously put SPARC at a disadvantage
2025-04-22 19:27:55 <xentrac     > so the theory was that openboot made it possible for board manufacturers to target a larger market, if they could get the IBM PC clone makers onboard
2025-04-22 19:28:03 <xentrac     > (they couldn't)
2025-04-22 19:29:38 <user51      > xentrac: Something like blinkenlights https://justine.lol/blinkenlights/?
2025-04-22 19:32:27 <xentrac     > user51: it's an allusion to those front panels, yes
2025-04-22 20:41:02 <M-Sci       > MrMobius: I would "see Create" and Sources of Dictionary Header Constructors and Data Structure.
2025-04-22 20:41:40 <MrMobius    > M-Sci: right you could do that but I was curious if there's a built-in way
2025-04-22 20:41:41 <M-Sci       > I expect "[']" will be needed.
2025-04-22 20:43:56 <M-Sci       > AFAIK Forth "Standatrds" are still so obsessed with constant factors that they do not allow any nesting.  I am not aware of any guideline that would justify such decisions.
2025-04-22 20:44:50 <M-Sci       > As if We are still in 8-bit era where that would be more theoretical than practical.
2025-04-22 20:46:16 <crc         > MrMobius: I'm not aware of anything in the standard for this
2025-04-22 20:47:01 <M-Sci       > I also do not like that there is no interoperability between "Value"s and "Variable"s.  I thnk We should have "at aValue" that result in an Address.
2025-04-22 20:48:09 <crc         > you could use something like `: foo S" CREATE bar" EVALUATE ;`
2025-04-22 20:48:22 <MrMobius    > that's an interesting idea
2025-04-22 20:49:31 <M-Sci       > IMHO "Standardization" and "portability" are excuses for sloppyness.
2025-04-22 20:50:52 <M-Sci       > Spare parts will be left after "porting".
2025-04-22 20:52:48 <xentrac     > & aValue
2025-04-22 20:53:28 <xentrac     > yeah, I think you have to use evaluate or its moral equivalents
2025-04-22 20:53:37 <crc         > I think in forth20xx, you can use EXECUTE-PARSING, as in `: foo S" bar" ['] CREATE EXECUTE-PARSING ;` for this
2025-04-22 20:55:09 <crc         > it appears to work in gforth with the code from https://theforth.net/package/compat/current-view/execute-parsing.fs
2025-04-22 21:06:30 <M-Sci       > Yes... Where is that Factoring?  How do We unFactor Create?
2025-04-22 21:36:57 <M-Sci       > `M-x man gcc' almost killed GNU Emacs.
2025-04-22 22:07:29 <joee        > how to switch to binary representation of numbers on the stack?
2025-04-22 22:28:50 <M-Sci       > Hi joee.  Would `bin' do it?  If not `see .s' and Create Your own.
2025-04-22 22:31:59 <joee        > hm i would like to have 10 with . or .s
2025-04-22 22:32:18 <joee        > 10 = 2
2025-04-22 22:37:37 <M-Sci       > gforth has `bin', `hex', `oct', and `dec'.  I think it even has `Base' "Value".
2025-04-22 22:39:25 <M-Sci       > In Python You could make a Subclass of `int' and override __repr__ to Your liking.  An interesting example would be for Addresses, displayed in hex.
2025-04-22 22:40:27 <M-Sci       > Python dataclass is Poor Man's Algebraic Data Type IMHO.
2025-04-22 22:50:53 <xentrac     > algebraic data types are defined by supporting disjoint-sum and product operations.  `dataclass` supports product, but how do you do disjoint sum?
2025-04-22 23:26:32 <veltas      > 1 1+ BASE !  will set binary in any initial base
2025-04-22 23:46:15 <M-Sci       > xentrac: Good question.  IDK (ATM).  Python finally has, including Syntactic Sugar, `T1 | T2'.
2025-04-22 23:46:50 <M-Sci       > gforth has $F and #9.