14:22:12
##forth
<cleobuline>
tout le monde fait la sieste ?
14:43:27
##forth
<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.
14:46:23
##forth
<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.
14:51:02
##forth
<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:
14:52:00
##forth
<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.
14:53:11
##forth
<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
14:54:00
##forth
<user51>
vdupras: Nice to see you here, your nick came up up every once in a while when I did forth searches. :)
14:55:20
##forth
<vdupras>
so in short, as frustrating as it seems, it's (3): train some more. There's really something to it.
14:55:44
##forth
<vdupras>
I think Lisp might be a better gateway drug
14:56:31
##forth
<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
14:58:45
##forth
<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.
15:03:07
##forth
<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
15:04:15
##forth
<vdupras>
Bigger machines are needlessly complex. They are monsters. But we've already made them! The world is already flooded with them?
15:04:17
##forth
<vdupras>
*them!
15:05:43
##forth
<vdupras>
Doing traditional Forth on those machines work, but it does feel underpowered compared to everything else.
15:06:35
##forth
<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
15:06:47
##forth
<vdupras>
But comparatively, it looks bad
15:08:06
##forth
<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?"
15:27:38
##forth
<crc>
user51: I don't have a particular niche for forth, but do find it useful & enjoyable in my daily programming
15:40:45
##forth
<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
15:42:59
##forth
<crc>
and it's useful for some things involving interactive or low level development
15:43:00
##forth
<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)
15:43:55
##forth
<qbit>
hi!
15:44:15
##forth
<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.
15:44:19
##forth
<crc>
hi qbit
15:47:04
##forth
<anthk_>
hello qbit
15:47:51
##forth
<M-Sci>
Welcome qubit.
15:49:43
##forth
<anthk_>
in forth, I like pforth/pfe, but I like eforth+subleq
15:55:52
##forth
<anthk_>
also, muxleq it's much faster than subleq, and even on my shitty netbooks forth it's almost instant
16:16:47
##forth
<xentrac>
haha
16:17:58
##forth
<xentrac>
anthk_: GForth includes a block editor, I think, which I think is written in Forth, maybe even ANS Forth
16:18:45
##forth
<anthk_>
yes, I know, but pfe it's lighter, even if it doesn't have an editor
16:18:52
##forth
<anthk_>
xentrac: would the editor work under pfe?
16:19:15
##forth
<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
16:19:49
##forth
<M-Sci>
anthk_: W/Transport_triggered_architecture : Memory-Mapped ALU ?
16:21:15
##forth
<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
16:22:55
##forth
<anthk_>
xentrac: open firmware the best 'example' for something better than UEFI
16:22:59
##forth
<xentrac>
anthk_: I'm sure you can port any block editor in Forth to PFE without too much difficulty
16:23:41
##forth
<anthk_>
block format just looks a literal byte dump
16:24:04
##forth
<xentrac>
yeah, openboot/ofw is cool. in that case the niche was "architecture-independent device drivers"
16:24:20
##forth
<anthk_>
the olpc had a builting wifi connecting tool
16:24:40
##forth
<anthk_>
and I think telnet too, and an http client?
16:24:54
##forth
<anthk_>
so someone bored could write some IRC and gopher client in ofw too
16:25:26
##forth
<anthk_>
now I see people implementing these hacks under uefi... and it's far more difficult
16:28:08
##forth
<anthk_>
on powermac days, people set some ofw settings to fake some devices/versions
16:28:14
##forth
<anthk_>
in order to install further OSX releases
16:29:30
##forth
<anthk_>
btw, the forth error codes, are an standard?
16:41:19
##forth
<xentrac>
user51: are you familiar with (ROM) monitors?
16:42:21
##forth
<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
16:43:55
##forth
<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
16:45:44
##forth
<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.
16:46:41
##forth
<xentrac>
and we're sort of used to that kind of interaction these days with the Python REPL or the browser JS console
16:47:27
##forth
<xentrac>
and we can do it for C programs with a debugger
16:48:46
##forth
<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
16:50:51
##forth
<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
16:52:12
##forth
<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
16:53:25
##forth
<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
16:55:08
##forth
<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
16:56:00
##forth
<cleobuline>
xentrac: there was MacForth plus wich was able to save turnkey
16:56:41
##forth
<cleobuline>
it was a very complete system
16:57:01
##forth
<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
16:58:11
##forth
<xentrac>
cleobuline: sure, a lot of these systems could save a core image with a complete runnable program
16:59:06
##forth
<xentrac>
and then launch it with little or no user interaction
17:01:10
##forth
<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
17:02:00
##forth
<xentrac>
L1-A would stop SunOS and scroll some of your desktop off the screen to show you the monitor prompt
17:02:24
##forth
<xentrac>
L1 was labeled "Stop" on later Sun keyboards
17:35:56
##forth
<M-Sci>
Something liek a Quake Console :p ?
17:39:39
##forth
<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.
17:42:36
##forth
<M-Sci>
"dump", which could then have a better name, should provide more information about memory.
19:03:50
##forth
<anthk_>
by comparison, UEFI shells are a turd
19:06:05
##forth
<anthk_>
inb4 "is not user friendly"
19:06:14
##forth
<anthk_>
put a text based menu with choices and everone could use it
19:06:57
##forth
<anthk_>
similar to the text gopher client with selectors like this
19:06:59
##forth
<anthk_>
-> item
19:07:01
##forth
<anthk_>
another item
19:07:05
##forth
<anthk_>
foo bar and so on
19:07:54
##forth
<anthk_>
in the end, a uefi bios UI it's just a chaotic menu (as most BIOSes do)
19:19:03
##forth
<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 ;
19:25:27
##forth
<xentrac>
anthk_: yeah. being a much better ROM monitor wasn't the main business justification for openboot tho
19:26:19
##forth
<xentrac>
Sun was reacting to the trend where peripheral board manufacturers would ship boards with BIOS extensions on them, unless I'm confabulating
19:26:43
##forth
<xentrac>
the BIOS extension code was 8086 code
19:26:57
##forth
<xentrac>
this obviously put SPARC at a disadvantage
19:27:55
##forth
<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
19:28:03
##forth
<xentrac>
(they couldn't)
19:32:27
##forth
<xentrac>
user51: it's an allusion to those front panels, yes
20:41:02
##forth
<M-Sci>
MrMobius: I would "see Create" and Sources of Dictionary Header Constructors and Data Structure.
20:41:40
##forth
<MrMobius>
M-Sci: right you could do that but I was curious if there's a built-in way
20:41:41
##forth
<M-Sci>
I expect "[']" will be needed.
20:43:56
##forth
<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.
20:44:50
##forth
<M-Sci>
As if We are still in 8-bit era where that would be more theoretical than practical.
20:46:16
##forth
<crc>
MrMobius: I'm not aware of anything in the standard for this
20:47:01
##forth
<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.
20:48:09
##forth
<crc>
you could use something like `: foo S" CREATE bar" EVALUATE ;`
20:48:22
##forth
<MrMobius>
that's an interesting idea
20:49:31
##forth
<M-Sci>
IMHO "Standardization" and "portability" are excuses for sloppyness.
20:50:52
##forth
<M-Sci>
Spare parts will be left after "porting".
20:52:48
##forth
<xentrac>
& aValue
20:53:28
##forth
<xentrac>
yeah, I think you have to use evaluate or its moral equivalents
20:53:37
##forth
<crc>
I think in forth20xx, you can use EXECUTE-PARSING, as in `: foo S" bar" ['] CREATE EXECUTE-PARSING ;` for this
21:06:30
##forth
<M-Sci>
Yes... Where is that Factoring? How do We unFactor Create?
21:36:57
##forth
<M-Sci>
`M-x man gcc' almost killed GNU Emacs.
22:07:29
##forth
<joee>
how to switch to binary representation of numbers on the stack?
22:28:50
##forth
<M-Sci>
Hi joee. Would `bin' do it? If not `see .s' and Create Your own.
22:31:59
##forth
<joee>
hm i would like to have 10 with . or .s
22:32:18
##forth
<joee>
10 = 2
22:37:37
##forth
<M-Sci>
gforth has `bin', `hex', `oct', and `dec'. I think it even has `Base' "Value".
22:39:25
##forth
<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.
22:40:27
##forth
<M-Sci>
Python dataclass is Poor Man's Algebraic Data Type IMHO.
22:50:53
##forth
<xentrac>
algebraic data types are defined by supporting disjoint-sum and product operations. `dataclass` supports product, but how do you do disjoint sum?
23:26:32
##forth
<veltas>
1 1+ BASE ! will set binary in any initial base
23:46:15
##forth
<M-Sci>
xentrac: Good question. IDK (ATM). Python finally has, including Syntactic Sugar, `T1 | T2'.
23:46:50
##forth
<M-Sci>
gforth has $F and #9.