2023-09-09 01:26:43 <KipIngram   > Yeah, I'm talking about the HP42 solver.
2023-09-09 01:26:59 <KipIngram   > Those are actually from a whole slew of HP calculators from over hte years.
2023-09-09 01:27:27 <KipIngram   > Well, I'm actually talking about the DM42 Solver.
2023-09-09 01:27:44 <KipIngram   > But it's built with Free42 which is based on HP-42.
2023-09-09 01: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-09 01:30:14 <KipIngram   > Anyway, I just think it could be made more code efficient than it is.
2023-09-09 01:34:17 <xelxebar    > Haha. Have seen something like that list of APL don'ts on Paul Mansour's blog.
2023-09-09 01: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-09 01:35:07 <KipIngram   > It has to get those names from SOMEWHERE, so somewhere you have to have typed them in.
2023-09-09 01:35:17 <KipIngram   > I guess that's what the M in MVAR is for - "menu" vars.
2023-09-09 01:35:44 <KipIngram   > xelxebar: I like it; an awful lot of those really resonated with me.
2023-09-09 01: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-09 01:36:32 <KipIngram   > Yeah, I thought the same.  Maybe "longer," but still not TOO long.
2023-09-09 01:36:47 <xelxebar    > For short-lived, local only variables that you only rarely interact with, then longer names make more sense IMHO.
2023-09-09 01: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-09 01:37:37 <KipIngram   > You get x, y, u, v, etc.
2023-09-09 01:38:34 <xelxebar    > Oh, yeah, if conventions let you use short names that communicate meaning immediatly like that, then heck yeah.
2023-09-09 01: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-09 01:39:34 <KipIngram   > It's just like digital circuits - the "shape" of the thing convey information.  Works for math equations too.
2023-09-09 01: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-09 01:41:01 <KipIngram   > E = mc^2 just has more "punch" that Total_Energy = Rest_Mass*Speed_Of_Light^2.
2023-09-09 01:41:21 <KipIngram   > Your eye can just take in E = mc^2 in one "go."
2023-09-09 01:41:29 <KipIngram   > It can exist as an "object."
2023-09-09 01: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-09 01:42:18 <KipIngram   > It's also why Verilog isn't universally a good thing.  You lose hte notion of circuit "shape."
2023-09-09 01:42:48 <KipIngram   > I do recognize that Verilog lets you manipulate larger amounts of logic.
2023-09-09 01: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-09 01: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-09 01:44:53 <KipIngram   > Yes.
2023-09-09 01:46:40 <KipIngram   > This same notion is why I tend to under-comment my code.
2023-09-09 01: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-09 01:46:54 <KipIngram   > The comment lines interfere with seeing the "layout" of the code on the page.
2023-09-09 01:47:09 <KipIngram   > For loops, while loops, etc. - those all have shapes too.
2023-09-09 01: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-09 01:48:34 <xelxebar    > Ah, I bet indentation conventions are a big part of the shape idea you're getting at.
2023-09-09 01: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-09 01: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-09 01:54:48 <KipIngram   > It's a prime situation to get race conditions.
2023-09-09 01:55:00 <KipIngram   > since the timing of the two paths can be a little different.
2023-09-09 01: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-09 01: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-09 01: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-09 01:56:05 <xelxebar    > Oh cool. You saw the splay of lines and immediately thought "hrm, potential race condition"?
2023-09-09 01: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-09 01:56:23 <KipIngram   > And THEN we saw the problem.
2023-09-09 01:57:07 <KipIngram   > I mean, I'm sure this is why different kinds of gates have different shapes.
2023-09-09 01:57:16 <KipIngram   > So that you can get that extra "channel."
2023-09-09 01:57:20 <xelxebar    > Tapping into that kind of pattern matching ability in the human brain is super helpful.
2023-09-09 01:57:53 <KipIngram   > I have a feeling you can't just 'learn' it either - I suspect it just comes with experience.
2023-09-09 01:58:54 <xelxebar    > I just wish this kind of thing was a more salient value in the current software development zeitgeist.
2023-09-09 01:59:08 <KipIngram   > And well, resistors, capacitors, transistors, etc. - they all have their shape.
2023-09-09 01:59:31 <KipIngram   > And it's a lot easier to grok a circuit than a SPICE listing.
2023-09-09 01: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-09 02:00:11 <KipIngram   > Right.  Works great for the computer, but not for the human mind.
2023-09-09 02:00:30 <KipIngram   > Music notation.
2023-09-09 02:00:36 <KipIngram   > We do this kind of thing all over the place.
2023-09-09 02:00:46 <xelxebar    > Ooo. Yeah. Another good example.
2023-09-09 02:01:21 <xelxebar    > Also makes use of fancy typsetting.
2023-09-09 02: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-09 02:03:38 <KipIngram   > “The Visual Display of Quantitative Information” by Edward R. Tufte
2023-09-09 02:04:31 <thrig       > Tufte is good
2023-09-09 02:04:40 <thrig       > shows the lie factor in pie charts, etc
2023-09-09 02: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-09 02:05:04 <KipIngram   > But that's only part of the puzzle.
2023-09-09 02:06:00 <xelxebar    > Cool. Book looks available. Grabbing.
2023-09-09 02:29:16 <KipIngram   > Man, APL just has a whole ZOO of array manipulation operators.
2023-09-09 02: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-09 02: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-09 02: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-09 03: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-09 04: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.
2023-09-09 07:20:04 <KipIngram   > Yeah - this is just me complaining at the point of not knowing ANY of them very well.  :-)
2023-09-09 07:20:25 <KipIngram   > I played with it for a week or so a year or year and a half ago or so.  Still have Dyalog installed on my notebook.
2023-09-09 07:38:20 <KipIngram   > So, you know - I mentioned earlier that focusing on a calculator OS was a good way to have a "firm target.'  It occurs to me, though, that if I do this right I should have a system that's entirely portable except for the actual "user interface" layer.  Instead of running a small calculator LCD and using a calculator keyboard, I could just have a different interface more suitable for a computer.  No reason for
2023-09-09 07:38:22 <KipIngram   > anything else to be different at all.
2023-09-09 07:38:45 <KipIngram   > I should structure it with such a layered design in mind.
2023-09-09 08:14:05 <KipIngram   > So I wonder why they did choose to run math expressions right to left.  Once I started thinking about it I wasn't able to see any particular reason that it couldn't have been done left to right, so long as one was consistent.
2023-09-09 08:14:28 <KipIngram   > Also, I actually agree with APL's mentality that "precedence rules" really just complicate mathematics.
2023-09-09 08:14:46 <KipIngram   > A right-to-left or left-to-right "cleanliness" seems more "tight" to me.
2023-09-09 10:02:30 <veltas      > I like both, stuff like hasell $ to force a directional order if it's prudent but the good old groupings as well
2023-09-09 10:02:34 <veltas      > haskell*
2023-09-09 13:42:37 <xelxebar    > KipIngram: APL is really trying to be an incarnation of Iverson's "Notation as a Tool of Thought". For English, it turns out that right-to-left evaluation causes the code to map better to English verbalization.
2023-09-09 13:46:13 <xelxebar    > The proverbial paren parser +\1 ¯1 0⌷⍨⊂'()'⍳ '()(()(((())())))', for example, pretty much directly reads "running total of open parens minus close parens"
2023-09-09 13:47:46 <xelxebar    > Which reads declaratively. Flipping it around, we get something like "Mark open parens with 1, close parens with -1, then calculate the running total", which reads very procedurally.
2023-09-09 13:49:33 <xelxebar    > The first tends to be closer to how people informally communicate ideas to each other, IMO, which is my guess for (part of) why right-to-left evaluation was chosen.
2023-09-09 14:17:42 <vms14       > did you ever toy with the idea of a word with compound words?
2023-09-09 14:17:50 <vms14       > i always do
2023-09-09 14:18:00 <vms14       > of a forth with*
2023-09-09 14:18:58 <vms14       > it shouldnt be hard to provide
2023-09-09 14:19:18 <vms14       > but it can run into troubles
2023-09-09 14:20:32 <vms14       > i would try by making a special type of word for compound words which would be just a hash table
2023-09-09 14:20:52 <vms14       > and the next word i read must exist in that table
2023-09-09 14:21:03 <vms14       > which could be yet another compund word
2023-09-09 14:21:51 <vms14       > but if a compound word has words that you already use, it can be tricky to specify when you want to use a compound word or not
2023-09-09 14:22:11 <vms14       > and you might not know a compound word was defined which could alter your code
2023-09-09 14:27:32 <vms14       > i'd like to have that feature, but it looks like it will give me troubles at the end
2023-09-09 14:29:39 <vms14       > somehow if a compound word is a hash table it acts like a spacename in the sense that will act like a prefix
2023-09-09 14:31:28 <vms14       > and it can be nested
2023-09-09 14:31:55 <vms14       > the cat   the guy      the would be a hash table containing cat and guy
2023-09-09 14:32:15 <vms14       > the red cat the red guy
2023-09-09 14:32:33 <vms14       > the contains red which contains cat and guy
2023-09-09 14:39:31 <vms14       > in your point of view i guess a compound word would be a dictionary
2023-09-09 14:40:27 <vms14       > a dictionary contains words and compound words which are itself dictionaries able to contain another dictionaries and words
2023-09-09 14:48:13 <vms14       > i want a return stack at the end
2023-09-09 14:49:23 <vms14       > i want it since i wanted tco, but also helps when you want to improve the ability to bootstrap from few primitives
2023-09-09 14:49:58 <vms14       > if loop and alike can be implemented in the language itself as long as you have a return stack
2023-09-09 14:50:25 <vms14       > they can be implemented with other tricks, but meh
2023-09-09 14:50:40 <vms14       > it gives you more control overall anyways
2023-09-09 14:50:57 <vms14       > and tco
2023-09-09 14:52:22 <vms14       > also you can use it to implement some sort of condition/exception system
2023-09-09 14:52:45 <vms14       > and handlers, async stuff, etc
2023-09-09 14:53:12 <vms14       > and the best part is all this can be written in the language itself
2023-09-09 14:54:25 <vms14       > also i wonder about the compiling state flag
2023-09-09 14:54:58 <vms14       > i don't use it, but sometimes i felt i could do some things better with a flag
2023-09-09 14:55:56 <vms14       > forth is so cool actually
2023-09-09 14:57:14 <vms14       > i want to learn more about how to be able to bootstrap from few primitives
2023-09-09 14:58:05 <vms14       > the better i do that the easier is to implement the whole lang and to port it to other langs/platforms
2023-09-09 15:03:28 <xelxebar    > vms14: Agreed about the coolness at the core of Forth. Have you read through any implementations yet?
2023-09-09 15:06:37 <vms14       > not much more than the jonesforth and what i was told here
2023-09-09 15:07:49 <vms14       > and some posts and alike, but i always wanted to do the stuff in my way cause i was using perl to implement a rpn stack based lang and following the forth way of doing stuff did not make sense using a high level language
2023-09-09 15:08:19 <vms14       > but i always had envy on some features of forth i can never provide for not doing the stuff like forth does it
2023-09-09 15:08:48 <vms14       > for example memory allocation does not make sense
2023-09-09 15:09:15 <vms14       > i don't see why i should fake memory with some array and allocate cells there
2023-09-09 15:09:43 <vms14       > but if I dont have that most of forth words won't exist
2023-09-09 15:10:23 <vms14       > the dictionary is a linked list in forth while i decided to have an environment instead
2023-09-09 15:11:13 <vms14       > it's lexical scope, forget does not exist and it can't
2023-09-09 15:11:40 <vms14       > i always liked allot
2023-09-09 15:12:02 <vms14       > and the tricks you can do using memory, including the dictionary
2023-09-09 15:13:19 <dave0       > vms14: a stack also works for the dictionary
2023-09-09 15:14:08 <dave0       > vms14: the rule that it finds newer words first, also works with a stack
2023-09-09 15:14:13 <vms14       > my dictionary is a hash table with a parent slot
2023-09-09 15:14:55 <dave0       > hashing words is interesting
2023-09-09 15:15:38 <dave0       > hash tables are not my favorite data structure
2023-09-09 15:15:47 <dave0       > but they can be fast
2023-09-09 15:16:07 <vms14       > what can do a perl dev without hashes?
2023-09-09 15:17:30 <dave0       > who me? i dont know perl :-p
2023-09-09 15:18:21 <vms14       > i wonder if starting by having an array as memory
2023-09-09 15:18:25 <vms14       > xd
2023-09-09 15:18:49 <vms14       > it will be so fucking expensive, but it's not like i care
2023-09-09 15:19:24 <vms14       > but having a gc already it does not make much sense
2023-09-09 15:19:54 <dave0       > the trouble with growing memory is it needs operating system support :-(
2023-09-09 15:19:58 <vms14       > i could have both actually
2023-09-09 15:20:39 <dave0       > you cant really say "give me all the memory you have"
2023-09-09 15:20:50 <dave0       > maybe in dos you could
2023-09-09 15:20:58 <vms14       > variables and stack elements can go with the gc
2023-09-09 15:21:15 <vms14       > and give you a memory array that you use with allot
2023-09-09 15:21:48 <vms14       > dave0 i only can say the memory will grow as much as it can
2023-09-09 15:22:06 <vms14       > perl arrays will grow forever until there is no memory
2023-09-09 15:22:34 <vms14       > so its infinite memory most of the time
2023-09-09 15:22:39 <vms14       > :D
2023-09-09 15:23:16 <vms14       > 99% infinite
2023-09-09 15:25:09 <vms14       > and a cell is also of infinite size
2023-09-09 15:25:26 <vms14       > like the stack
2023-09-09 15:25:35 <vms14       > unlimited power i have
2023-09-09 15:26:51 <vms14       > well actually the limit is 3G since it will run on my phone which has 6 and already uses 3
2023-09-09 15:27:53 <dave0       > vms14: that's nice if the arrays automatically grow :-)
2023-09-09 15:27:59 <vms14       > i wonder if android will let termux eat that ram, but I guess no problem
2023-09-09 15:28:08 <dave0       > you gotta do it by hand in c
2023-09-09 15:28:54 <vms14       > dave0: thats why if i already have all that does not make sense to provide memory allocation
2023-09-09 15:29:27 <vms14       > but i guess if you want to allocate memory why i dont give you an array to play with
2023-09-09 15:29:45 <vms14       > the thing is a cell can be of any size
2023-09-09 15:29:56 <vms14       > including 3G
2023-09-09 15:29:59 <vms14       > xd
2023-09-09 15:30:15 <dave0       > i read somewhere that chuck likes to build his structures in memory and dump them out to disk in one go
2023-09-09 15:30:59 <vms14       > he also likes to fill the stack as soon as it can
2023-09-09 15:33:02 <vms14       > i should try to make a real forth in perl and see if i like it
2023-09-09 15:33:50 <vms14       > but it's hard without asm
2023-09-09 15:38:01 <vms14       > i wonder what i win with memory allocation
2023-09-09 15:38:20 <vms14       > for now i want the return stack
2023-09-09 15:38:44 <vms14       > but also the compile state flag i think can be handy
2023-09-09 15:39:20 <vms14       > i want forth's [  word which just changes that flag
2023-09-09 15:40:05 <vms14       > but the state flag indirectly involves the dictionary trough immediate words
2023-09-09 15:40:39 <vms14       > since immediate words can be used to manipulate dictionary entries and add stuff there
2023-09-09 15:55:33 <KipIngram   > vms14: Just a couple of weeks ago I mentioned the notion of having the ability to find "phrases" in the dictionary.  I can't remember now why I thought it might be useful.
2023-09-09 15:56:08 <KipIngram   > I guess it would be a sort of "greedy matcher" - it would match the longest string that it could on each step.
2023-09-09 15:56:53 <vms14       > https://www.ultratechnology.com/1xforth.htm
2023-09-09 15:57:12 <vms14       > funny to see chuck even dislikes the stack notation
2023-09-09 15:57:54 <vms14       > he says the stack should never have more than 4 or 5 parameters
2023-09-09 15:58:26 <KipIngram   > dave0, vms14: Having your RAM allocation grow dynamically as your data structures grow is called "table doubling," at least in the context of hash tables.  Going up by a factor of 2 is just an "easy an natural" way to do it.
2023-09-09 15:58:29 <vms14       > and that he chose a stack size of 18 as an infinite stack
2023-09-09 15:59:27 <vms14       > like no matter what program it executes, it will always have enough space
2023-09-09 15:59:44 <KipIngram   > yeah, Chuck basically just feels that words should be so simple that you don't need any of that - the code itself should make evident what it's doing.
2023-09-09 16:00:07 <vms14       > KipIngram: in part that's why i wanted compound words
2023-09-09 16:00:12 <veltas      > Multiplying by a factor to reduce effort of moving reallocations amortizes the work to a constant amount per insertion
2023-09-09 16:00:15 <vms14       > but meh
2023-09-09 16:00:22 <KipIngram   > I've never been able to get to Chuck's small stack sizes; there's just something about how he codes that makes that work.
2023-09-09 16:00:53 <vms14       > he tells you, the stack should never have more than 4 or 5 parameterds
2023-09-09 16:00:58 <KipIngram   > Right - the table doubling is expensive, but after amortization they still get O(1) on their hash table.
2023-09-09 16:01:20 <KipIngram   > I know he does, but I never wind up with code that's THAT stack efficient.
2023-09-09 16:01:25 <KipIngram   > Just not good enough yet, I guess.
2023-09-09 16:02:02 <KipIngram   > I have checked mine and found that at most I seem to use 17-18 items, so I guess "so far' 18 has been infinite for me.
2023-09-09 16:02:14 <KipIngram   > Mine's bigger, but that's how much the code I've written tends to use.
2023-09-09 16:02:22 <vms14       > the secret is just more definitions it seems
2023-09-09 16:02:53 <KipIngram   > No, I think there's more to it than that.  I think there's a basic notion of how one "approaches" algorithm design that would play into it.
2023-09-09 16:03:02 <vms14       > ah yeah
2023-09-09 16:03:17 <vms14       > like having to use less data by doing it in a certain way
2023-09-09 16:03:21 <KipIngram   > I've gotten pretty good at factoring - these days my definitions are about the same length as Chuck's.  I read somewhere that he averages like 44 chars.
2023-09-09 16:03:24 <vms14       > or reusing that data
2023-09-09 16:03:29 <KipIngram   > And I'm somewhere between 40-50.
2023-09-09 16:03:59 <KipIngram   > It matters to Chuck because in his chips he does hardware stacks.
2023-09-09 16:27:23 <vms14       > oh he has no else
2023-09-09 16:27:56 <KipIngram   > So there's an operational bit of these calculators that's a little complicated.  It involves real vs. complex numbers.  The most intuitive way to implement that would be to just naturally bring in complex numbers as your calculations demand.  If the result is complex, then you get a complex number.
2023-09-09 16:27:57 <vms14       > ah cause he has different return in a word
2023-09-09 16:28:26 <KipIngram   > But in some cases that's not what you want - instead if there's no real solution you want to regard it as a "no solution" situation and inform hte user of that.
2023-09-09 16:28:39 <KipIngram   > So you have to have mode settings to tell the calculator which one you want.
2023-09-09 16:29:09 <KipIngram   > Different returns in a word?
2023-09-09 16:29:13 <KipIngram   > Not sure what you mean.
2023-09-09 16:29:26 <vms14       > ; does not end a definition
2023-09-09 16:29:42 <vms14       > it is a return and he says you can have more than one return
2023-09-09 16:29:45 <KipIngram   > I just mean that he has specific limited hardware resources for his stacks, and the bigger he has to make those resources the more power they consume, the more resources, etc.
2023-09-09 16:29:58 <KipIngram   > Oh.  Right.
2023-09-09 16:29:59 <vms14       > and different entries in a word or something like that
2023-09-09 16:30:20 <KipIngram   > Yes, you get that by separating your headers from your definitions.
2023-09-09 16:30:28 <KipIngram   > So that adjacent definitions are truly adjacent in RAM.
2023-09-09 16:30:49 <KipIngram   > Then you can point headers into that anywhere.
2023-09-09 16:31:14 <vms14       > the definition is green and it might have a semicolon in the definition which means return but it does not mean end of definition. It can have more than one return, and you can have more than one entry point in here if you want.
2023-09-09 16:31:59 <KipIngram   > Yes.  The mere appearance of a ; doesn't necessarily take him out of compile mode.  He doesn't actually HAVE that "mode" anymore - it's just done with the colors.
2023-09-09 16:32:19 <KipIngram   > So you can think of his code as one long wall of code, and his headers just tell him where he can jump into it.
2023-09-09 16:32:38 <vms14       > I don't see that ELSE is as useful as the complexity it introduces would justify. You can see this in my code. I will have IF with a semicolon and then I will exit the definition at that point or continue.
2023-09-09 16:32:56 <KipIngram   > The headers are separate in my current system, though I don't use the colors.
2023-09-09 16:33:06 <vms14       > IF ~~~ ; THEN
2023-09-09 16:33:08 <KipIngram   > If i want a return without leaving compile mode I have ;,
2023-09-09 16:33:57 <KipIngram   > Then : ;  compile ;, state off ; immediate
2023-09-09 16:34:58 <vms14       > ooh
2023-09-09 16:35:07 <vms14       > he changed loops for recursion
2023-09-09 16:35:07 <KipIngram   > And if I have an unconditional jump (a loop) at the end of a definition, then I don't need a return there.  So instead of ; I use [
2023-09-09 16:35:35 <vms14       > .
2023-09-09 16:35:35 <vms14       > I've got a new looping construct that I am using in Color Forth and that I find superior to all the others. That is that if I have a WORD I can have in here some kind of a conditional with a reference to WORD. And this is my loop.
2023-09-09 16:35:36 <vms14       > WORD ~~~ IF ~~~ WORD ;
2023-09-09 16:35:36 <vms14       >  THEN ~~~ ;
2023-09-09 16:35:57 <KipIngram   > Right - that's tail recursion.
2023-09-09 16:36:19 <KipIngram   > You just change that final call to WORD to a jump.
2023-09-09 16:36:34 <KipIngram   > I have a dedicated word for it, though, ME
2023-09-09 16:36:43 <KipIngram   > ME compiles a jump back to the start of the current definition.
2023-09-09 16:36:55 <KipIngram   > It's shorter usually, which is nice, and also I can conditionalize it:
2023-09-09 16:37:00 <KipIngram   > 0=ME etc.
2023-09-09 16:37:14 <KipIngram   > Of course you DO need ; after a *conditional* loopback.
2023-09-09 16:37:23 <KipIngram   > In case you don't take the jump.
2023-09-09 16:38:06 <KipIngram   > "back to the latest entry point" is the only kind of loop I can do.
2023-09-09 16:38:12 <KipIngram   > But I can always put in an entry anywhere:
2023-09-09 16:38:26 <KipIngram   > : foo  ... : bar ... me [
2023-09-09 16:38:34 <KipIngram   > That would go back to bar because it's latest.
2023-09-09 16:39:03 <KipIngram   > In the upcoming system I plan to be able to do that without having to put an extra header in.
2023-09-09 16:41:36 <vms14       > he doesnt even have blocks
2023-09-09 16:42:16 <vms14       > he says there's plenty of memory so block uses the memory instead of disk
2023-09-09 16:42:28 <KipIngram   > well, that's just because he was doing an specific application on a specific machine that he knew had enough RAM to do what he wanted.
2023-09-09 16:42:46 <KipIngram   > and he was interfacing that application to DOS, which he did by just having DOS utilities to load and save high RAM.
2023-09-09 16:42:57 <KipIngram   > In any kind OF "generic" system you couldn't do without blocks.
2023-09-09 16:43:04 <vms14       > BLOCK is a wonderful word BLOCK accesses, used to access a region of disk. Now I define it as accessing region of memory. There is no reason to use the disk at all. With megabytes of memory available you just load your data into memory and go from there. There is no need for disk. So BLOCK becomes much much simpler.
2023-09-09 16:43:07 <KipIngram   > He just didn't need them FOR THAT JOB.
2023-09-09 16:43:23 <KipIngram   > Yes - just so.
2023-09-09 16:43:38 <KipIngram   > Because he did his mass storage access with DOS programs.
2023-09-09 16:44:03 <KipIngram   > He'd load high RAM from disk before even starting his Forth up, and later when he quite he'd archive it off to disk.
2023-09-09 16:44:21 <KipIngram   > s/quite/quit/
2023-09-09 16:44:45 <KipIngram   > I don't really count that as "proving that you don't need blocks."
2023-09-09 16:45:05 <KipIngram   > That was just an example of his "solve only the probelm you need to solve" mentality.
2023-09-09 16:45:27 <KipIngram   > His sole goal during that period, for his Forth, was to facilitate the design of his chips.
2023-09-09 16:45:43 <vms14       > My contention is that every application that I have seen that I didn't code has ten times as much code in it as it needs. And I see Forth programmers writing applications with ten times as much code as is necessary.
2023-09-09 16:45:54 <KipIngram   > He also didn't have vocabularies, but that doesn't mean you never need any namespace organization.
2023-09-09 16:46:16 <KipIngram   > Yeah - just using Forth isn't a magic bullet.
2023-09-09 16:46:26 <KipIngram   > Chuck was just supremely good at designing software.
2023-09-09 16:47:16 <KipIngram   > Typical programmers, though, will say "I want to use Library X," and that immediately forces them to make design decisions that will "fit" LibrarY x.
2023-09-09 16:47:28 <KipIngram   > And those might not be "optimum" in terms of solving the problem.
2023-09-09 16:47:55 <KipIngram   > And Library X almost certainly does MORE than what you're using it for, so you get extra code linked in that way too.
2023-09-09 16:48:29 <KipIngram   > Worse, the typical programmer says "I want to use Library X and Library Y," so then they need code to interface those two libraries together.
2023-09-09 16:48:44 <KipIngram   > Since they probably don't use exactly the same information format, etc.
2023-09-09 16:49:47 <KipIngram   > this can snowball, and the first thing you know most of your code is about arranging to work with those libraries.
2023-09-09 16:50:11 <vms14       > You factor, you factor, you factor and you throw away everything that isn't being used, that isn't justified
2023-09-09 16:50:26 <KipIngram   > You were just complaining half an hour ago about the stuff that's not easy for you to do because of how you've implemented your lang on top of other tools.  You're boxed in by those decisions.
2023-09-09 16:51:02 <KipIngram   > Over and over you've found that you *can't* make something truly Forth-like.
2023-09-09 16:51:36 <vms14       > cause i keep wondering if going to the forth way is actually the correct thing in my case
2023-09-09 16:51:47 <vms14       > which i always answer no
2023-09-09 16:52:04 <KipIngram   > I'm not criticizing - just pointing out that you've got a ready example of what I'm talking about.
2023-09-09 16:52:07 <vms14       > but some features keep me wondering
2023-09-09 16:52:37 <vms14       > and also wonder how much i have to get near to forth to steal that feature
2023-09-09 16:52:46 <KipIngram   > We say that all these things happen because of the pressure to ship fast, and that's true of course.  But I think a similar aspect of the situation is that there is great pressure on programmers to have "early visual results."
2023-09-09 16:52:58 <vms14       > and if there might be workarounds
2023-09-09 16:53:08 <KipIngram   > Not necessarily even "finished," but there's a pressure to be able to have somethingyou can show off to your boss as quickly as possible.
2023-09-09 16:53:27 <vms14       > well i got a lot of joy playing with the lang
2023-09-09 16:53:28 <KipIngram   > And the low-level coding associated with solving a problem from scratch doesn't really facilitate that very well.
2023-09-09 16:53:36 <KipIngram   > It can be a while before you have anything "to show."
2023-09-09 16:53:40 <vms14       > and as soon as i have the core part i make a repl
2023-09-09 16:54:12 <KipIngram   > It reassures your higher ups that you're "actually doing something."
2023-09-09 16:54:33 <vms14       > but i have a lot of decisions in my head and i want to see results
2023-09-09 16:54:43 <KipIngram   > I think that in most organizations the programmers that are highly regarded are the ones who have visual results the most quickly.
2023-09-09 16:55:05 <vms14       > i never got real results as i can stay for long without rewriting cause i took another decision
2023-09-09 16:55:08 <KipIngram   > and most managers can't even tell if that's actually "good code" or not.
2023-09-09 16:55:24 <vms14       > KipIngram: wouldn't surprise me
2023-09-09 16:55:24 <KipIngram   > Yes - like I said the other day, this is a learning expedition for you.
2023-09-09 16:55:39 <KipIngram   > A "playground," so to speak.
2023-09-09 16:55:44 <vms14       > recruiters have no idea about programming, but they hire developers
2023-09-09 16:55:55 <vms14       > why should have any idea the team manager?
2023-09-09 16:56:19 <KipIngram   > I know - I've always been of the belief that the leaders should be chosen from among your best techincal people.
2023-09-09 16:56:31 <KipIngram   > The ones who not only have strong basic skills, but also "see the big picture."
2023-09-09 16:56:51 <KipIngram   > So they SHOULD be able to judge their team's work in a technical way.
2023-09-09 16:57:39 <KipIngram   > But, that's just not how the world does it.
2023-09-09 16:58:19 <vms14       > if you say should in caps i'll understand you mean rfc's should
2023-09-09 16:58:56 <KipIngram   > I just don't think you can properly judge a person's performance in a job if you aren't able to do that job yourself.
2023-09-09 16:59:28 <KipIngram   > Doesn't mean you have to be lightning fast at it, or have it as your "forte," but you should know your way around the block well enough to have a real opinion about the person's performance.
2023-09-09 16:59:56 <KipIngram   > Because it's the manager's job to decide who to promote, who to make team leads, who to give raises to, etc.
2023-09-09 17:00:06 <KipIngram   > Who to fire.  :-(
2023-09-09 17:00:29 <KipIngram   > Who to move into a different type of work to better fit their skills and so on.
2023-09-09 17:01:26 <KipIngram   > Also who's reliable and can be counted on to deliver without detailed oversight, who needs handholding to get anything done... all that stuff.
2023-09-09 17:08:47 <KipIngram   > I also think the manager should be able to plan the team's work, on his own.  That doesn't mean you don't include the team in such discussions, but the manager should understand what needs to be done and who is good at what kinds of work to make a passable plan completely autonomously.
2023-09-09 17:09:21 <KipIngram   > Which includes having an idea of how long various items of work ought to take, etc.
2023-09-09 17:09:46 <KipIngram   > If the team is sandbagging the work schedule, the manager ought to be able to see it and call it out.
2023-09-09 17:12:05 <KipIngram   > If someone on the team is new to the profession, then the manager should be able to help them improve.  Sit down with them from time to time, look at the work together, point out new ideas to the person...
2023-09-09 17:12:39 <KipIngram   > "I don't know how that stuff actually works" just isn't an acceptable manager credential in my eyes.
2023-09-09 17:13:52 <vms14       > it is the design of his forth what makes code shorter
2023-09-09 17:13:53 <KipIngram   > In small companies things usually naturally evolve along the lines I'm talking about - it's in the big companies where you find the "professional managers."
2023-09-09 17:14:24 <KipIngram   > Yeah, Chuck's "success factors" are strewn all through his tools and methodologies.
2023-09-09 17:14:37 <KipIngram   > He's a "pervasive optimizer."
2023-09-09 17:14:50 <vms14       > for example he says if you work with a file you have to open it close read write
2023-09-09 17:15:16 <vms14       > his forth has no files so you would use block
2023-09-09 17:15:39 <KipIngram   > You know, if I'm going to have these "system" and "user" modes, where in user mode some of the instructions are type-directed, there's going to need to be a fast way to flip back and forth.
2023-09-09 17:16:12 <KipIngram   > Right - since there's not a file system to "automate" parts of the storage management you get to handle those things yourself.
2023-09-09 17:16:47 <vms14       > but i meant you dont have to call all those functions
2023-09-09 17:16:51 <KipIngram   > Same with floating point - he rejects that too, in facor of scaled integer solutions.  Which is really just you directly managing things the floating point library would do automatically.
2023-09-09 17:16:58 <vms14       > you just put the data on the block
2023-09-09 17:17:00 <KipIngram   > Right.
2023-09-09 17:17:03 <vms14       > no opening close etc
2023-09-09 17:17:14 <KipIngram   > Sure.  But you do have FLUSH.
2023-09-09 17:17:25 <KipIngram   > You eventually have to make sure the block gets written back out.
2023-09-09 17:17:38 <vms14       > that is what makes his code smaller
2023-09-09 17:17:46 <KipIngram   > It's one reason.
2023-09-09 17:18:01 <vms14       > he just simplifies the whole concept
2023-09-09 17:18:15 <vms14       > then uses that simple concept
2023-09-09 17:18:28 <KipIngram   > Yeah.  A file system might have N things it can do.  But in a given app Chuck might only need two of those things.
2023-09-09 17:18:40 <vms14       > i always felt bad for doing that
2023-09-09 17:18:51 <vms14       > like it was dirty and buggier
2023-09-09 17:18:53 <KipIngram   > So he doesn't have the baggage of N-2 features hanging around - he just does the two things, manually.
2023-09-09 17:19:28 <vms14       > is like chuck was a ultra lazy person
2023-09-09 17:19:46 <KipIngram   > Your floating point library can probably calculate sin() and tan() and ln() and e^x() etc.
2023-09-09 17:19:51 <KipIngram   > You may not need ANY of those.
2023-09-09 17:20:02 <KipIngram   > Depends on what you're doing.
2023-09-09 17:20:07 <vms14       > i never used any of those
2023-09-09 17:20:22 <KipIngram   > Oh, I have, but I worked in a university research lab, modeling EM fields.
2023-09-09 17:20:45 <KipIngram   > I imagine they are VERY OFTEN not needed.
2023-09-09 17:21:06 <KipIngram   > Most floating point code probably just does + - * /.
2023-09-09 17:21:19 <KipIngram   > And the truth is those aren't hard to do with scaled integers.
2023-09-09 17:21:57 <KipIngram   > On the disk front, it may be that you KNOW that what you're loading and saving is, say, 2.5k.
2023-09-09 17:22:07 <KipIngram   > If your block size is 4k, then you don't need ANY file system help.
2023-09-09 17:22:20 <KipIngram   > Just pick a spot on the disk for it to live and BLOCK it there - you're done.
2023-09-09 17:22:42 <KipIngram   > You may not need a record in a directory of where it is - you may just have chosen a number.
2023-09-09 17:23:01 <KipIngram   > The complexity of the solution can be adjusted to precisely fit the complexity of the problem.
2023-09-09 17:23:52 <KipIngram   > I do think Chuck's attitude is very extreme.  The common argument would be "But next month you're going to need to solve a different problem, and you're going to want it to use the same disk."
2023-09-09 17:24:05 <KipIngram   > So maybe more generic disk management is "long term" advantageous.
2023-09-09 17:24:12 <KipIngram   > Chuck just entirely rejects that type of reasoning.
2023-09-09 17:24:27 <KipIngram   > And I suppose there is a middle ground between the extremes.
2023-09-09 17:25:10 <KipIngram   > vms14: Let me note that if you wanted to write software for a 3D printer, or a cnc machine, you'd almost certainly need the trig functions.
2023-09-09 17:25:24 <KipIngram   > Because in both places you're dealing with where things are in space.
2023-09-09 17:26:30 <KipIngram   > If you need to go from A to B, you have to tell two separate motors how to move, and one of them moves distance*sin(angle) and the other distance*cos(angle).
2023-09-09 17:27:17 <KipIngram   > So you don't find that stuff ONLY in esoteric scientific analyses.
2023-09-09 17:30:21 <vms14       > chuck recommends to write a browser
2023-09-09 17:30:30 <vms14       > write  a new browser. It's a good application. It gives you access to a world of information. It's a good application and it one that I am trying to focus on in my spare time
2023-09-09 17:30:41 <KipIngram   > At the time he made that recommendation browsers were a  LOT less complex than they are now.
2023-09-09 17:30:45 <vms14       > xd
2023-09-09 17:30:58 <KipIngram   > I suspect he was talking about just handling HTML.
2023-09-09 17:31:08 <vms14       > but a simple text browser could be fun
2023-09-09 17:31:19 <KipIngram   > Sure.
2023-09-09 17:31:46 <vms14       > i should write one and name it chuck
2023-09-09 17:31:53 <KipIngram   > Hee hee.
2023-09-09 17:32:07 <KipIngram   > I think a typesetting system could also be fun.
2023-09-09 17:32:21 <KipIngram   > Once again, though, LaTeX is... vast.
2023-09-09 17:32:43 <vms14       > but you mean something that generates latex code?
2023-09-09 17:33:04 <KipIngram   > No, I meant writing the code to take some specification of the document and produce the pixel patterns.
2023-09-09 17:33:35 <KipIngram   > Go from a human written text spec to a 2D array of pixels.
2023-09-09 17:33:36 <vms14       > and produce for example a png?
2023-09-09 17:33:45 <KipIngram   > Or a BMP, or whatever.
2023-09-09 17:34:01 <KipIngram   > There's a ton of issues involved with making text look good on a display.
2023-09-09 17:34:09 <vms14       > actually you just need to draw into a pixmap
2023-09-09 17:34:21 <KipIngram   > Yes, but WHAT YOU DRAW is the issue.
2023-09-09 17:34:29 <KipIngram   > In the end, you want it to be smooth, beautiful text.
2023-09-09 17:34:42 <vms14       > would you read font glyphs and use them?
2023-09-09 17:34:43 <KipIngram   > Of whatever size the user called for, maybe italicized, bold, etc. etc.
2023-09-09 17:35:04 <KipIngram   > Well, what if you want to support any font size at all?
2023-09-09 17:35:28 <KipIngram   > I'm talking about taking some sort of geometric specification of what the characters look like, and then dynamically making a bit image of the proper size.
2023-09-09 17:35:33 <vms14       > would you scale it with the same technique as the zoom?
2023-09-09 17:35:38 <KipIngram   > Not just having umpteen zillion different font tables.
2023-09-09 17:36:15 <KipIngram   > To some extent you scale in a standard way, but you can get "artifacts" in how the final image looks that you need to take steps to remove.
2023-09-09 17:36:23 <KipIngram   > That's my point, it's a deeply "subtle" job.
2023-09-09 17:36:32 <KipIngram   > It's an "area of expertise."
2023-09-09 17:36:40 <vms14       > you might want to use svg fonts
2023-09-09 17:36:54 <vms14       > they're declarative
2023-09-09 17:36:58 <KipIngram   > Yes, you might want something like that for your original character spec.
2023-09-09 17:37:08 <KipIngram   > But if your output device is bitmapped, you eventually have to cross that bridge.
2023-09-09 17:37:42 <KipIngram   > And large fonts aren't just zoomed up copies of small fonts - you need to fill in stuff and smooth stuff and so on.
2023-09-09 17:37:53 <vms14       > see a text browser is funnier
2023-09-09 17:38:17 <KipIngram   > I'm just pointing out that both of these are tasks that would lead to a lot of learning.
2023-09-09 17:39:04 <KipIngram   > There are so many interesting problems that would lead to learning, though.
2023-09-09 17:39:13 <KipIngram   > Another one is to write a baby SPICE system.
2023-09-09 17:39:24 <KipIngram   > Text spec of a circuit -> circuit's dynamical behavior.
2023-09-09 17:39:46 <KipIngram   > That gets you right into numerical analysis, which is a hugely interesting field.
2023-09-09 17:41:22 <KipIngram   > That's one thing Chuck did I find very interesting - he did all his own transistor circuit modeling, and he did it using fixed point numbers.
2023-09-09 17:41:41 <KipIngram   > And claimed he got more accurate results than off the shelf tools offered.
2023-09-09 17:42:27 <KipIngram   > Part of how he would have done that, though, would have been to recognize the boundaries of his own cicuit modeling needs and solved only those parts that needed solving.  he didn't have to be prepared for any bizarre circuit a random user might toss at the tool.
2023-09-09 17:43:18 <KipIngram   > A big part of why Chuck's code is small is that he's good at recognizing what he DOES NOT need to do.
2023-09-09 17:43:52 <vms14       > a browser gets fun when you have to accept bad html
2023-09-09 17:44:01 <KipIngram   > Absolutely.
2023-09-09 17:44:07 <vms14       > which means any html you will fetch from internet
2023-09-09 17:44:26 <KipIngram   > Good path code is often fairly straightforward.
2023-09-09 17:45:17 <KipIngram   > The best way to do "error handling" in a system is to eliminate the possibility of the error happening in the first place.
2023-09-09 17:45:28 <KipIngram   > The only time you CAN'T do that is when a user is in the loop somewhere.
2023-09-09 17:45:55 <KipIngram   > In an embedded system where one automated thing is talking to another, you don't necessarily need sophisticated error checking.  Just make sure there aren't any errors.
2023-09-09 17:46:30 <KipIngram   > A power supply that's only ever going to have one circuit connected to it, because it's hard-wired on a circuit board, doesn't need to watch out for a "wrong loaD" being connected.
2023-09-09 17:46:32 <KipIngram   > Etc.
2023-09-09 17:47:54 <KipIngram   > of course, a component failure in the "right load" could create a bad state - so you do have to be prepared for that.
2023-09-09 17:48:10 <KipIngram   > But it's just not as "open ended" a problem as it is when you're dealing with a human.
2023-09-09 17:48:30 <KipIngram   > For one thing, you have to assume the human is going to deliberately TRY to break you.
2023-09-09 17:51:06 <KipIngram   > Looks like APL's "array handling" goes beyond Python's and most others.  In Python you don't really have a 2D array - you have an "array of arrays" instead.
2023-09-09 17:51:14 <KipIngram   > Hence [i][j] instead of [i,j].
2023-09-09 17:51:22 <KipIngram   > But APL can deal with both.
2023-09-09 17:51:33 <KipIngram   > Up to arbitrary rank.
2023-09-09 17:53:03 <KipIngram   > To me the difference between an array and a list is that all items in an array are the same size, and they're situated in contiguous RAM.
2023-09-09 17:53:13 <KipIngram   > I.e., it's an array IN RAM.
2023-09-09 17:53:22 <KipIngram   > Whereas items in a list can be anything.
2023-09-09 17:58:27 <KipIngram   > So if you've got a real array and you store a complex number into one of its entries, you'd need to promote the entire array.
2023-09-09 17:59:58 <KipIngram   > Looks to me like addressing a multi-dimensional array would mean you needed to set up so that you could take the dot product of an index vector and a "dimension sizE" vector, or some derivative of a size vector.
2023-09-09 18:00:30 <KipIngram   > And somewhere there would be some tight assembly code for doing that.
2023-09-09 18:02:43 <KipIngram   > xelxebar: Maybe I need to launch myself a process of "one APL glyph per day" and just start working through them.  According to your words last night I'll know the bulk of it in a couple of months.
2023-09-09 18:07:21 <vms14       > i think ill end using vim
2023-09-09 18:07:37 <vms14       > it makes more sense with this keyboard
2023-09-09 18:08:00 <vms14       > i get crazy with emacs hotkeys and not willing to make a setup
2023-09-09 18:08:22 <vms14       > plus i always wanted to escape from emacs anyways
2023-09-09 18:09:09 <vms14       > just need to set esc as control
2023-09-09 18:30:11 <KipIngram   > Use CapsLock.
2023-09-09 18:30:27 <KipIngram   > For control, I mean.
2023-09-09 18:30:54 <KipIngram   > I've always regarded emacs and vim as "similar undertakings."
2023-09-09 18:31:09 <KipIngram   > About the same amount of work required to get "competent" for either one of them.
2023-09-09 18:34:42 <KipIngram   > Re: that array indexing, performance would be higher if the "sizes" of each layer entity was a power of two.
2023-09-09 18:35:05 <KipIngram   > That could get quite wasteful in pathological cases, though.
2023-09-09 18:40:54 <vms14       > oh thats fine
2023-09-09 18:41:07 <vms14       > termux has an option to make the back key be space
2023-09-09 18:41:40 <vms14       > now i just need to get used to vi
2023-09-09 18:41:49 <vms14       > i know just some basics
2023-09-09 18:42:10 <vms14       > but i remember the hotkeys made sense even for mnemonic purposes
2023-09-09 18:42:44 <vms14       > it's hard to use emacs with this keyboard i get super confused
2023-09-09 18:43:48 <vms14       > lol back key be escape*
2023-09-09 19:06:01 <KipIngram   > Wait - don't you need the back key for... well, "backing up"?
2023-09-09 19:06:49 <thrig       > backups are good to have
2023-09-09 19:06:56 <vms14       > actually it was troubling me when pressed it by accident
2023-09-09 19:07:10 <vms14       > now it will even be useful
2023-09-09 19:07:14 <vms14       > :D
2023-09-09 19:07:42 <vms14       > and i hope i don't get confused like with emacs
2023-09-09 19:08:42 <KipIngram   > There are some handy little tricks for getting around quickly in vim.  You can google up articles on it.  Often the fastest way to get somewhere is to use search.
2023-09-09 19:09:02 <KipIngram   > Just pick any little substring long enough to be unique near where you want to go and fire off a search.
2023-09-09 19:09:09 <KipIngram   > Then cursor the rest of the way.
2023-09-09 19:09:38 <KipIngram   > The collapseos "simple editor" works this way too - you can move the insert point by searching.
2023-09-09 19:10:39 <vms14       > i had marks in comments in the past to search them xd
2023-09-09 19:10:48 <KipIngram   > I did like the emacs ability to inject a control string without having to "leave" insert mode.
2023-09-09 19:11:18 <vms14       > i think for this keyboard command/insert mode makes more sense
2023-09-09 19:11:43 <vms14       > as i don't really get any benefit using control + something hotkeys
2023-09-09 19:11:43 <KipIngram   > Yeah, if you're typing along and you think you're going to want to come back and polish what you're typing, it's easy just to stick a foo or soemthing in there and then search for all the foos later.
2023-09-09 19:12:16 <vms14       > it makes sense in a standard keyboard because of what they call tempo
2023-09-09 19:12:27 <vms14       > but here there is no tempo :/
2023-09-09 19:14:11 <thrig       > lack of f t F T drives me nuts in other editors
2023-09-09 19:15:34 <KipIngram   > f t F T?
2023-09-09 19:16:51 <KipIngram   > Oh, one thing I find interesting in APL is the ability to take any complex array type thing and "put it in a box" and now it's basically a scalar.
2023-09-09 19:20:18 <thrig       > fE move to first E on line; 2fo move before second o on line, etc
2023-09-09 19:20:46 <KipIngram   > Oh, ok.
2023-09-09 19:20:55 <thrig       > whoops, 2to for before
2023-09-09 19:21:31 <KipIngram   > Wow - I didn't know about those.  That's cool.
2023-09-09 19:21:38 <KipIngram   > I knew about the number prefix, of course.
2023-09-09 19:21:53 <KipIngram   > But that you just told me about - that looks damn useful.
2023-09-09 19:22:01 <KipIngram   > Thanks.  :-)
2023-09-09 19:22:26 <vms14       > https://stackoverflow.com/questions/12495442/what-do-the-f-and-t-commands-do-in-vim
2023-09-09 19:23:43 <KipIngram   > What I think would be nice is a "transient" command method.
2023-09-09 19:24:18 <KipIngram   > Say you're in insert mode.  I'd like to be able to just TAP the control key, and then do something like 20j or whatever.
2023-09-09 19:24:30 <KipIngram   > Get that mobility, but not actually have to do esc and i.
2023-09-09 19:24:52 <KipIngram   > So tapping control would get you a one-shot command.
2023-09-09 19:25:27 <KipIngram   > The general goal of minimizing esc/i iterations seems like a good one to me.
2023-09-09 19:26:39 <vms14       > idk how much lets you configure the editor, but it seems doable
2023-09-09 19:26:58 <vms14       > you just need to wrap the command into esc and i
2023-09-09 19:27:41 <vms14       > at least in emacs you can do a lot of stuff, and i've heard stuff that makes me feel like what you want is doable
2023-09-09 19:28:09 <vms14       > i'd like to make my own editor
2023-09-09 19:28:16 <vms14       > or some kind of rlwrap
2023-09-09 19:28:36 <vms14       > i want to bind words to hotkeys
2023-09-09 19:35:05 <vms14       > i wonder why do you use vi when you could be using your own editor
2023-09-09 19:38:12 <vms14       > im playing a bit with it and it feels much more comfortable
2023-09-09 19:38:54 <vms14       > and now i can almost code with one hand
2023-09-09 19:39:18 <vms14       > i couldnt even move with one hand with emacs
2023-09-09 19:39:23 <vms14       > unless using the screen
2023-09-09 19:40:38 <vms14       > thrig: so you move mainly with f t F T?
2023-09-09 19:42:05 <vms14       > ah it only works by lines
2023-09-09 19:42:08 <vms14       > :/
2023-09-09 19:42:49 <vms14       > it's cool anyways
2023-09-09 19:43:12 <vms14       > if it worked on the whole file i would move mainly with that xd
2023-09-09 19:52:53 <KipIngram   > Implementing editors in Forth is always fun.  :-)
2023-09-09 19:53:09 <KipIngram   > Block editing is considerably simpler than file editing, so you can more quickly get something you can play with.
2023-09-09 19:53:39 <KipIngram   > You know how EXPECT takes a buffer address and a max size?
2023-09-09 19:54:17 <KipIngram   > You can leverage that into block editing if you write it so that you can specify "the entire remainder of your block" as the "max size, but have EXPECT  only "work on" and "print" the first line of that, up to the first carriage return.
2023-09-09 19:54:47 <KipIngram   > Then give yourself an entry into that code that allows the buffer to have pre-existing content in it, and allows you to position the cursor on entry.
2023-09-09 19:55:04 <KipIngram   > Then you have something that lets you "edit a line," but it will shift all the following lines around just the right way.
2023-09-09 19:55:20 <KipIngram   > So you just point it at the line you want to edit and use it - the rest takes care of itself.
2023-09-09 19:55:41 <KipIngram   > Of course, you may be moving thousands of bytes on every keystroke, but... computers are fast enough for that.
2023-09-09 19:56:04 <KipIngram   > And you do it with CMOVE, so it takes advantage of REP.
2023-09-09 19:57:48 <KipIngram   > My current editor is really just a line editor, but I have a command that will re-list the block as it stands now, with numbered lines, and then I just edit by line number.
2023-09-09 19:58:06 <KipIngram   > Commands to insert lines, delete lines, etc.
2023-09-09 19:58:14 <KipIngram   > It's crude, but it's functional.
2023-09-09 20:05:08 <KipIngram   > xelxebar: What I need to do with these APL glyphs is get myself a really clear picture of a multi-D array in mind and get real clear on what each one does to it.
2023-09-09 20:05:32 <KipIngram   > I have a suspicion that it's mostly about being able to re-arrange those arrays in various ways, pluck stuff out of them, etc.
2023-09-09 20:10:11 <KipIngram   > Take something like transpose, for example - you could hit a multi-D array with that at any  level.