2022-12-11 11:31:34 <Zarutian_iPad> 
ACTION reads https://dugas.ch/artificial_curiosity/GPT_architecture.html

2022-12-11 12:00:32 <KipIngram   > Interesting back and forth between Liz Rather and another guy about APL vs. Forth.  I rather think the other guy was right about a couple of points.
2022-12-11 12:02:19 <KipIngram   > He cited operating on arrays in one whack offset most of APL's performance shortcoming compared to Forth; Rather replied that in most of her experience on did deal with "cells at a time" rather than arrays.  He came back with "if Chuck had been influenced by APL and had made Forth an array language, she'd probably be saying that most of her experience revolved around array work."  He even cited the "if all
2022-12-11 12:02:20 <KipIngram   > you have is a hammer, everything looks like a nail."
2022-12-11 12:02:50 <KipIngram   > He was polite enough not to point out that that if one operates a cell at a time in APL (it was unclear whether she was referring to APL with her remark), one is probably not using it right.
2022-12-11 12:06:13 <KipIngram   > Someone else referred to APL's looping mechnism as "training wheels" for people coming over from other language mindsets.
2022-12-11 12:06:47 <KipIngram   > The way APL deals with arbitrary dimension data is really quite impressive to me.
2022-12-11 12:07:07 <KipIngram   > The very strong connection with mathematical rigor is too.
2022-12-11 12:08:06 <KipIngram   > I like the symbolic names, though I didn't work with it enough last year when I was looking at it to get really comfortable with them.  Still had to look things up constantly.
2022-12-11 12:08:29 <KipIngram   > But I could at least *imagine* what it would feel like after getting totally familiar with them.
2022-12-11 12:08:44 <KipIngram   > I feel like that would be a sense of great power.
2022-12-11 12:14:00 <KipIngram   > The way I like to think about it is that when you get to the end of that road, you'd be as comfortable and intuitive with all of those symbols as we all are now with the standard arithmetic symbols.
2022-12-11 12:15:50 <KipIngram   > Most of us can look at a line of arithmetic and have some immediate "feel" about what the whole sentence "is"; we don't have to "think it through" from scratch, bit by bit.  I think that would start to be the case with all of the APL symbols once you got it all down well enough.
2022-12-11 12:16:43 <Zarutian_iPad> no, I always have to look up the “precedence” rules with most equations
2022-12-11 12:16:52 <eris[m]     > you still need to work through the effects
2022-12-11 12:17:04 <eris[m]     > no precedence applies in APL other than operators first
2022-12-11 12:17:07 <KipIngram   > On regular arithmetic? (Zarutian_iPad)
2022-12-11 12:17:20 <thrig       > P.S. ancient old C ignored the ()
2022-12-11 12:17:23 <Zarutian_iPad> yeah
2022-12-11 12:17:30 <KipIngram   > eris: well, I know we still DO do that, but it somehow becomes "subconscious" to an extent with the standard arithmetic symbols.
2022-12-11 12:17:36 <KipIngram   > At least for me that's how it feels.
2022-12-11 12:17:41 <eris[m]     > i meant with apl
2022-12-11 12:17:47 <eris[m]     > it dorsnt become subconscious
2022-12-11 12:18:04 <KipIngram   > Oh, you're saying that one likely just never gets to the same level with APL?
2022-12-11 12:18:21 <eris[m]     > not even the most talented APLers i know can instantly read an APL statement for its purpose
2022-12-11 12:18:23 <KipIngram   > That's not implausible; it's "a lot."
2022-12-11 12:18:34 <eris[m]     > they need a bit of time to figure out the shape
2022-12-11 12:18:47 <KipIngram   > Fair enough - I've not been around the block well enough to know.
2022-12-11 12:19:03 <KipIngram   > But it seems like a path one would at least partially move down.
2022-12-11 12:19:20 <eris[m]     > apl is particularly difficult to acquire an intuition for (it is possible, just harder)
2022-12-11 12:19:33 <KipIngram   > I believe that.
2022-12-11 12:19:39 <KipIngram   > there are just so many pieces.
2022-12-11 12:19:54 <eris[m]     > its more about compositionality for me
2022-12-11 12:20:09 <eris[m]     > APL has 'operators' and 'trains'
2022-12-11 12:20:23 <eris[m]     > which make order of application more difficult to sus out
2022-12-11 12:20:38 <KipIngram   > And it did seem to me that the way 'what a piece of code does' depends on what's around it would contribute to making it harder.
2022-12-11 12:21:08 <KipIngram   > Some of those symbols completely change depending on their surroundings.  I didn't exactly love that aspect.
2022-12-11 12:21:48 <KipIngram   > I found some of them to change in a very intuitive way; for some of them it felt kind of arbitrary.
2022-12-11 12:22:00 <KipIngram   > But that might just be me not seeing deeply enough at that time.
2022-12-11 12:22:01 <thrig       > might morphing polymorphic rangers
2022-12-11 16:44:02 <KipIngram   > https://madhadron.com/programming/seven_ur_languages.html
2022-12-11 16:53:10 <KipIngram   > Nice "taxonomy" of programming languages.
2022-12-11 16:55:43 <thrig       > Java C# C++ Python Ruby are mostly algollikes
2022-12-11 16:59:58 <KipIngram   > Yes, as are Fortran, Cobol, and a whole slew of others.
2022-12-11 17:01:02 <KipIngram   > So now I want to know some language from all seven categories.  :-)
2022-12-11 17:01:35 <KipIngram   > Already know Forth, already know a number of algol derivatives.
2022-12-11 17:01:51 <KipIngram   > Know a LITTLE Lisp, a LITTLE APL.  Long way to go on both of those, though.
2022-12-11 17:02:13 <thrig       > I dunno, haskell type errors drove me up the wall, then I uninstalled it
2022-12-11 17:02:20 <KipIngram   > ML / functional is probably my biggest weakness.
2022-12-11 17:02:41 <KipIngram   > I've looked into it, but I just feel like my headspace is a long way from any kind of "intuitive grip" on functional thinking.
2022-12-11 17:03:27 <KipIngram   > Oo and Prolog I've also tinkered with a little, but am far from any sort of real "expertise."
2022-12-11 17:13:50 <KipIngram   > Ok, still thinking about this business of piipelining in Forth.  Forth is already almost there, if you regard the stack as the "go-between" between successive steps.  However, if that's the end of the story, then each component has to FINISH before the next one can begin; you can't really get a "flow" going.
2022-12-11 17:14:43 <MrMobius    > not exactly RISC :)
2022-12-11 17:14:45 <KipIngram   > So I wonder if it could be extended by having a second push operation.  When a word runs, it has a stack that works just like always; you can take stuff off, put stuff on.  But in addition, there would be a "queue," which would go on the output side.
2022-12-11 17:15:10 <KipIngram   > So you could optionally push a value to the queue, and the other end of that queue would be the stack for the next command.
2022-12-11 17:15:34 <KipIngram   > Now you could set all the words running at once, and each one would just block if it needed a stack item but its stack was empty.
2022-12-11 17:15:59 <KipIngram   > Data could just flow gracefully through that chain, getting processed as far as possible as soon as the data became available to each of the words.
2022-12-11 17:16:46 <KipIngram   > So there would just be one new word, which is a "push to queue" word.
2022-12-11 17:17:24 <KipIngram   > And if you were just running the word sans piping, then that push to queue word might be how you wrote output characters to the console.
2022-12-11 17:17:30 <KipIngram   > So it would fill the role of EMIT.
2022-12-11 17:17:44 <KipIngram   > Maybe.
2022-12-11 17:17:50 <KipIngram   > Not really sure about that yet.
2022-12-11 17:18:13 <KipIngram   > But if a normal standard Forth process has an output queue, that would seem to be it.
2022-12-11 17:19:57 <KipIngram   > So the *console* process would interpret data pulled from its stack as ASCII characters.
2022-12-11 17:20:11 <KipIngram   > But a different process receiving that data could interpret it in some different way.
2022-12-11 17:22:01 <KipIngram   > Its fairly straightforward to imagine supporting multiple output queues, which would let a process send data to  multiple other processes.
2022-12-11 17:22:25 <KipIngram   > Not as easy to see how to have multiple input queues, though, unless maybe only one of them was "the stack."
2022-12-11 17:23:00 <KipIngram   > I've tried to think about multi-stack Forths over the years (like a number of people have) but never saw it going anywhere graceful.
2022-12-11 17:23:27 <KipIngram   > But with multi-in, multi-out, you could have arbitrary graph networks of processes.
2022-12-11 17:25:06 <KipIngram   > While you could push back onto your input queue, you would not be able to pop from an output queue; once you pushed data in, it would be gone as far as you are concerned.
2022-12-11 20:47:30 <thrig       > hmmmm https://github.com/stacksmith/harn