2023-06-06 02:53:14 <veltas      > : , ( x)   HERE  1 CELLS ALLOT  ! ;
2023-06-06 07:31:34 <KipIngram   > Yes?
2023-06-06 07:33:19 <KipIngram   > I have a family of such words.  Byte, word, half-cell, and cell words for the body regionand for the header region.
2023-06-06 07:35:51 <veltas      > I just like posting random simple definitions in here sometimes
2023-06-06 07:35:56 <KipIngram   > I use the half-cell words a lot more often than I do the cell word.
2023-06-06 07:36:01 <KipIngram   > That is a nice one.
2023-06-06 07:36:23 <veltas      > It's a little gross honestly, I don't like how ANS is missing CELL
2023-06-06 07:36:51 <KipIngram   > Oh, it is?  That seem slike kind of an obvious one to have.  Do they "explain" that somehow?
2023-06-06 07:37:22 <KipIngram   > They just figure 1 CELLS is "good enough"?
2023-06-06 07:37:24 <veltas      > I'm sure there's some random Forth where CELL did something else like creates a splinter cell in your house or something
2023-06-06 07:37:39 <KipIngram   > It's a bit offensive just because it's poor English.  :-)
2023-06-06 07:40:11 <veltas      > When is someone going to write a cloud-based Forth
2023-06-06 07:40:40 <KipIngram   > Don't know - in my own mind it's hard for me to "detach" Forth from embedded style work.
2023-06-06 07:41:08 <KipIngram   > Just offhand I'd think that a cloud Forth probably ought to have some "interesting extensions."
2023-06-06 07:41:34 <KipIngram   > Since there are things that people kind of take for granted that Forth doesn't normally offer "out of the box."
2023-06-06 07:41:46 <KipIngram   > I'd think it would need some of those to appeal to such an audience.
2023-06-06 07:42:24 <veltas      > The big job I'd like to see it tackle is writing some kind of scalable Forth, having the same basic constructs that current solutions offer
2023-06-06 07:43:15 <KipIngram   > I was thinking a little the last couple of days about how I might tackle trying to add "object like" behavior to Forth.
2023-06-06 07:43:26 <KipIngram   > Kind of idle thinking - it's not necessarily something I'm all hot for.
2023-06-06 07:43:33 <veltas      > Yeah me neither
2023-06-06 07:43:56 <veltas      > I've discovered that the PACKAGE word allows me to write neater struct member access words through
2023-06-06 07:43:58 <KipIngram   > I figured classes would provide a jump table for methods, and there would be an additional machine code "handler" you might call doobj.
2023-06-06 07:44:11 <KipIngram   > Method would be a table index passed in on the stack:
2023-06-06 07:44:18 <KipIngram   > <method> <object>.
2023-06-06 07:44:19 <veltas      > Often I don't want public access words anyway, so I just get to write short words like .THIS .THAT and they only appear in a private wordlist
2023-06-06 07:44:35 <KipIngram   > doobj would just route execution to the definition called out by that table item.
2023-06-06 07:45:14 <KipIngram   > I didn't see any good way to chain classes together - looked like the simple approach would be to get inheritance by inheriting parent-defined jump tables, and extending them in the new class.
2023-06-06 07:45:21 <veltas      > Yeah that kind of instancing is like an extension of DOES>
2023-06-06 07:45:30 <KipIngram   > Yeah.
2023-06-06 07:45:35 <veltas      > Which is sort of like a one-method class system
2023-06-06 07:45:41 <KipIngram   > DOES> <any of these things>
2023-06-06 07:46:09 <KipIngram   > I didn't think much about what the actually code of defining classes would look like.
2023-06-06 07:46:28 <KipIngram   > Anyway, more of an intellectual curiosity than anything else.
2023-06-06 07:47:04 <veltas      > IMO a big deal with OOP is just finding ways to shorten amount of crap to write when using structs/classes
2023-06-06 07:47:21 <KipIngram   > Yeah, it often feels "verbose" to me.
2023-06-06 07:47:27 <veltas      > i.e. I don't want to write "MY-STRUCT.MEMBER" every time I want MEMBER
2023-06-06 07:47:39 <KipIngram   > I think the general idea is fine; it's certainly a worthwhile mental model.
2023-06-06 07:47:44 <veltas      > And I don't want to 'pass' the object itself to member functions explicitly every time I call a member
2023-06-06 07:48:15 <KipIngram   > Hmmm.  But somehow it has to know what actual object is in play.
2023-06-06 07:48:50 <veltas      > And that's what a type system is for
2023-06-06 07:48:55 <KipIngram   > It almost feels like vocabulary type stuff should be tied in somehow.
2023-06-06 07:49:05 <KipIngram   > But that's a whole separate part of the system.
2023-06-06 07:50:11 <KipIngram   > The syntax I wrote above has me kind of "executing" the object.  But surely you'd want to be able to justput an object on the stack too.
2023-06-06 07:50:35 <KipIngram   > <obj> with no method, but Forth doesn't have a super elegant way of doing both of those things.
2023-06-06 07:50:53 <veltas      > I have two broad ideas for shortening access words, one is to write i.e. "USING <mystruct>", which allows me to lookup members of that struct without the text preceding the '.'
2023-06-06 07:51:02 <KipIngram   > Yes.
2023-06-06 07:51:03 <veltas      > Until END-USING or ; or something
2023-06-06 07:51:48 <KipIngram   > That's where I thought vocabularies seem to come in.
2023-06-06 07:52:01 <KipIngram   > USING <object> "targets" words that follow.
2023-06-06 07:52:39 <KipIngram   > And it seems like you might want a stack of those things - methods would dig down until they found an object they recognized.
2023-06-06 07:52:50 <veltas      > Yeah
2023-06-06 07:52:56 <veltas      > In case you have a couple different structs
2023-06-06 07:53:11 <veltas      > In most code I'd expect just one or two at a time
2023-06-06 07:53:16 <KipIngram   > Right.
2023-06-06 07:55:46 <KipIngram   > It really is similar to the thoughts I'd had for including types.  I've settled in on thinking that the stack would contain pointers to objects exclusively, and the compiler would keep up with what that was going to look like at any given time.
2023-06-06 07:55:55 <KipIngram   > And would use that to guide word searches.
2023-06-06 07:56:12 <KipIngram   > FIND would only be happy with a word that expected the current stack layout.
2023-06-06 07:56:36 <veltas      > I'll do pretty much anything to avoid types
2023-06-06 07:56:51 <KipIngram   > It's a fairly clean idea, but then I usually get greedy and want to have a way to still be able to put raw integers or addresses onto the stack.
2023-06-06 07:56:59 <KipIngram   > Probably better to keep it pure.
2023-06-06 07:58:09 <KipIngram   > I guess having that all be compile time only would limit capabilities in certain ways.
2023-06-06 07:59:03 <veltas      > I came up with the USING idea while working on my "new B" design, because likewise I wanted to avoid types ... really the whole point of
2023-06-06 07:59:08 <veltas      > a new B is that it's C without types
2023-06-06 07:59:41 <KipIngram   > I know kind of historically what B is, but don't really have much familiarity with it.
2023-06-06 07:59:45 <veltas      > B really is such an elegant language, it's a shame that C had to add so much clutter, and that's what you get with types... clutter
2023-06-06 07:59:58 <veltas      > It's just C without types
2023-06-06 08:01:23 <KipIngram   > So when you call a function, you just shove in whatever items you want to?
2023-06-06 08:01:28 <veltas      > Yeah
2023-06-06 08:01:29 <KipIngram   > And it's up to you to make sure it works?
2023-06-06 08:01:35 <KipIngram   > That's actually kind of appealing.
2023-06-06 08:01:39 <veltas      > That's how C actually works too, without prototypes
2023-06-06 08:01:41 <veltas      > In C90
2023-06-06 08:01:51 <veltas      > Like the hello world program in B is just:   main() putf("Hello, world!*n");
2023-06-06 08:02:01 <veltas      > No includes, no prototypes
2023-06-06 08:02:15 <KipIngram   > I like simple and to the point.
2023-06-06 08:02:16 <veltas      > And no 'block' is needed for a function, a function body can just be one statement
2023-06-06 08:02:38 <KipIngram   > That's getting closer to Forth.
2023-06-06 08:03:00 <veltas      > It's really depressing seeing how elegant B is compared to C. Of course in the 90's things got so out of hand that C looks elegant
2023-06-06 08:03:09 <KipIngram   > I like thinking of my Forth as just a big slab of code, with "entry points" I've specified.
2023-06-06 08:03:48 <veltas      > Well C became popular in the 80's and because it was still far neater than Pascal, but with an actual type system and primitive compile-time safety
2023-06-06 08:04:06 <KipIngram   > Pulling the headers off into another region kind of amplified that perspective for me.
2023-06-06 08:04:56 <KipIngram   > I didn't quite get that separation all the way done in my current system - definitions still point back at headers.
2023-06-06 08:05:06 <KipIngram   > I intend to take it the rest of the way on the next one.
2023-06-06 08:05:20 <KipIngram   > "Here's all the stuff you need to run - and here's all the stuff you use to 'get at it'."
2023-06-06 08:07:37 <veltas      > One cool 'feature' of B is that its arrays (called vectors) *really are* just an address.
2023-06-06 08:07:40 <veltas      > If you write `auto v[10];` then you've allocated 11 cells, one for the variable v, and 10 for the vector. v now contains address of the remaining 10 cells
2023-06-06 08:08:16 <veltas      > You can send that address to that allocation of 10 cells somewhere else and then reuse the variable 'v' for something else if you want
2023-06-06 08:11:25 <KipIngram   > Hmmm.  Yeah, I often think about chunks of memory that have their own size in the first cell.
2023-06-06 08:11:44 <veltas      > That is something I designed into New B
2023-06-06 08:12:08 <veltas      > In New B when you declare a vector it puts the size into the next cell, and then the content after that
2023-06-06 08:12:51 <veltas      > So you can do v[-1] to get the size of the vector, and resize it if that's helpful for some reason
2023-06-06 08:13:23 <veltas      > Although I think there will be a function `size(v)` to get the size, just a little cleaner visually
2023-06-06 08:14:14 <veltas      > I also have been thinking about how to reduce syntax, one idea is to make all local scope variables 1-3 letters long, and anything longer is assumed to be external scope
2023-06-06 08:14:45 <veltas      > And then anything starting with underscore is module-local
2023-06-06 08:14:50 <veltas      > Just an idea, anyway
2023-06-06 08:15:24 <veltas      > But it avoids ever writing a declaration of local scalars, and there would be no need for 'extern', 'static', 'auto' keywords
2023-06-06 08:18:19 <KipIngram   > So, maybe one way to think about this (Forth stuff) is that when we execute an object, it has a run-time behavior, and that's all you get when it executes in a running definition.  But maybe at compile time it also makes some modification to the search path.
2023-06-06 08:18:43 <KipIngram   > Kind of like adding a vocabulary effect to a word in addition to its primary function.
2023-06-06 08:19:03 <KipIngram   > Maybe temporary, or maybe you'd have to explicitly "clear" it.
2023-06-06 08:21:02 <veltas      > What about if someone has a word that takes such an object as a parameter and then modifies it?
2023-06-06 08:21:48 <veltas      > That word has no idea where to look without something like USING, so maybe USING can be there as well in those situations
2023-06-06 08:22:41 <veltas      > And now we're at my New B design, because I had designed it so if you use "struct x" in a def then it becomes scoped, but you can also do "using x" to achieve the same thing if it doesn't come up naturally
2023-06-06 08:23:34 <KipIngram   > Could be.  I see what you're getting at - there is a difficulty there.
2023-06-06 08:23:46 <KipIngram   > : foo ...modify object... ;
2023-06-06 08:23:50 <veltas      > Exactly
2023-06-06 08:23:53 <KipIngram   > : bar   object foo ;
2023-06-06 08:24:12 <KipIngram   > The compiler had no idea when foo was compiled what the code in bar was going to look like.
2023-06-06 08:24:31 <KipIngram   > that is a big sharp thorn right there.  :-(
2023-06-06 08:24:50 <veltas      > So I suggest:   using object : foo ...modify object... ; previous
2023-06-06 08:25:48 <veltas      > And then you can just do    : bar object foo ;   and   : foobar object ...modify object... ;   without 'using' because it's implied
2023-06-06 08:28:56 <veltas      > I think that's a reasonable compromise
2023-06-06 09:23:10 <KipIngram   > Yeah, it was there when foo was compiled, so foo knows what to do.
2023-06-06 09:23:47 <KipIngram   > I'd always assumed that in a system like this I'd have to tell words what the stack was going to look like.  I'd considered doing that via "enabled" stack comments.
2023-06-06 09:24:20 <KipIngram   > : *  ( vector vector -- vector) ... ;
2023-06-06 09:24:32 <KipIngram   > Or matrix, or whatever.
2023-06-06 09:25:01 <KipIngram   > That's  not quite "object oriented," but it seems like it's getting into a similar neighborhood.
2023-06-06 09:25:46 <KipIngram   > Definition has to be told what KIND of thing will be on the stack, even though it won't know WHICH thing until runtime.
2023-06-06 09:30:07 <veltas      > It's not "object oriented", it's just a type system. But I do think a lot of the power of OOP is just grouped naming features and encapsulation
2023-06-06 09:32:20 <thrig       > wasn't OO about messages according to some Alan Kay?
2023-06-06 09:36:22 <KipIngram   > I see why that comment makes sense, but I think veltas is on the right track.  In terms of how you use it it is kind of about managing your names.
2023-06-06 09:38:16 <veltas      > thrig: I accept Bjarne Stroustrup's interpretation of what OOP means in most languages, of which I'd say encapsulation is like a third of it
2023-06-06 09:38:44 <veltas      > People obviously don't use OOP that well in practice, for most people it's just a way of grouping and hiding stuff, almost all of which exists in C anyway
2023-06-06 09:40:45 <KipIngram   > That would be me.
2023-06-06 09:41:31 <veltas      > If I remember rightly Bjarne boils it down to encapsulation, inheritance and polymorphism
2023-06-06 09:44:23 <KipIngram   > encapsulation and inheritance have always made sense to me - I've never really "gotten" polymorphism.
2023-06-06 09:54:51 <thrig       > poly probably makes sense in GUI design where you have something and you're like "hey something render yourself"
2023-06-06 09:55:08 <veltas      > It makes sense everywhere, drivers are like polymorphism
2023-06-06 09:55:29 <veltas      > You're like "I have a disk, I don't know how to use it but I know I can read and write from it and ask how big it is"
2023-06-06 09:58:23 <veltas      > Bjarne describes the thing I'm interested in as "data abstraction", which he doesn't consider OOP
2023-06-06 09:58:26 <KipIngram   > So how is that not "encapsulation"?
2023-06-06 09:58:33 <KipIngram   > What exactly IS "polymorphism"?
2023-06-06 09:58:46 <KipIngram   > Bundling functionality inside containers with data - that makes sense to me.
2023-06-06 09:59:09 <KipIngram   > You don't need to know what's in there - you only need to know what you can do with it.
2023-06-06 09:59:49 <KipIngram   > In a sense that's no different from hardware design.  I turn this knob - my music gets louder.
2023-06-06 09:59:56 <KipIngram   > How does that happen?  Well, someone knows...
2023-06-06 10:00:01 <veltas      > https://en.wikipedia.org/wiki/Polymorphism_(computer_science)
2023-06-06 10:00:51 <KipIngram   > Ok, so akin to overloading?
2023-06-06 10:01:29 <KipIngram   > Being able to use symbols in different contexts, and have them mean the appropriate thing in each case?
2023-06-06 10:01:33 <thrig       > overloading is when you put 300 people on a 30 person ferry
2023-06-06 10:04:27 <veltas      > KipIngram: It's not a fundamental set of features, it's more just a programming paradigm
2023-06-06 10:04:45 <veltas      > It's not like you can't achieve the features of polymorphism in non-OOP languages
2023-06-06 10:04:58 <veltas      > It's just that OOP languages provide them in a certain way
2023-06-06 10:07:23 <veltas      > You might read what Bjarne actually said about it, I'm misremembering anyway https://www.stroustrup.com/whatis.pdf
2023-06-06 10:07:33 <KipIngram   > Yeah, I'm seeing that I am familiar with most of these IDEAS - just not under the correct "lingo."
2023-06-06 10:08:09 <veltas      > Nowhere does he say 'polymorphism', I suppose that's allowed by calling and dispatch mechanisms along with a static or dynamic type system and inheritance
2023-06-06 10:08:21 <veltas      > Well nobody agrees on the lingo
2023-06-06 10:08:27 <KipIngram   > In the system I've envisioned, a function that works on some object without really needing to know what the object exactly is (stack manipulations are an example) has one of those forms of polymorphism.
2023-06-06 10:08:35 <veltas      > I don't think Bjarne's terminology is necessarily normal among even C++ programmers
2023-06-06 10:08:37 <KipIngram   > Who cares what those objects are?  You can still swap them.
2023-06-06 10:08:48 <veltas      > And certainly the simula terminology isn't typical
2023-06-06 10:08:53 <KipIngram   > Or there might be a function to return the size of an object that was "universal."
2023-06-06 10:09:03 <veltas      > Yeah I'd say that was 'single dispatch'
2023-06-06 10:09:14 <veltas      > You can look that up
2023-06-06 10:10:25 <KipIngram   > I run into this sort of thing reading math papers.  I'll be all baffled, and when I finally get it all "decoded" it turns out to be concepts I already knew.
2023-06-06 10:11:33 <KipIngram   > Just with swanky mathematician names.
2023-06-06 10:11:57 <KipIngram   > Always made me wonder why the old language wasn't perfectly good enough.
2023-06-06 10:12:45 <KipIngram   > I feel like, though, that's what people do when they "priestify" a domain - they wrap it all up in a new language.
2023-06-06 10:13:19 <KipIngram   > I don't really feel a whole lot of "agile development" was NEW - I'd done some of that stuff just on instinct long before I ever heard of agile.
2023-06-06 10:13:30 <KipIngram   > But it all got new names.
2023-06-06 10:38:45 <veltas      > Yeah very true
2023-06-06 10:39:13 <veltas      > I think the reason it gets branding and names is because people who happen across it don't fully understand why it works, and aren't aware it's not new
2023-06-06 10:39:26 <KipIngram   > :-)  So I tend to roll my eyes a little over the way it's been turned into a veritable religion.
2023-06-06 10:39:55 <veltas      > There's only one religion I have time for :P
2023-06-06 10:44:09 <KipIngram   > :-)
2023-06-06 10:51:16 <veltas      > I don't really consider it to be a cult, I think it's just a meme or fad
2023-06-06 10:51:43 <veltas      > Nobody really takes agile that seriously anyway, at least I wouldn't imagine so because nobody actually seems to practice it
2023-06-06 10:52:19 <veltas      > I think people actually tried to do XP and scrum years ago but nowadays you're lucky if you can get people to apply anything even slightly iterative
2023-06-06 10:52:25 <KipIngram   > We've just had a couple of "rah rah" guys that carry their colored sticky notes around with them over the years.
2023-06-06 10:52:27 <veltas      > or test driven
2023-06-06 10:52:42 <veltas      > Nothing wrong with sticky notes :P
2023-06-06 10:53:57 <KipIngram   > No, not at all.  It's just that these guys weren't particularly technical guys, and mostly billed themselves as "agile experts."
2023-06-06 10:54:18 <KipIngram   > And I've just always felt that technical work should be led by technical people.
2023-06-06 16:34:03 <Zarutian_iPad> okay, someone answer me this: why do LargeLanguageModels have such wierd names?
2023-06-06 16:34:18 <drakonis    > because programmers
2023-06-06 16:34:26 <drakonis    > and people that want memorable names
2023-06-06 16:34:40 <Zarutian_iPad> https://www.together.xyz/blog/redpajama-7b case in point
2023-06-06 16:35:00 <Zarutian_iPad> Llamas in red pajamas
2023-06-06 16:37:27 <Zarutian_iPad> https://pennylane.ai/qml/demos/tutorial_zx_calculus.html just begs for a Forth port no?
2023-06-06 16:51:57 <KipIngram   > That will take me a while to absorb, but it looks interesting.
2023-06-06 16:56:24 <KipIngram   > It's... quite abstract.
2023-06-06 21:35:40 <KipIngram   > Zarutian_iPad: ok, I suspect there's a lot of power in that zx calculus.  I just don't know my quantum computing well enough to really get my hands around it, though.
2023-06-06 21:36:18 <KipIngram   > I have a fair sense about the gist of quantum computing (and how very much it's NOT like regular computing), but I've never really "waded in."
2023-06-06 21:36:44 <KipIngram   > Question pop up on Quora all the time - "When will quantum computers make computers obsolete?" etc.
2023-06-06 21:37:15 <KipIngram   > My opinion is never.  There's plenty of stuff that regular computers do just as well as a quantum computer would, and they're a lot easier to build.
2023-06-06 21:37:26 <KipIngram   > We're GOOD at building them.  Supremely good.
2023-06-06 21:37:38 <KipIngram   > You don't need a quantum computer to check Facebook or watch a movie.
2023-06-06 21:38:14 <KipIngram   > I think that we'll figure out how to build them well enough to "have them around," and they'll fill a niche and solve particular problems for us - problems they do excel at.
2023-06-06 21:38:44 <KipIngram   > I particularly think they might revolutionize drug development and other "fancy chemical stuff."
2023-06-06 21:38:59 <KipIngram   > We may get a "golden age" of super materials.
2023-06-06 21:39:43 <KipIngram   > But I don't think standard computers are going anywhere, unless someone finds a COMPLETELY unexpected way to make quantum computers "even cheaper" than the ones we make now.
2023-06-06 21:59:42 <KipIngram   > Ah, so it's possible to kick a script out of a sleep in Linux.
2023-06-06 22:00:13 <KipIngram   > Apparently if your script calls sleep, you can kill the *sleep pid* and  your script will just carry on.
2023-06-06 22:00:17 <KipIngram   > That's useful.
2023-06-06 23:40:02 <thrig       > wait till you learn about editing the shell script on the fly