10:44 <KipIngram> You know, it occurs to me that my looping words almost obviate the need for tail optimization. If I want to recurse on the current word, I use my word ME (think of it sort like the way "self" is used in some languages).

10:44 <KipIngram> So the only time tail optimization would actually DO anything would be when the last word of a definition is some OTHER : definition word.

10:46 <KipIngram> ME is a primitive that directly compiles the jump a recursion by name would be optimized into.

10:50 <f-a> https://www.hackster.io/news/the-lisperati1000-is-a-cyberdeck-terminal-dedicated-to-lisp-programming-bb564f2ffcff now we need one for forth

10:51 <KipIngram> How cute. Well, there it is - we could re-flash it.

10:58 <KipIngram> It mentions that it runs on three 18650 batteries, but it doesn't say how long they will run it for.

11:05 <KipIngram> There used to be "Lisp machines," back in the early days of the microcomputer era.

11:06 <KipIngram> It would be interesting to tinker with what one could do with an FPGA to "accelerate" Lisp.

11:06 <KipIngram> Of course that probably wouldn't be battery-powered.

11:06 <KipIngram> FPGAs are little power piggies.

14:30 <cmtptr> so this isn't forth-related, but #forth is one of the best "general software design philosophy" channels i know of.

14:31 <cmtptr> one thing that i think i've recognized is very difficult for me is adopting a bad codebase and envisioning the path to a better codebase

14:31 <cmtptr> like, i can look at something and go "this sucks," but generally to improve it i have to just rewrite the whole thing from scratch

14:32 <cmtptr> i wonder if there are any good strategies to do that better

14:32 <boru> Start with tests before you start refactoring. It's easier to know if you broke functionality, then.

14:32 <f-a> some would say test drive- yeah

14:34 <cmtptr> well that helps me if i decide to just rewrite, but i mean that it's difficult for me to incrementally improve without rewriting

14:34 <f-a> eh, very difficult task

14:34 <boru> If it's not a modular design, then yes, incremental refactoring can be a can of worms.

14:34 <f-a> of course if you could break it modularly

14:34 <f-a> lol boru is faster than me

14:34 <boru> Which is rare for a Friday afternoon, f-a!

14:35 <f-a> hehe

14:38 <boru> Factoring can be a good start for refactoring, though.

14:38 <boru> Breaking down big monolith functions or modules to DRY them out a bit.

14:39 <boru> Then you can decide which parts of those need to actually be refactored, or do some opportunistic refactoring along the way.

14:40 <boru> If it's for work, usually the most difficult part is convincing management that it needs doing.

14:41 <boru> In which case I'd buy a copy of Koopman's Better Embedded System Software and whallopping them over the head with it.

14:42 <boru> It's a nice size that balances well in the hand for assaulting management.

14:45 <cmtptr> yeah, it is for work, and yes the most recent anecdote is that i've adoped responsibility of something that was written by somebody years ago (imo not that well designed in the first place), and then touched by several people over time since then, and today they want it to support new HW (something that was never a concept before), but they don't want me to touch old-HW implementation because testers don't

14:45 <cmtptr> want to have to reverify old HW functionality

14:45 <boru> That old chestnut. Organically grown software.

14:45 <cmtptr> i'm done now, but looking back at what i did, i'm not real happy with it. but i also don't see what i could have done better without a massive refactoring

14:46 <boru> "don't want to have to reverify old HW functionality" sounds a bit broken, imho.

14:46 <boru> Surely, catching regressions is their job.

14:47 <cmtptr> yep, 100% agree

14:47 <cmtptr> our verification sucks

15:08 <cmtptr> anyway thanks for your responses. you reminded me that one of the biggest shortcomings with this module is that - at the moment - it's basically incapable of being isolated and unit tested. going forward, i think that's what i might do as my background task

15:09 <cmtptr> that's an easy sell because making it unit-testable doesn't impact functionality