2023-09-08 01:23:58 <KipIngram   > No, that doesn't seem like something which should be mutable to me.
2023-09-08 01:24:26 <KipIngram   > However, any way of implementing it in Forth could *potentiallly* be changed - you could always reach nto the definition and change it (within certain bounds).
2023-09-08 01:24:49 <KipIngram   > As a matter of logic, though, that's a piece of CODE that you execute - not a "stored value."
2023-09-08 01:25:03 <KipIngram   > I can do this in Forth:
2023-09-08 01:25:09 <KipIngram   > : foo 42 ;
2023-09-08 01:25:16 <KipIngram   > That puts 42 on the stack.
2023-09-08 01:25:31 <KipIngram   > If I know the right way to poKE RAM, though, I could change the 42.
2023-09-08 01:27:07 <KipIngram   > : foo  ." hello, world!" ;
2023-09-08 01:27:31 <KipIngram   > In theory mutable, as long as you don't try to make the string longer.  But not really thought of that way.
2023-09-08 01:35:42 <thrig       > even the pad where formats are pictured isn't really available for fiddling with
2023-09-08 09:36:57 <KipIngram   > Well, it IS - PAD gives you the address.  You'd just have to "know how to fiddle."
2023-09-08 09:37:16 <KipIngram   > Forth makes it POSSIBLE to fiddle with pretty much everything.
2023-09-08 09:44:03 <KipIngram   > A "thing" in programming is the whole idea of hiding implementation details from higher levels, and perhaps outright PREVENTING access to those lower levels by the higher code.  Forth doesn't really do any such "preventing."  If you KNOW what the lower level is doing, you can tinker under its hood.  That doesn't necessarily mean it's a good thing to do, though - the minute you exploit some internal low-level
2023-09-08 09:44:05 <KipIngram   > behavior you're making it a "requirement" - if you then went and changed how the low level stuff worked you might break your higher level code.
2023-09-08 09:45:38 <KipIngram   > It's all a big tradeoff between efficiency and resiliency.
2023-09-08 10:26:02 <KipIngram   > Looks like RPL went in big time for giving names to frequently used sequences of primitives.  If you scroll through the list there's a whole bunch of them with names that look like several primitive names rammed together.
2023-09-08 10:26:34 <KipIngram   > Almost like at some point they said "ok, we've got X amount of memory left - how can we use it to carve out a little more performance?"
2023-09-08 10:47:55 <KipIngram   > I think I need to wade back into APL again for a bit.  I see it strongly influencing this new system as well; need to get those lines drawn a little more sharply.
2023-09-08 10:52:36 <KipIngram   > Geez - reading this:
2023-09-08 10:52:38 <KipIngram   > https://xpqz.github.io/learnapl/intro.html
2023-09-08 10:52:58 <KipIngram   > he might as well be talking about Forth.  So much of that you could just replace "APL" with "Forth" and it would still sound about right.
2023-09-08 11:00:07 <KipIngram   > There is an immediate friction between Forth and APL, though.  Forth does things left to right, but APL does things right to left.  Because that's the way operators in math work.  A B C x is A(B(C(x))).  That is DEEPLY baked into scientific "math think."
2023-09-08 11:00:13 <KipIngram   > Not exactly sure how to resolve that.
2023-09-08 11:00:45 <KipIngram   > In other words, given Iverson's goals when he cooked this all up, it makes total sense that it should be that way.
2023-09-08 11:01:01 <KipIngram   > And given Chuck's goals, what he did makes total sense too.
2023-09-08 11:01:06 <vms14       > i have a word that makes a copy of an element to provide a way to make inmutable data
2023-09-08 11:01:31 <KipIngram   > If you want data to be immutable, just don't mutate it.
2023-09-08 11:01:43 <KipIngram   > It'll keep its value as long as you leave it a lone.
2023-09-08 11:01:49 <vms14       > : oh ( 1 2 3 ) ;   oh shift
2023-09-08 11:02:15 <vms14       > shift is destructive, from now on oh will return ( 2 3 )
2023-09-08 11:02:38 <KipIngram   > Like pop in python.
2023-09-08 11:02:44 <vms14       > : oh ( 1 2 3 ) copy ;
2023-09-08 11:03:01 <vms14       > now it's not mutable
2023-09-08 11:03:35 <vms14       > i wonder if I should change the name or make an alias
2023-09-08 11:03:44 <vms14       > for some meaning of not mutable
2023-09-08 11:03:50 <KipIngram   > In Python you have copy.deepcopy
2023-09-08 11:04:21 <vms14       > in my case it only works for lists and hashes
2023-09-08 11:04:40 <vms14       > it creates a new hash from a reference and returns a new reference
2023-09-08 11:04:54 <vms14       > same with a list
2023-09-08 11:05:38 <vms14       > should it be called no.mutable? xd
2023-09-08 11:06:13 <vms14       > : oh ( 1 2 3 ) immutable ;
2023-09-08 11:06:21 <vms14       > meh
2023-09-08 11:06:26 <KipIngram   > I'm not tuned into your whole setup enough to have any advice.
2023-09-08 11:07:00 <vms14       > ill call it copy
2023-09-08 11:08:13 <KipIngram   > I think this depends a lot on what you're familiar with.   Functional programmers don't like for inputs to change.
2023-09-08 11:08:30 <KipIngram   > But coming from an embedded background, it seems natural to me that code DOES THINGS TO THINGS.
2023-09-08 11:08:35 <KipIngram   > Code makes changes.
2023-09-08 11:08:43 <vms14       > yeah but i dont know if all immutable by default is a good choice
2023-09-08 11:09:03 <KipIngram   > Changing something in place is often more efficient than copying it.
2023-09-08 11:09:04 <vms14       > i can just give the option of making it immutable with copy
2023-09-08 11:09:23 <KipIngram   > I like Python's resolution - by default it's efficient, but you can deliberately cause a copy if you want it.
2023-09-08 11:09:37 <vms14       > then why is it so slow
2023-09-08 11:10:00 <KipIngram   > Oh, you've just got "slow" baked in at your ground floor.
2023-09-08 11:10:35 <vms14       > i wonder if my lang is slower than python
2023-09-08 11:10:38 <vms14       > i bet it is
2023-09-08 11:10:55 <vms14       > it's part of the trademark
2023-09-08 11:11:02 <KipIngram   > Python has received a LOT of optimization effort.
2023-09-08 11:11:22 <vms14       > uglier than perl, slower than python and weirder than lisp
2023-09-08 11:11:35 <KipIngram   > Heh.
2023-09-08 11:11:40 <vms14       > that's the motto
2023-09-08 11:11:58 <KipIngram   > Well, here I am thinking about a mashup among Forth, HP RPL, APL, etc.
2023-09-08 11:12:16 <vms14       > you like apl
2023-09-08 11:12:22 <vms14       > you like concise stuff
2023-09-08 11:12:36 <KipIngram   > Yes, but alSO I like the mathematical "rigor" it rolls in.
2023-09-08 11:12:58 <KipIngram   > It was initially conceived not as a computer language, but rather as an advanced mathematical notation system.
2023-09-08 11:13:09 <KipIngram   > something to raise the power level of mathematical notation.
2023-09-08 11:13:20 <vms14       > like the lambda calculus
2023-09-08 11:13:22 <KipIngram   > only later did they say "Hey, this could run on a computer...'
2023-09-08 11:14:36 <KipIngram   > So I'm thinking in my context my equivlanet of "system rpl" will be just plain vanilla Forth, and my "user rpl" will be the type-aware extension.
2023-09-08 11:15:39 <vms14       > id like to steal concepts from prolog
2023-09-08 11:15:50 <KipIngram   > Prolog is interesting.
2023-09-08 11:15:52 <vms14       > i always had the feeling prolog can be very useful
2023-09-08 11:16:02 <vms14       > and like something i always wanted to have xd
2023-09-08 11:16:03 <KipIngram   > I haven't looked into whether there's anything "stealable" there, though.
2023-09-08 11:16:18 <KipIngram   > It can be, if the problem is "right."
2023-09-08 11:16:31 <KipIngram   > You know that puzzle about the five houses of the five colors lived in by the five nationarlities?
2023-09-08 11:16:32 <vms14       > KipIngram: that's why
2023-09-08 11:16:41 <vms14       > like having it as a part of the language
2023-09-08 11:16:45 <KipIngram   > You can almost just put that straight into prolog and then have it just tell you the answer.
2023-09-08 11:16:52 <vms14       > but i have to learn prolog
2023-09-08 11:17:34 <KipIngram   > It's not that hard.
2023-09-08 11:20:14 <KipIngram   > RPL has a type for a code string, but also has a type for an "algebraic expression."  That may be where the APL orientation comes in - maybe APL execution order lives inside my "algebraic expressions."
2023-09-08 11:20:35 <KipIngram   > That at least succeeds in nicely separating the left-to-right from the right-to-left.
2023-09-08 11:27:05 <KipIngram   > That feels like a right resolution.  "Programs" are step-by-step instructions.  Forth has that nailed.  "Algebraic expressions" are MATH, and I think APL has the better orientation toward that.
2023-09-08 11:30:45 <KipIngram   > vms14: Bear in mind I haven't thought about Prolog in this context AT ALL until the last few minutes, but it seems reasonable to me that we might get at that by having a "rule" type as one of the supported types.
2023-09-08 11:32:02 <vms14       > then you only need a macro, object and function types and your lang has alll the programming paradigms
2023-09-08 11:32:15 <vms14       > as a type
2023-09-08 11:32:44 <KipIngram   > Also,  "list" is a type in RPL also, so that opens the door to a lisp engine living in there somewhere too.
2023-09-08 11:33:06 <KipIngram   > I've thought for a while that Forth and Lisp might be able to coexist quite nicely.
2023-09-08 11:33:07 <vms14       > i suppose it goes against the yagni rule
2023-09-08 11:33:22 <vms14       > which is what chuck seems to encourage
2023-09-08 11:33:42 <KipIngram   > Yes, Chuck's whole mentality was oriented toward embedded design.
2023-09-08 11:33:49 <vms14       > KipIngram: they can do the same stuff in different ways
2023-09-08 11:33:50 <KipIngram   > Where you're building a system to do ONE THING.
2023-09-08 11:34:14 <KipIngram   > But sometimes the stuff we're talking about is pretty general purpose.
2023-09-08 11:34:27 <gordonjcp   > It's funny, stuff like APL and Prolog and things that were fundamentally a decent idea but still an evolutionary dead end kind of
2023-09-08 11:34:28 <KipIngram   > Like if you're making a calculator, you don't know what problems you're going to want to solve with it.
2023-09-08 11:34:30 <vms14       > the only thing i miss from lisp is the total control you have about every statement
2023-09-08 11:34:48 <vms14       > in forth any word can implement its own syntax, which is fun
2023-09-08 11:34:59 <vms14       > but impies chaos
2023-09-08 11:35:06 <vms14       > implies*
2023-09-08 11:35:11 <KipIngram   > gordonjcp: I think to some extent they were the victims of the "C is good enough" effect.
2023-09-08 11:35:25 <thrig       > in troff, macros can modify macros on the fly
2023-09-08 11:35:27 <KipIngram   > As in, the "good enough" is the greatest enemy of "the best."
2023-09-08 11:35:59 <KipIngram   > It implies chaos if you allow the chaos in.
2023-09-08 11:36:12 <vms14       > my language did not even arrive to "good enough"
2023-09-08 11:36:13 <KipIngram   > Forth doesn't PREVENt chaos, but it doesn't "endorse" it, either.
2023-09-08 11:36:22 <KipIngram   > Your language is a learning vehicle.
2023-09-08 11:36:31 <KipIngram   > And from what I can tell it has worked well for that.
2023-09-08 11:36:34 <vms14       > yeah
2023-09-08 11:36:58 <vms14       > i think its almost a year
2023-09-08 11:37:01 <vms14       > or more
2023-09-08 11:37:11 <vms14       > time is fast
2023-09-08 11:37:13 <KipIngram   > Yeah, I think you've been at it at least a year.
2023-09-08 11:37:22 <KipIngram   > You just wait - it keeps getting faster.
2023-09-08 11:37:29 <KipIngram   > you ain't seen nothing yet.
2023-09-08 11:37:34 <vms14       > :o
2023-09-08 11:39:11 <KipIngram   > Anyway, I'm pretty jazzed over this "agnostic vs. not agnostic" instructions notion.  I'm looking toward making my *instruction set itself* extensible to type support.
2023-09-08 11:39:51 <KipIngram   > And best I can tell the cost is just going to be a small number of extra table linkages.  Like 2-3, with each one being just one or two extra assembly language instructions.
2023-09-08 11:40:38 <vms14       > KipIngram: how would be the syntax for a method call in forth
2023-09-08 11:41:17 <KipIngram   > I'm not necessarily looking for total object orientation.
2023-09-08 11:41:52 <vms14       > i have to think about, but for now i'd like to think about just method calls
2023-09-08 11:42:02 <KipIngram   > Here's the thinking.  A bunch of my instructions (say, stack manipulation like SWAP or OVER) don't care a whit about what the things on the stack ARE.
2023-09-08 11:42:08 <KipIngram   > Those will be the same for all types.
2023-09-08 11:42:43 <KipIngram   > But some instructions, like + or AND  etc., do care.  I'm looking at making those instructions have the ability to trigger different code depending on what the  types of the things on the stack are.
2023-09-08 11:43:01 <KipIngram   > So in that sense it's not a "method" - it's just an instruction just like plain vanilla code.
2023-09-08 11:43:25 <vms14       > it is method dispatch
2023-09-08 11:43:33 <KipIngram   > So it would just be a + instruction, for example, in the code like in any other situation, but it might cause me to sum the two matrices referenced by the top stack items.
2023-09-08 11:43:47 <KipIngram   > Effectively it is, yes.
2023-09-08 11:44:15 <KipIngram   > So I'll be able to "reassign" those non-agnostic opcodes on a type-by-type basis, so I'll still get the compactness of the packed instructions and so on.
2023-09-08 11:44:39 <KipIngram   > Also, I'm planning some optimizations to make function calls take only the amount of room they need to take to "reach" the called code.
2023-09-08 11:44:42 <vms14       > but what if the different behaviors accept a different number of arguments?
2023-09-08 11:44:52 <vms14       > you can't know which one
2023-09-08 11:44:55 <KipIngram   > "Forth" means "lots of calls," so you want them to be efficient.
2023-09-08 11:45:20 <KipIngram   > That would be ok - a non-agnostic instruction won't have to take the same number of arguments for all types.
2023-09-08 11:46:18 <KipIngram   > All it means is that how a non-agnostic opcode gets interpreted will be influenced by what's on the stack.
2023-09-08 11:46:24 <vms14       > could you have two definitions of + with a signature that takes two elements and a signature that takes three?
2023-09-08 11:46:50 <KipIngram   > Well, if I allocated two instructions for that, then yes, but I probably won't.
2023-09-08 11:47:06 <KipIngram   > If I decided I WANTED matrix + to require three matrices, I could do that, but... probably won't.
2023-09-08 11:48:02 <KipIngram   > I could, however - if I wanted to - have integer integer + add integers, matrix matrix + add matrices, and integer matrix + add that integer to all elements of the matrix.
2023-09-08 11:48:03 <vms14       > i mean there's no way for you to perform multiple dispatch depending on the signature if the word has different number of arguments in it's different behaviors
2023-09-08 11:48:09 <KipIngram   > Literally just whatever combinations make sense.
2023-09-08 11:48:44 <KipIngram   > I see little value in a three-operand +, though - it's too easy to just say + + and do it with two two-op additions.
2023-09-08 11:49:18 <vms14       > yeah but i mean that your multiple dispatch only works if you always take the same number of elements
2023-09-08 11:49:40 <KipIngram   > Yes, I don't envision any equivalent of Lisp's (+ 1 2 3 4 5).
2023-09-08 11:49:59 <KipIngram   > However, APL has some capabilities like that, so inside my algebraic expression processing we might find that sort of thing.
2023-09-08 11:50:08 <vms14       > if you have code for + that takes 3 integers as argument, you can't know when it wants the 3 arg version or the 2
2023-09-08 11:50:09 <KipIngram   > But not in the "Forth part."
2023-09-08 11:50:27 <vms14       > unless you give the arguments on some sort of list
2023-09-08 11:50:30 <KipIngram   > Right.  Forth just doesn't give you a good way to do that.
2023-09-08 11:50:55 <KipIngram   > 1 2 3 4 5 + gives you no idea at all which items you "wanted" to be in the addition.
2023-09-08 11:51:08 <KipIngram   > But both Lisp and APL handle that kind of thing fine.
2023-09-08 11:51:35 <KipIngram   > I suspect that what I'd want + to do to a pair of lists, though, is concatenate them.
2023-09-08 11:52:05 <vms14       > i kind of dislike js taking strings with +
2023-09-08 11:52:20 <KipIngram   > Oh, i'm a big fan of Python string +.
2023-09-08 11:52:24 <KipIngram   > Makes total sense to me.
2023-09-08 11:52:30 <KipIngram   > And I use it all the time.
2023-09-08 11:53:13 <KipIngram   > See, a "program" is a set of instructions, but an "algebraic expression" is really more like data that you want to manipulate.  Though you certainly might "eval" it.
2023-09-08 11:53:23 <vms14       > i prefer + to coerce a string to a number and sum that take a string and concatenate it with a number
2023-09-08 11:53:46 <KipIngram   > Well, Python won't let you + a string and a number.
2023-09-08 11:53:52 <vms14       > js does
2023-09-08 11:53:53 <KipIngram   > Precisely because it's not clear what you want.
2023-09-08 11:54:01 <vms14       > thats why i dislike that
2023-09-08 11:54:01 <KipIngram   > You have to caste one or the other of htem to the other type.
2023-09-08 11:54:15 <vms14       > i prefer to have a separate name for concatenation
2023-09-08 11:54:18 <KipIngram   > "abc" + str(123)
2023-09-08 11:54:51 <KipIngram   > I'd like to separate the decisions about what these symbols "mean" from the idea of supporting type-specific meanings.
2023-09-08 11:55:27 <thrig       > https://thrig.me/tmp/string-addition.txt
2023-09-08 11:55:30 <KipIngram   > And by the way, it's the OPCODES that are actually going to have the type-specific interpretations; I don't have to give them the same mnemonics in all cases.
2023-09-08 11:56:26 <KipIngram   > so, the opcode I call + in the native system might be called "frapplerock" in the context of some specific type.
2023-09-08 11:56:34 <KipIngram   > The compiler will have to be able to deal with all that.
2023-09-08 11:57:38 <KipIngram   > The main point is that there is a subset of my instruction set that only "makes sense" in the context of integers on the stack.  Those are free to re-purpose when other things are on the stack.
2023-09-08 12:56:17 <KipIngram   > got an email this morning letting me know that my pre-order of "The Olympian Affair" is being processed.  That's book #2 of Jim Butcher's "Cinder Spires" series.  I can hardly wait - book #1 wsa damn good.
2023-09-08 13:05:57 <thrig       > way to Butcher prose?
2023-09-08 13:12:58 <KipIngram   > https://github.com/the-carlisle-group/Dado/wiki/How-Not-To-Code-In-Dyalog-APL
2023-09-08 13:13:19 <KipIngram   > Heh.  Honestly, Jim Butcher has almost ruined reading for me by making it too hard to find "acceptably good" stuff to read.
2023-09-08 13:14:39 <KipIngram   > I've gotten two of my daughters engaged with his series The Dresden Files, and on several occasions each they've complained to me in the middle of the day about being tired, because the night before they couldn't stop reading.
2023-09-08 13:15:26 <thrig       > probably easier reading than Bertrand Russell
2023-09-08 13:16:06 <KipIngram   > Well, that's for sure.
2023-09-08 13:16:16 <KipIngram   > I once tried Russell's History of Western Philosophy.
2023-09-08 13:16:19 <KipIngram   > Thick stuff.
2023-09-08 13:16:57 <KipIngram   > Butcher's just a story teller, but somehow he managed to make even his fantastical worlds seem "believable."
2023-09-08 13:17:16 <KipIngram   > Like, if it turned out that magic was real, then this world would feel super realistic.
2023-09-08 13:17:46 <KipIngram   > As opposed to some other writers like Simon Green, who just write stuff that's so over the top it's almost like it's a joke.
2023-09-08 13:18:24 <KipIngram   > Butcher's world of magic is reasonable and sensible - Green's seems heavily designed for  "shock effect.'
2023-09-08 13:18:52 <KipIngram   > I'm basing that opinion on Green's "Nightside" series.
2023-09-08 13:20:15 <KipIngram   > I don't know exactly how to phrase that appreciation for Butcher's work - it's something like "if I suspend disbelief, then I can just fully immerse myself in this world."  It can "feel real" to me and I wind up attached to the characters as though they're actually my friends.
2023-09-08 13:23:37 <MrMobius    > KipIngram: they were actually constrained on memory in the HP-48 which is why a lot of the OS is written in the slower sysRPL than assembly
2023-09-08 13:24:41 <MrMobius    > Four enthusiasts rewrote the other interface in assembly and added a bunch of goodies which ran on a 48GX with 128K ram card which is part of why the 48GX was so popular
2023-09-08 13:25:15 <MrMobius    > HP just licensed that for the HP-49G so no card slots but you have that software preinstalled
2023-09-08 13:26:16 <MrMobius    > The weird ROT+1DUPOVER stuff is all sysRPL because those are instructions that occur at known addresses in the ROM by chance
2023-09-08 13:26:28 <MrMobius    > occur before a return address I mean
2023-09-08 13:27:01 <MrMobius    > so you can use them as shortcuts but none of them were purposely included for the programmer's convenience
2023-09-08 13:38:33 <KipIngram   > Oh, interersting.
2023-09-08 13:39:16 <KipIngram   > I'm finding that focusing on a "calculator design" is proving to be a very good way of having a "well defined target that is in the ballpark of what I was already interested in."
2023-09-08 13:39:59 <KipIngram   > I don't know exactly what kind of threading they used in there, but it's hard for me to see how this plan I've got at the moment won't be at least "as compact" as whatever they did and possibly more so.
2023-09-08 13:40:22 <KipIngram   > Holy cow - I've got a dental appointment.  Back in a bit, guys.
2023-09-08 13:42:14 <Zarutian_iPad> one thing that Forth enables is to 'decompress' behaviour into the evolution of the process instead into memory
2023-09-08 15:07:25 <KipIngram   > I think I follow what you mean.
2023-09-08 15:14:57 <KipIngram   > What does the phrase "code golf" mean?
2023-09-08 15:18:45 <thrig       > in as few strokes as possible
2023-09-08 15:19:34 <thrig       > so, as terse as possible, generally to the point of unreadability
2023-09-08 15:19:52 <KipIngram   > Aha - this:
2023-09-08 15:19:54 <KipIngram   > In dfns, the left argument is ⍺, and the right argument is ⍵. Not alpha and omega, but ⍺ and ⍵. The 26 individual letters of the alphabet provide the next best 26 choices for local variable names. If you need more, your function is probably trying to do too much. Long names obscure the relationship between primitive functions, and make anything more than a trivial expressions hard to read.
2023-09-08 15:20:16 <KipIngram   > captures my attitude toward brevity perfectly.  "Long names obscure the relationship..."  <-- that
2023-09-08 15:20:34 <KipIngram   > You can't "see" the visual structure of the code as well with big multi-word names sprinkled in there.
2023-09-08 15:21:31 <KipIngram   > I think that is as true in a Forth definition as it is in an APL expression.
2023-09-08 15:22:48 <thrig       > probably there's a goldilocks zone between too terse and too long
2023-09-08 15:23:37 <KipIngram   > That's from here:
2023-09-08 15:23:39 <KipIngram   > https://github.com/the-carlisle-group/Dado/wiki/How-Not-To-Code-In-Dyalog-APL
2023-09-08 15:23:48 <KipIngram   > I find it by and large philosophoically pleasing.
2023-09-08 15:24:41 <KipIngram   > "If you need... an Uber car to get from one end to the other, your function is too damn long!"
2023-09-08 15:25:27 <thrig       > vs. http://number-none.com/blow/blog/programming/2014/09/26/carmack-on-inlined-code.html
2023-09-08 15:25:52 <KipIngram   > I already see one thing I like in APL better than in how RPL does it.  In RPL, when you're writing a function for the solver, you have to call out your variables: MVAR A, MVAR B, ...
2023-09-08 15:26:10 <KipIngram   > And then you have to RCL <mvar> to get one of those values onto the stack.
2023-09-08 15:26:27 <KipIngram   > APL's "default parameters," alpha and omega - that's better.
2023-09-08 15:27:05 <KipIngram   > i think that the function should attach names x y z t to the incoming stack items BY DEFAULT, and then your function should just be able to code accordingly.
2023-09-08 15:27:18 <KipIngram   > No declarations, and no having to RCL to get at the values.
2023-09-08 15:27:45 <KipIngram   > Because chances are the solver itself probably had those on the stack just a little earlier, and  had to STO them.  Wasteful.
2023-09-08 16:31:09 <MrMobius    > Isn't RCL and STO from the HP42?
2023-09-08 16:31:18 <MrMobius    > which is not RPL
2023-09-08 19:26:43 <KipIngram   > Yeah, I'm talking about the HP42 solver.
2023-09-08 19:26:59 <KipIngram   > Those are actually from a whole slew of HP calculators from over hte years.
2023-09-08 19:27:27 <KipIngram   > Well, I'm actually talking about the DM42 Solver.
2023-09-08 19:27:44 <KipIngram   > But it's built with Free42 which is based on HP-42.
2023-09-08 19:29:53 <KipIngram   > I just think that instead of having you make up names to  include in MVAR commands and then have to fetch from those names, your solver function should just use x, y, z, t as default variables that refer to the stack registers present on entry to the function.
2023-09-08 19:30:14 <KipIngram   > Anyway, I just think it could be made more code efficient than it is.
2023-09-08 19:34:17 <xelxebar    > Haha. Have seen something like that list of APL don'ts on Paul Mansour's blog.
2023-09-08 19:34:53 <KipIngram   > Although, I guess I also have to consider the interface the solver provides.  It gives you the variables to set across the soft buttons.
2023-09-08 19:35:07 <KipIngram   > It has to get those names from SOMEWHERE, so somewhere you have to have typed them in.
2023-09-08 19:35:17 <KipIngram   > I guess that's what the M in MVAR is for - "menu" vars.
2023-09-08 19:35:44 <KipIngram   > xelxebar: I like it; an awful lot of those really resonated with me.
2023-09-08 19:36:00 <xelxebar    > Kind of disagree with some of his ideas about naming things. Long-lived variables that span lots of code are probably really important global concepts that get used everywhere. Better to use one-variable names for those.
2023-09-08 19:36:32 <KipIngram   > Yeah, I thought the same.  Maybe "longer," but still not TOO long.
2023-09-08 19:36:47 <xelxebar    > For short-lived, local only variables that you only rarely interact with, then longer names make more sense IMHO.
2023-09-08 19:37:30 <KipIngram   > I don't think that - I think you want your code to look like math equations - to "read" like math equations.  And you don't usually see long variable names in math.
2023-09-08 19:37:37 <KipIngram   > You get x, y, u, v, etc.
2023-09-08 19:38:34 <xelxebar    > Oh, yeah, if conventions let you use short names that communicate meaning immediatly like that, then heck yeah.
2023-09-08 19:38:51 <KipIngram   > I think you need to be able to see the way the operator symbols "sit" with respect to each other - if you shove them too far apart with variable names you can't see that as well.
2023-09-08 19:39:34 <KipIngram   > It's just like digital circuits - the "shape" of the thing convey information.  Works for math equations too.
2023-09-08 19:39:52 <KipIngram   > That's why "real"  math print in books works so much better than some kind of ascii "typed out" equation.
2023-09-08 19:41:01 <KipIngram   > E = mc^2 just has more "punch" that Total_Energy = Rest_Mass*Speed_Of_Light^2.
2023-09-08 19:41:21 <KipIngram   > Your eye can just take in E = mc^2 in one "go."
2023-09-08 19:41:29 <KipIngram   > It can exist as an "object."
2023-09-08 19:42:16 <xelxebar    > Totally. Math orthography uses *tons* of conventions around naming, too, which really helps convey meaning. It'd be weird to se a complex number named something like n or k.
2023-09-08 19:42:18 <KipIngram   > It's also why Verilog isn't universally a good thing.  You lose hte notion of circuit "shape."
2023-09-08 19:42:48 <KipIngram   > I do recognize that Verilog lets you manipulate larger amounts of logic.
2023-09-08 19:43:56 <xelxebar    > That's why globally important concepts that thread throughout the entire code shoudl ideally be single-letter names. If you're reading the code, you should definitely need to grok those concepts, and those names cause minimal interference with the shape of the code.
2023-09-08 19:44:46 <xelxebar    > This is kind of Peak Style, IMHO: https://github.com/Co-dfns/Co-dfns/blob/master/src/codfns/PS.aplf
2023-09-08 19:44:53 <KipIngram   > Yes.
2023-09-08 19:46:40 <KipIngram   > This same notion is why I tend to under-comment my code.
2023-09-08 19:46:40 <xelxebar    > It's code that's extremely unfriendly to jumping in naively without grokking the big picture, but once you *do* grok the big picture, then the code really sings in a similar way that good physics papers do.
2023-09-08 19:46:54 <KipIngram   > The comment lines interfere with seeing the "layout" of the code on the page.
2023-09-08 19:47:09 <KipIngram   > For loops, while loops, etc. - those all have shapes too.
2023-09-08 19:47:42 <xelxebar    > Yeah. Comments definitely impose an overhead. They also just take up physical space, which could be used to display more meaningful code.
2023-09-08 19:48:34 <xelxebar    > Ah, I bet indentation conventions are a big part of the shape idea you're getting at.
2023-09-08 19:53:27 <xelxebar    > Kind of wish I had better hardware knowledge. I really like the idea of how 2D circuit diagrams provide different channels of communication not available in linear text.
2023-09-08 19:54:41 <KipIngram   > Yeah - just one example.  There's a concept called "reconvergent fanout."  This is where one signal gets split apart, goes along two different paths, and then derivatives of those signals come back together again later.
2023-09-08 19:54:48 <KipIngram   > It's a prime situation to get race conditions.
2023-09-08 19:55:00 <KipIngram   > since the timing of the two paths can be a little different.
2023-09-08 19:55:13 <xelxebar    > Seems mildly related to math notation vs. "mathy notation" like APL. One of the things that math notation does better, IMHO, is using fancy typography to convey information. Being limited to a linear stream of symbols is somewhat limiting.
2023-09-08 19:55:32 <KipIngram   > I once found an intermitting problem in a downhole oilwell acoustic instrument that I knew nothing about just from seeing reconvergent fanout go by on a schematic page.
2023-09-08 19:55:52 <KipIngram   > The guy that worked on it and I studied that part of the code, just because I saw that, and found a race condition.
2023-09-08 19:56:05 <xelxebar    > Oh cool. You saw the splay of lines and immediately thought "hrm, potential race condition"?
2023-09-08 19:56:18 <KipIngram   > So I didn't "see the problem" just by glancing at the page - but I saw something that made me decide it was worth a closer look.
2023-09-08 19:56:23 <KipIngram   > And THEN we saw the problem.
2023-09-08 19:57:07 <KipIngram   > I mean, I'm sure this is why different kinds of gates have different shapes.
2023-09-08 19:57:16 <KipIngram   > So that you can get that extra "channel."
2023-09-08 19:57:20 <xelxebar    > Tapping into that kind of pattern matching ability in the human brain is super helpful.
2023-09-08 19:57:53 <KipIngram   > I have a feeling you can't just 'learn' it either - I suspect it just comes with experience.
2023-09-08 19:58:54 <xelxebar    > I just wish this kind of thing was a more salient value in the current software development zeitgeist.
2023-09-08 19:59:08 <KipIngram   > And well, resistors, capacitors, transistors, etc. - they all have their shape.
2023-09-08 19:59:31 <KipIngram   > And it's a lot easier to grok a circuit than a SPICE listing.
2023-09-08 19:59:49 <xelxebar    > Something like Kubernetes yaml templates or your everyday json serialization ends up so "declarative" and uniform that it discombobulates the kinds of pattern matching you're talking about.
2023-09-08 20:00:11 <KipIngram   > Right.  Works great for the computer, but not for the human mind.
2023-09-08 20:00:30 <KipIngram   > Music notation.
2023-09-08 20:00:36 <KipIngram   > We do this kind of thing all over the place.
2023-09-08 20:00:46 <xelxebar    > Ooo. Yeah. Another good example.
2023-09-08 20:01:21 <xelxebar    > Also makes use of fancy typsetting.
2023-09-08 20:02:11 <KipIngram   > I used to keep tabs on a website called kottke.org.  He was a graphic designer.  There was a book he regularly raved over, on the pictorial representation of information.
2023-09-08 20:03:38 <KipIngram   > “The Visual Display of Quantitative Information” by Edward R. Tufte
2023-09-08 20:04:31 <thrig       > Tufte is good
2023-09-08 20:04:40 <thrig       > shows the lie factor in pie charts, etc
2023-09-08 20:04:54 <KipIngram   > Anyway, I think I need to retract my criticism of the DM-42 solver operation.  I'd totally forotten that the user interface had to be arranged for as well.  I was thinking only of the "equation program."
2023-09-08 20:05:04 <KipIngram   > But that's only part of the puzzle.
2023-09-08 20:06:00 <xelxebar    > Cool. Book looks available. Grabbing.
2023-09-08 20:29:16 <KipIngram   > Man, APL just has a whole ZOO of array manipulation operators.
2023-09-08 20:50:47 <KipIngram   > If there's anything I don't like about it, it's that memorization requirement.  I imagine it takes quite a while to get really fluid with it.
2023-09-08 20:51:16 <KipIngram   > It's kind of like LaTeX.  It can do damn near anything, but it's kind of just huge grab bag of "gadgets" you use to do it.
2023-09-08 20:51:44 <KipIngram   > And as far as that level of it goes there's no "systematic order" to it - you just have to learn 'em.
2023-09-08 21:59:47 <xelxebar    > KipIngram: It's really not that bad, just like 70 symbols. Most of them are dead simple and there's a decent amount of logic/symmetry to them.
2023-09-08 22:01:21 <xelxebar    > The hardest part, IMHO, is learning how to think in an array-like way such that the primitives map to nice domain-level concepts.