2026-01-30 06:53:19 <tpbsd       > Ive been force feeding on neovim setup with the help of my AI, which at times seems annoyed anyone can be as dense as I am !
2026-01-30 06:54:02 <tpbsd       > at least I now have Forth color syntax working
2026-01-30 07:47:16 <tpbsd       > I've been using "fabric" as a CLI agent for AI, it's very handy for issues like learning neovim config
2026-01-30 09:48:14 <veltas      > I have a love-hate relationship with LLMs
2026-01-30 09:49:34 <tpbsd       > veltas, I have a much stronger hate relationship with Python I must admit
2026-01-30 09:50:18 <tpbsd       > mainly as Python is used in many AI interfaces and it's a PITA of conflicting versions that wont play together
2026-01-30 09:53:01 <tpbsd       > veltas, sure, Google before it became useless with paid ads ranking responses highly, was about the same use as I get from AI these days with 'fabric' which I use to access Kimi-K2 AI via my command line
2026-01-30 09:53:56 <tpbsd       > I use it with apps I have to configure but dont know well, and which have hopeless docs
2026-01-30 09:54:56 <veltas      > Oh I've hated Python for a while
2026-01-30 09:55:56 <veltas      > I can't think of anything more useless than a language that has so many books dedicated to how to write in it, and yet any sensible person would avoid writing anything but short programs in it
2026-01-30 09:56:19 <veltas      > There are a lot of languages/frameworks like this though
2026-01-30 09:56:19 <tpbsd       > agreed
2026-01-30 09:57:44 <tpbsd       > I mean Im a dedicated Forth langiage lover, but don't mind C, Lua, xml, Pascal, Assembly, Scheme
2026-01-30 09:59:09 <veltas      > Not a JSON fan?
2026-01-30 09:59:28 <tpbsd       > Ive written a Lua pop up window for CMSIS-SVD and it was pretty easy, works great and it's running in Neovim. I could do that but couldnt get the Forth syntax color highlighting working in Nvim, go figure!
2026-01-30 10:00:01 <tpbsd       > Ive never used JSON, and Im perfectly comfortable with XML
2026-01-30 10:00:09 <veltas      > Lua benefits by being small and quick to fully 'learn', but they're still making it more complicated and more bloated each release so it's harder to justify liking it
2026-01-30 10:00:36 <veltas      > The siren's call to small languages is the ease of which new features can be added, but which likewise quickly stop it being a small and sweet language
2026-01-30 10:00:45 <veltas      > It's hard to have the 'taste' to avoid doing this to a small lang
2026-01-30 10:01:04 <tpbsd       > I must admit my fav editor is Helix which is written in Rust, it's seriously well desighed
2026-01-30 10:01:15 <veltas      > I've never tried it, maybe I will
2026-01-30 10:01:22 <veltas      > I wonder if it would even run on my laptop lol
2026-01-30 10:01:30 <veltas      > Can it run in a terminal?
2026-01-30 10:01:41 <tpbsd       > if VIM run on it, then Helix will
2026-01-30 10:02:00 <tpbsd       > sure, I only use it in a xterm
2026-01-30 10:02:16 <tpbsd       > well in a Alacritty term
2026-01-30 10:03:38 <tpbsd       > Helix (hx) is fast and awesome and about 90% VIM compatible, but it differs in a few ways by design, so it's not the same or equivalent to VIM
2026-01-30 10:03:47 <MrMobius    > Lua is kind of interesting but never got that far with it. I have a calculator you can program in Lua
2026-01-30 10:04:10 <MrMobius    > Can you compile out some of the bloat?
2026-01-30 10:04:21 <tpbsd       > MrMobius, thats cool, Ive only done the Pop up
2026-01-30 10:04:57 <MrMobius    > I had to use a hideous thing called AutoHotkeys today. I'm confident that it's worse than bash which has been my most hated language up until now
2026-01-30 10:05:06 <veltas      > MrMobius: Because Lua is all about static linking, you can always just use an old version
2026-01-30 10:05:28 <veltas      > Or luajit which hovers around version 5.1/5.2
2026-01-30 10:05:33 <tpbsd       > I always use 'sh' instead of 'bash' myself
2026-01-30 10:05:57 <MrMobius    > veltas: ya makes sense. I've never gone down that road with programming languages or anything else because I'm not sure what in the newer release is a feature vs a bug fix
2026-01-30 10:06:16 <MrMobius    > unless the versioning is such that features are frozen and only bugs get fixed
2026-01-30 10:07:20 <veltas      > awk would be quite a good simple scripting language if it had locals and better handling of implicit types/references
2026-01-30 10:07:42 <tpbsd       > veltas, I seriously recommend you should at least install Helix and in it type ":tutor" and do a quick run thru
2026-01-30 10:08:00 <veltas      > I'll give it a shot tpbsd, but I suspect it will be too slow for regular use
2026-01-30 10:08:10 <veltas      > Also looks like it wouldn't work over serial
2026-01-30 10:09:17 <veltas      > I often work on 115K serial terminals and vim works quite well with those, I am guessing a lot of newer vim-like programs never test on limited baud terminals
2026-01-30 10:09:21 <tpbsd       > veltas, whats in your laptop ? a 1MHz 8080 ?
2026-01-30 10:09:26 <veltas      > lol
2026-01-30 10:09:38 <veltas      > No it's a Core 2 Duo
2026-01-30 10:09:59 <veltas      > I'll try it out but by 'slow' I mean it takes more than a second to load when I go to edit a file
2026-01-30 10:10:09 <tpbsd       > veltas, I must admit, Ive no idea how Helix would work in that case
2026-01-30 10:10:11 <veltas      > Or I get lots of pauses doing normal operations
2026-01-30 10:10:20 <veltas      > Yeah only way to find out is to try it
2026-01-30 10:10:42 <veltas      > Also I might need to build it, in which case because it's Rust I might not have enough RAM
2026-01-30 10:11:04 <tpbsd       > ahh
2026-01-30 10:11:10 <veltas      > These problems were solved in the 50s/60s by people like Grace Hopper but somehow we keep recreating them
2026-01-30 10:11:42 <tpbsd       > yeah, humans specialise in tripping over
2026-01-30 10:12:27 <veltas      > I think calling it "a post-modern text editor" is bloody foolish though, a lot of people will be turned off by that
2026-01-30 10:12:44 <veltas      > But I can see they say it's just "a joke" and their repo etc look pretty apolitical
2026-01-30 10:14:47 <tpbsd       > it's my favorite editor thesedays and so easy to configure for LSP's
2026-01-30 10:15:35 <tpbsd       > in fact I wrote a Forth LSP that uses pylsp using Helix
2026-01-30 10:16:18 <tpbsd       > I still cant work out how to connect that LSp to any other 'LSP compliant' editor than Helix
2026-01-30 10:45:29 <iv4nshm4k0v > I'm averse to Rust, hence anything written in it is "software I can't edit," and it's something I try to avoid.
2026-01-30 10:59:49 <veltas      > tpbsd: https://aashvik.com/posts/555-revolution/
2026-01-30 11:00:19 <veltas      > iv4nshm4k0v: I'm too stupid to write Rust so yes for a different reason
2026-01-30 11:00:41 <veltas      > Also I think the borrow checker is a bit totalitarian for most programming
2026-01-30 11:02:33 <tpbsd       > veltas, I'm so tired of 555 articles, I used that thing for 20 years and I know it intimately. It's day is long gone, like the T-Model Ford
2026-01-30 11:03:50 <tpbsd       > veltas, a MSP430 can cost 20 cents, why would anyone use a 555 in preference to it ?
2026-01-30 11:05:38 <tpbsd       > somewhere there must be a stock of billions of 555 someone wants to sell
2026-01-30 11:15:23 <veltas      > I will add context that the article was published on 1 April
2026-01-30 11:15:51 <tpbsd       > ahh!
2026-01-30 11:16:33 <veltas      > When I was in school they had us solder a 555 circuit and never explained what it was or anything, so I had no clue what I was doing
2026-01-30 11:16:39 <veltas      > But I did make a blinky LED
2026-01-30 11:19:53 <tpbsd       > it just charges a capacitor to a vref and then discharges it to make an analog timer
2026-01-30 11:20:06 <tpbsd       > thats basically all it does
2026-01-30 11:20:55 <tpbsd       > any MSP430 has far faster and infinetly slower timing capabalities that are far more accurate
2026-01-30 11:21:20 <tpbsd       > and you dont need any external components
2026-01-30 11:21:34 <tpbsd       > and you can run Forth on it
2026-01-30 12:22:37 <iv4nshm4k0v > Well, unlike MSP430, 555 won't hang due to a bug in your code.
2026-01-30 12:25:20 <tpbsd       > iv4nshm4k0v, true, but it will hang due to a bug in your wiring or component value selection :)
2026-01-30 12:33:16 <iv4nshm4k0v > Components, unless faulty, won't change their values mid-operation - unlike RAM / registers.  Designing analog circuits is somewhat of a lost knowledge by now, and they're indeed harder to get right, but they are easier to test as well.
2026-01-30 12:33:43 <veltas      > Looks like you weren't here for tpbsd's pre-CMOS rant the other day lol
2026-01-30 12:44:57 <veltas      > I wish I knew more about this stuff, but wishing is not doing
2026-01-30 12:55:26 <iv4nshm4k0v > As to Rust, IIRC there was an old (1980s, perhaps?) study that found that /bug density/ of the code a given programmer produces is largely independent of the programming language used.  From whence, if you want less bugs, make code shorter.  (Or hire a better programmer.)
2026-01-30 12:55:26 <iv4nshm4k0v > A programming language /may/ eliminate a given class of bugs, but that only means that other kinds of bugs will manifest more often.
2026-01-30 12:57:21 <iv4nshm4k0v > ... Back when I've just switched to GNU/Linux in 1999, my Internet connectivity was rather limited, so I mostly downloaded sources and built them myself - the thing was that were I to download a pre-built binary, and find a bug there later, I'd need the respective source too - and I might lack connectivity to get it at the moment.
2026-01-30 12:57:22 <iv4nshm4k0v > When I've got wider bandwidth, I've switched to Debian binaries; the idea was that this way, were I to /report/ a bug, it'd be potentially easier to reproduce, as the maintainer(s) would have access to the very same binary I've encountered the bug with.
2026-01-30 13:10:27 <veltas      > Where did Debian say this in less-exaggerrated form?
2026-01-30 13:13:16 <veltas      > Are you on 80486?
2026-01-30 13:58:58 <KipIngram   > Ah, I've been thinking about this new system and had a nice breakthrough, I think.  For ages I've been circling the whole compile/meta-compile, live system / target system business.  It's been this Gordion's knot I couldn't quite find the string to pull on.  This morning I've hit on the idea of a definint word "image."  <parameters> image <image name>.  Executing an image name will make it the
2026-01-30 13:59:01 <KipIngram   > target for new compilation.  The running system will have built-in image name "live".
2026-01-30 14:00:12 <KipIngram   > CURRENT will always refer to a vocabulary that has to exist in the currently targeted image.  But each image will have its own search path for looking up words, and we'll be aware of a pair of those.  When STATE=0, we'll use the search path for the running system; when STATE=1 we'll use the search path for the target system.
2026-01-30 14:00:25 <KipIngram   > Suddenly a whole lot of things seem a lot more clear to me.
2026-01-30 14:00:53 <veltas      > Interesting
2026-01-30 14:01:04 <veltas      > I've come to conclusion you might as well just write assembly
2026-01-30 14:01:25 <veltas      > But good luck with the cross compiler, it just never feels too forthy when all is done
2026-01-30 14:01:45 <KipIngram   > Well, I've struggled with thath same debate, frankly.  The fastest way to get "a system" done would be to just write it, the same way I always have.
2026-01-30 14:01:55 <KipIngram   > But I really would like to solve this problem once and for all.
2026-01-30 14:02:06 <veltas      > If that's your goal then go for it
2026-01-30 14:02:26 <veltas      > And good luck
2026-01-30 14:03:01 <KipIngram   > Yeah, that "self-beating" I've done the last few days seems to have worked - I've been focused in on this a lot more the last day or two.  Still just at the concept level, but it's sharpening up quite a lot.
2026-01-30 14:03:44 <KipIngram   > When I do start writing this Python thing, I want to be really clear on what I'm about to write.  I don't want to start writing and then find myself wandering around.
2026-01-30 14:04:47 <veltas      > Are you a morning thinker or an evening thinker?
2026-01-30 14:04:51 <KipIngram   > I'm also toying with the idea of giving the Python some emulation capability, but that's really an entirely separate functionality.
2026-01-30 14:05:24 <KipIngram   > Mostly a morning thinker, because evenings my wife's around and we socialize.  I still might be "working on something," but truly deep focus is harder.
2026-01-30 14:06:06 <veltas      > I'm a morning thinker to an extreme extent, I can do some incredible stuff right after I wake up
2026-01-30 14:06:09 <veltas      > And it's downhill from there
2026-01-30 14:06:11 <KipIngram   > In the morning I'm usually up hours ahead of her; my cat cuddles up on the sofa by me and goes to sleep, and I can really drill in.
2026-01-30 14:07:22 <KipIngram   > Usually I just shift my focus and do more lightweight things in the evenings.  I've been watching a lot of ancient history videos here lately.
2026-01-30 14:08:00 <KipIngram   > If you like such things there's a YouTube channel called "Fall of Civlizations" that has some really good, detailed content.
2026-01-30 14:08:52 <KipIngram   > I'm in the middle of a five-hour plus episode on the Persians right now.
2026-01-30 14:09:20 <KipIngram   > Iran and Iraq have been at each other's throat for thousands of years, man.
2026-01-30 14:09:31 <KipIngram   > It's nothing new.
2026-01-30 14:10:05 <KipIngram   > The names have just changed - back then it was Persia and Babylon.
2026-01-30 14:17:27 <veltas      > Hey KipIngram I've been thinking recently that the UNIX model might be the only sane way to get out of DLL hell and also endless naming collisions and avoid the perils of namespacing etc
2026-01-30 14:17:44 <veltas      > I.e. the model where you have small well defined processes that do 'one thing'
2026-01-30 14:18:02 <veltas      > Have you thought about this, and do you think this could apply in Forth as well somehow?
2026-01-30 14:18:35 <veltas      > In Forth the main way I can see this applying would be loading the relevant word to do 'one thing' and processing some data saved to storage or RAM, and then FORGET and load the next word
2026-01-30 14:18:55 <veltas      > I'm sure there's more sophisticated ways of doing that but you quickly delve into OS territory
2026-01-30 14:19:07 <veltas      > I know you think about design of more sophisticated forth systems
2026-01-30 14:25:54 <iv4nshm4k0v > veltas: http://debian.org/releases/stable/release-notes/issues.en.html regarding supported architectures, and also news:LM4el-9tsu-5@gated-at.bofh.it (Message-Id: 20251031213541.GA73786@debian.org in the Debian mailing lists) regarding APT (a core part of Debian) heading Rust-wards.  NetBSD has "portability" as an explicit project's goal.
2026-01-30 14:25:55 <iv4nshm4k0v > FTR, my "486" MB (Socket 3, but with Am5x86 installed) is sadly out of order (fails to boot with a "BIOS ROM checksum error" message), but I have several working "586" (Socket 7) combos.  Haven't actually tried to run NetBSD there, but people who did report that it "just works."  (And packages built for NetBSD/i486 do run on NetBSD/amd64.)
2026-01-30 14:30:25 <veltas      > Ah that sucks but I can't blame them, they don't have resources to support proper old 32-bit processors
2026-01-30 14:30:51 <veltas      > I think for a while now the experience on 32-bit has been very sub-par and not to the standards that Debian want
2026-01-30 14:31:29 <veltas      > NetBSD interestingly runs particularly badly on older hardware I've tried it on
2026-01-30 14:31:37 <iv4nshm4k0v > I think for a while now my experience with Debian has been very sub-par and not to the standards that I want.
2026-01-30 14:31:56 <veltas      > I think there's a sweet spot but the old wifi tech I tried I would have had to try fixing the driver
2026-01-30 14:32:12 <veltas      > I wish my experience was better because NetBSD's ethos is the sort of thing I'd love
2026-01-30 14:32:28 <veltas      > I would have tried fixing the driver but I couldn't find anyone interested in helping me do so
2026-01-30 14:32:55 <veltas      > And it was right around the time I had to start doing some life stuff, can't remember but probably selling my house or something, so needed a working computer
2026-01-30 14:33:24 <veltas      > I tried it on a couple of laptops and one the wifi was totally messed up, proprietary firmware couldn't load properly
2026-01-30 14:33:39 <veltas      > other one the driver constantly reset the connection, like every minute
2026-01-30 14:33:45 <veltas      > It couldn't download big files etc
2026-01-30 14:33:58 <iv4nshm4k0v > Support for peripherals is certainly lacking, indeed.  Linux has much more people willing to hire programmers to write (and debug) drivers.  Sometimes reverse-engineer the proprietary tech as well, which ain't something one'll be doing in their spare time.
2026-01-30 14:34:25 <veltas      > There's not a lot of interest in NetBSD, you might want to try e.g. OpenBSD which is kind of similar ethos but more focused on security, and seems to have more users
2026-01-30 14:34:53 <veltas      > I've not tried it yet, it's the last on my BSD world tour to mess with
2026-01-30 14:35:55 <iv4nshm4k0v > The last I've heard, current OpenBSD won't run i486, either.  My understanding is that most of the *BSDs out there either support amd64 only, or support only a few architectures.  NetBSD runs on VAX.
2026-01-30 14:36:41 <veltas      > That's funny because I know OpenBSD was a fork from NetBSD by someone who did a lot of the porting, but yeah I guess the focus became security ultimately
2026-01-30 14:37:56 <veltas      > iv4nshm4k0v looks like OpenBSD supports i386 still
2026-01-30 14:38:32 <veltas      > Ah right it says "Intel Pentium or later"
2026-01-30 14:38:39 <veltas      > so is more i586
2026-01-30 14:38:40 <crc         > OpenBSD requires at least a pentium
2026-01-30 14:38:56 <veltas      > Sorry for making you write that crc :P
2026-01-30 14:39:39 <veltas      > Well iv4nshm4k0v maybe we need to have a NetBSD party and help each other get it working on our hardware
2026-01-30 14:39:49 <veltas      > Does anyone here remember Linux parties?
2026-01-30 14:43:27 <iv4nshm4k0v > That's a common misunderstanding; "i386" is mostly used as a synonym to what's more properly called "IA-32" or "x86-32."  Debian "i386" required "Pentium Pro (i686) or later" since Stretch, for instance.  NetBSD "i386" has been "i486 or later with an FPU" since, I think, the 1990s.
2026-01-30 14:55:38 <iv4nshm4k0v > Good to know that OpenBSD still runs on Pentium.  Still, I've been using Linux "device mapper" and LVM rather heavily for a couple of decades now, and NetBSD having a (partial and rather limited) implementation was a deciding factor when I've been "shopping for BSDs" several years ago due to my disappointment in Debian.  Now I kinda like their stance on portability, too.
2026-01-30 15:04:38 <veltas      > I'll say when distros include or exclude 80486 or 80386, it's over a handful of edge-case instructions that usually don't matter
2026-01-30 15:05:03 <veltas      > But obviously matter if you're on one of those archs
2026-01-30 15:08:28 <MrMobius    > "A programming language /may/ eliminate a given class of bugs, but that only means that other kinds of bugs will manifest more often." <- why is that?
2026-01-30 15:10:51 <iv4nshm4k0v > It is my guess based on the results of an old study I don't even have a citation for.  If the "bug density" for a particular programmer doesn't depend on the language used, then the number of bugs in, say, 100 KiB of source code would be more or less constant, regardless of language.  If some bugs /cannot/ be there, there will be others instead.
2026-01-30 15:10:51 <iv4nshm4k0v > veltas: In Debian, I believe the problem was that the likes of Firefox and VLC started requiring SSE2 and such.  The choice was, more or less, between requiring i686 for the "i386" port - or not including such software in that port at all.  (Or to have in the same port both the software that will and will not work on a given CPU.)
2026-01-30 15:14:04 <iv4nshm4k0v > MrMobius: If you have a newer study that shows that the number of bugs per "unit of code" /does/ depend on the language used, I'd be willing to read it.  The "language landscape" certainly changed over the past decades, so I suppose some knowledge might no longer be valid anymore.
2026-01-30 15:15:47 <MrMobius    > iv4nshm4k0v: I havent seen the study on the amount of bugs being the same but I'll take your word for it
2026-01-30 15:16:25 <MrMobius    > and it's based on bugs per source code unit not time spent? I wonder how they address some languages having much shorter source code for the same function
2026-01-30 15:16:42 <MrMobius    > which would mean less bugs per program if the language was more concise
2026-01-30 15:17:18 <MrMobius    > not that I'm saying it matters either way. just curious about your reasoning :)
2026-01-30 15:20:36 <iv4nshm4k0v > I can't find the reference to that study in my records, alas.  I /think/ they've been counting lines-of-code, but I may be misremembering.  Personally, I'd be counting "language constructs," so that ": FOO BAR BAZ ;" is "5 units", and "s/a[bc]+d/e/g" is perhaps "7 units" or so.
2026-01-30 15:23:53 <veltas      > I'd count bytes (well if I researched I'd count everything and show the results)
2026-01-30 15:24:21 <veltas      > Or maybe compressed bytes
2026-01-30 15:35:23 <iv4nshm4k0v > Other than that, having something you need built into the language means your code will be shorter, but it also means that you won't make your bug inside that builtin - by the virtue of not implementing it.  So the amount of code is /ought/ to correlate with the number of bugs.  Hence "bug density."
2026-01-30 15:48:54 <veltas      > From a more constructivist standpoint, I can't help but notice a lot of advice I saw for Rust borrow checker workarounds to be to essentially simulate pointers with indices
2026-01-30 15:49:29 <veltas      > And I can say from working on VB6 legacy code that using indices into lots of arrays can introduce a lot of bugs, albeit not memory bugs in memory-safe langs
2026-01-30 15:49:46 <veltas      > But certainly similar kinds of bugs, just with less crazy security implications in normal cases
2026-01-30 15:50:30 <veltas      > My biggest issue with Rust is the borrow checker is solving a problem that only applies to like 1% of code by making 99% of code much harder to write
2026-01-30 15:53:35 <cleobuline  > If the angels pooped we would all be in trouble
2026-01-30 15:57:55 <iv4nshm4k0v > It kinda depends on your typical code, as well as your typical bugs.  Different languages constrain programmers in different ways, and from what I've seen, the chances that a given language will help you avoid all *your* typical issues - and only them - are pretty slim.  Say, Nils Holm recounted making a bug in "typeless" T3X once that C's type system wouldn't have prevented either.
2026-01-30 16:00:26 <vms14       > i stole create and does> from forth :0
2026-01-30 16:00:37 <vms14       > : counter create , does dup 1 swap +! @ end ;
2026-01-30 16:00:53 <vms14       > 0 counter some-counter
2026-01-30 16:00:59 <iv4nshm4k0v > (My experience with Scheme and Emacs Lisp certainly helped me to learn write better code, but I won't go so far as to claim they'll help /everyone./)
2026-01-30 16:01:13 <vms14       > in mine does neds an 'end' delimiter and can be used outside a definition
2026-01-30 16:01:26 <vms14       > needs*
2026-01-30 16:01:45 <vms14       > and memory is a js array so you can store the whole universe in a cell xd
2026-01-30 16:02:31 <vms14       > that's the interpreter: https://gitlab.com/vms14/oh/-/blob/master/oh.js
2026-01-30 16:03:53 <vms14       > i was stealing some words from forth yesterday like create does ! +! >r r> r@ 2>r... although the return stack is not used, only for do loop +loop and most words are different since the interpretr is not really a forth
2026-01-30 16:04:24 <vms14       > but i like that counter example and i think i should lean more to the forth way even if the language is actually very different
2026-01-30 16:06:04 <vms14       > create does not increment the here pointer so you can create multiple words that refer to the same memory address but can have different runtime behavior with does, which is cool
2026-01-30 16:06:47 <veltas      > iv4nshm4k0v: The thing the borrow checker is solving that I think is too restrictive is multithread safety.  As a result a lot of code ends up being written with communication, queues, etc, for no good reason other than to shut up the compiler because you weren't going to use multiple threads anyway
2026-01-30 16:07:05 <veltas      > And that's the selling point of rust, fearless concurrency, but I just don't value that as a feature
2026-01-30 16:07:29 <veltas      > And it sucks that people are being sold rust as a general purpose lang when it's not really that, it's actually quite quirky for behaving this way
2026-01-30 16:07:32 <veltas      > Seems it to me anyway
2026-01-30 16:10:48 <iv4nshm4k0v > The way I see it, every language is like that.  Perl /is/ quirky, but its quirks /do/ match my expectations, so to me, writing Perl feels fairly natural.
2026-01-30 16:11:18 <vms14       > perl trusts the programmer and that's something i need
2026-01-30 16:12:20 <vms14       > i need to test ideas and see them explode, so the language should allow me to do that
2026-01-30 16:13:14 <veltas      > iv4nshm4k0v: The difference is I don't see a big "rewrite in Perl" movement with government backing
2026-01-30 16:15:09 <iv4nshm4k0v > Ah.  Well, I'd be more inclined to blame gov't, than a language, anyway.
2026-01-30 16:23:21 <veltas      > That's getting a bit semantic, by 'rust' I mean the lang, community, et al because it's all related to me
2026-01-30 16:23:40 <veltas      > If I look at just the lang on its own I could see it your way, but they're a bit inseparable
2026-01-30 16:24:22 <veltas      > e.g. I want to just look at 'C' but can't really separate it from GCC, and ISO C committee, and Linux, etc.  They are all part of C, culture, etc
2026-01-30 16:24:49 <veltas      > Which sucks because pretty much all the above are tired of C and want Rust to take over, and are borderline sabotaging it and treating it like a meme
2026-01-30 16:25:03 <veltas      > Except GCC really
2026-01-30 16:27:13 <veltas      > One advantage of Forth is that an individual can be dangerous with it, and also maintain their own Forth realistically
2026-01-30 16:27:35 <veltas      > I'm interested in any lang like that, Forth is one of the better and more interesting ones I've seen
2026-01-30 16:40:22 <cleobuline  > forthBot: LOAD ini.fth
2026-01-30 16:40:23 <forthBot    > File ini.fth with MOON  loaded
2026-01-30 16:40:31 <cleobuline  > forthBot:  CREDIT
2026-01-30 16:40:32 <forthBot    > Brought to you by Cleobuline updated with hashtable with the help of Grok  https://github.com/cleobuline/forth-bot-gmp-irc-threaded-multi-users/tree/main Site https://labynet.fr
2026-01-30 16:41:05 <cleobuline  > forthBot:  MOON
2026-01-30 16:41:05 <forthBot    > Phase de la lune pour Fri January 30 2026
2026-01-30 16:41:05 <forthBot    > 🌔 Gibbeuse croissante La lune grossit, revez grand ce soir ! Illumination 93%
2026-01-30 16:44:29 <vms14       > veltas: if i were to steal the power of forth, what do i actually have to steal? :0
2026-01-30 16:46:11 <cleobuline  > the stack
2026-01-30 16:47:11 <vms14       > the stack and the syntax for colon words were the first things i stole
2026-01-30 16:47:23 <vms14       > but never the return stack
2026-01-30 16:47:40 <cleobuline  > forthBot:  CAT
2026-01-30 16:47:41 <forthBot    >    /_/
2026-01-30 16:47:41 <forthBot    >   > ^ <
2026-01-30 16:47:41 <forthBot    > ( o.o )
2026-01-30 16:47:47 <vms14       > and i'm faking memory and see power in create and does
2026-01-30 16:48:54 <vdupras     > the stack by itself is nothing, the dictionary by itself is nothing, immediates by themselves are nothing, "here" by itself is nothing. Blend them skilfully and you've got something great. It's hard to pick a part without losing the whole magic
2026-01-30 16:48:59 <vms14       > since my memory is fake it can take any object, i can create multiple words and assign them to the same memory location with different runtime behavior, no matter what the cell points to since it's just a js array
2026-01-30 16:50:03 <vms14       > i like how in forth you label memory and make your own accessors by just incrementing memory addresses on the stack
2026-01-30 16:50:27 <vms14       > i wanted to have that freedom too, even if weirder
2026-01-30 16:55:26 <veltas      > The two stacks make Forth code very small, and the simplicity makes Forth implementations small and maintainable, I'd say that's 90% of the benefit
2026-01-30 16:55:29 <cleobuline  > forthBot:  123456789123457 ?PRIME .
2026-01-30 16:55:29 <forthBot    > Error: Unknown word: ?PRIME
2026-01-30 16:55:45 <vms14       > cleobuline: that's a bunny not a cat xd
2026-01-30 16:55:52 <cleobuline  > forthBot:  123456789123457 PRIME? .
2026-01-30 16:55:53 <forthBot    > 1
2026-01-30 16:56:01 <veltas      > It being small means it can be used in embedded, usually you don't get the 'whole' thing in embedded, e.g. C compiler won't run on an MCU
2026-01-30 16:56:08 <cleobuline  > oui ca melange les lignes
2026-01-30 16:56:35 <vms14       > i like my rpn lang because the core fits in my mind and the rest is just words
2026-01-30 16:56:52 <vms14       > new syntax is just an immediate word
2026-01-30 16:57:01 <veltas      > Being small means it's easy to extend
2026-01-30 16:57:18 <veltas      > And yes you can learn it easier because it's small
2026-01-30 16:57:26 <veltas      > Small has lots of advantages
2026-01-30 16:59:37 <vms14       > there is also the "everything is a pain and you have to simplify and strip out everything" philosophy, where you avoid complexity as much as possible and start questioning what is really needed
2026-01-30 16:59:53 <vms14       > i don't think my lang embodies properly that
2026-01-30 17:00:58 <vms14       > forth encourages you to do big things with very small ones
2026-01-30 17:01:21 <vms14       > create and does being one example
2026-01-30 17:08:30 <vms14       > forthBot: : BUNNY CAT ; BUNNY
2026-01-30 17:08:30 <forthBot    > Unknown word in definition: CAT
2026-01-30 17:08:30 <forthBot    > Error: Definition discarded due to error
2026-01-30 17:08:35 <vms14       > :/
2026-01-30 17:08:51 <vms14       > oh you have to load the file, meh
2026-01-30 17:12:41 <iv4nshm4k0v > veltas: That's curious, because I see it exactly the other way around.  Yes, I'm somewhat attached to GNU C (and not just GCC: my early experience was with Borland C, but I've then 're-learned' C using GNU Libc Reference Manual as my textbook), and I've spent considerable time reading ISO C11, but I keep all those thing separate in my mind.
2026-01-30 17:12:41 <iv4nshm4k0v > Same with, say, Arduino: I don't mind using AVR-based boards (well, mostly the cheap clones) on occasion, or the Optiboot loader, but I know next to nothing about Arduino C++.  Basically, the only thing I know is that it uses AVR Libc, so I can use Arduino IDE to build and upload AVR Libc-based code.
2026-01-30 17:17:51 <iv4nshm4k0v > Anyway, my recent interest in Forth is specifically that Forth implementations are known to have been used as self-hosting operating systems for small computing systems.  (And small computing systems are IMO better suited for explaining how computing systems work than large ones.)  Knuth used MIX to explain algorithms; I'm going to try to use Forth to explain computers.
2026-01-30 17:57:34 <vms14       > i keep coming to that link with forth books so i'll share it
2026-01-30 17:57:38 <vms14       > https://www.jupiter-ace.co.uk/index_forth_books.html
2026-01-30 18:47:59 <veltas      > iv4nshm4k0v: I think Forth is good for that.  Have you read Starting FORTH?
2026-01-30 18:48:40 <veltas      > The PDF 1st ed is better than the web version, but out of date re standards
2026-01-30 18:50:51 <iv4nshm4k0v > I've read Pygmy Forth and cmForth source code, as well as Brad Rodriguez "Moving Forth" articles.  Can't say I quite figured out everything I know, but plenty to get started writing a Forth.
2026-01-30 18:53:22 <iv4nshm4k0v > "everything I need", that is.  "Thinking Forth", as well, for a glimpse into "Forth culture."
2026-01-30 18:55:52 <forthBot    > Environment for cleobuline inactive, freeing...
2026-01-30 18:56:14 <DKordic     > iv4nshm4k0v: I agree with You so far.  https://github.com/uho/preforth is relevant.
2026-01-30 19:08:30 <forthBot    > Environment for vms14 inactive, freeing...
2026-01-30 22:52:43 <veltas      > iv4nshm4k0v: I mention Starting FORTH because it's quite a good beginner text but also might be good inspiration for what you're trying to do