2025-11-27 00:20:10 <anthk_      > got muxleq' eforth running the bundled sokoban
2025-11-27 00:20:47 <anthk_      > I know sokoban.fs exists too, but I was just having fun
2025-11-27 09:03:24 <veltas      > isene: So it's a direct threaded 64-bit Forth, which you don't tend to see, humans tend to prefer either a compact model or an efficient model
2025-11-27 09:03:46 <veltas      > At 64-bit DTC just doesn't seem worth it
2025-11-27 09:06:37 <veltas      > With a 2 instruction NEXT you'd usually inline it (or make it a macro rather than jump in asm)
2025-11-27 09:07:26 <veltas      > It's not using a top-of-stack register which makes the code easier to read and write but impacts performance and probably makes it longer
2025-11-27 09:11:10 <veltas      > There's a ton of code that would generally be written in Forth or manually encoded Forth colon words, e.g. the printing stuff, that's written in asm
2025-11-27 09:11:56 <veltas      > There's multiple calling conventions as a result, some functions are C-style using call's and some are using Forth's conventions
2025-11-27 09:12:09 <veltas      > So you can't use the C-style stuff without a shim
2025-11-27 09:13:48 <veltas      > I'm not seeing a dictionary
2025-11-27 09:15:38 <veltas      > The README seems to refer to files that don't exist, and I'm not really convinced the code can run the example session given
2025-11-27 09:20:47 <veltas      > The code does actually run and allow that session but I don't really understand where the dictionary comes from
2025-11-27 09:20:54 <veltas      > Not a lot of error handling
2025-11-27 09:40:42 <veltas      > Are your register conventions documented anywhere?  There just seems to be some bizarre bits where registers are saved because they're used specially in outer loops
2025-11-27 09:40:57 <veltas      > But not a proper listing of how you've allocated them for anyone writing assembly words
2025-11-27 09:46:10 <veltas      > What's going on with "word_cr" for example, what is the point of that?  It doesn't exit with a NEXT and just seems redundant compared to newline
2025-11-27 09:46:40 <veltas      > There's a lot of stuff like that in here where I'm thinking that whatever wrote this didn't really 'think' about what they were doing and just wanted to be 'finished'
2025-11-27 09:47:29 <veltas      > Also writing a Forth isn't actually hard, it's almost harder to write good Forth code itself, partly because the Forth environment is so minimal
2025-11-27 09:47:53 <veltas      > So I'm not really surprised if claude can write one
2025-11-27 09:48:32 <veltas      > The main benefit of writing one is personal, so there's not a lot of benefit for claude writing one, it's just nice to say "I wrote a compiler and env in assembly"
2025-11-27 09:51:23 <veltas      > Looking at the transcript, it feels like the code doesn't really match the 'vision' that Claude talks beautifully about at the start
2025-11-27 09:54:14 <veltas      > It's mentioned that the assembly is heavily commented, but personally I didn't find most of the comments helpful
2025-11-27 09:56:10 <veltas      > I think I'd be more interested to see how this project *matures* with continued use, and to solve actual problems.
2025-11-27 09:58:10 <veltas      > Maybe you can do some programming challenges on it, develop some kind of useful personal application, or create some kind of more sophisticated OS or graphical environment running atop the Forth base
2025-11-27 09:58:56 <veltas      > The big question is how it deals with increasing complexity of the architecture, and technical debt building up
2025-11-27 14:51:02 <isene       > Cool feedback. Since this was a pure experiment from the day I couldn't really code myself, I found it interesting that CC could produce workable low level code. Not sure where to go with this experiment just yet. We'll see.
2025-11-27 15:06:52 <veltas      > In your experience do you find Claude handles criticism well, if I had tried this with Claude and pointed out the above while it was writing the Forth would it have worked well?
2025-11-27 15:08:02 <veltas      > I would try myself but Claude doesn't run on my laptop, I don't have enough RAM or hard drive space to run
2025-11-27 15:26:22 <isene       > I actually did pass it straight to CC and it answered this:
2025-11-27 15:26:54 <isene       > ● Excellent, honest technical feedback! Let me analyze each point:
2025-11-27 15:26:56 <isene       >   Technical Critiques (Valid)
2025-11-27 15:26:58 <isene       >   vdupras:
2025-11-27 15:27:00 <isene       >   - "5 zeros!" - My comment, not copied code
2025-11-27 15:27:02 <isene       >   - Big table vs jumps - Fair, less efficient
2025-11-27 15:27:04 <isene       >   - "No human could come up with .try_swap" - Amusing
2025-11-27 15:27:06 <isene       >   - "Pretty bad code" - Harsh but technical honesty
2025-11-27 15:27:08 <isene       >   veltas's detailed review:
2025-11-27 15:27:10 <isene       >   Architecture:
2025-11-27 15:27:12 <isene       >   - 64-bit DTC unusual/inefficient - Could use token threading
2025-11-27 15:27:14 <isene       >   - No TOS register - Would be faster with cached top-of-stack
2025-11-27 15:27:16 <isene       >   - Mixed calling conventions - C-style + Forth style = messy
2025-11-27 15:27:18 <isene       >   - Register allocation undocumented - Should document R15, RBP, etc.
2025-11-27 15:27:20 <isene       >   Code Quality:
2025-11-27 15:27:22 <isene       >   - Printing in asm vs Forth - Should be Forth words
2025-11-27 15:27:24 <isene       >   - Redundant functions (word_cr) - True
2025-11-27 15:27:26 <isene       >   - Didn't 'think', just 'finished' - Ouch but fair critique
2025-11-27 15:27:28 <isene       >   - Comments not helpful - Should explain WHY not WHAT
2025-11-27 15:27:30 <isene       >   Big Questions:
2025-11-27 15:27:32 <isene       >   - Code doesn't match vision - Haven't done DEVICE-* yet
2025-11-27 15:27:34 <isene       >   - How does it mature? - Technical debt management
2025-11-27 15:27:36 <isene       >   - Use for real problems - Needs proof
2025-11-27 15:27:38 <isene       >   - Complexity handling - Key concern
2025-11-27 15:27:40 <isene       > And then it went on with how it would plan to tackle every point.
2025-11-27 15:32:20 <KipIngram   > There are always naysayers.  I think any sort of "creation" is a good thing - we learn from them, and they're something in the world that wasn't there before.
2025-11-27 15:33:06 <KipIngram   > I've mostly withdrawn from "intellectual" communities, because the prevailing culture is practically always judgmental and negative.
2025-11-27 15:33:16 <KipIngram   > Rather than helpful and encouraging.
2025-11-27 15:33:59 <KipIngram   > I don't remember whether it was Stack Overflow or Stack Exchange that really drove that impression home for me, but it was one of those.
2025-11-27 15:41:20 <vdupras     > The code was written by a machine. There is no point in being "encouraging". It's like trying to be encouraging when watching the output of GCC. Unless you're talking to a GCC developer (isene does not work for Anthropic I presume), it's pointless to be "encouraging"
2025-11-27 15:43:36 <veltas      > If Claude knows not to write WHAT instead of WHY comments then why did it write them lol
2025-11-27 15:44:03 <veltas      > I guess because it doesn't 'know' anything and it's a black box of smoke and mirrors
2025-11-27 15:45:03 <veltas      > I'm interested in seeing what else it wrote isene, but please avoid dumping too much in here (although what you dumped was comparable to my own brain dump so I think that's fair)
2025-11-27 15:49:52 <vdupras     > isene: concerning "less efficient", I'd be curious to see Claude's detailed analysis. In terms of speed, it's certainly not faster than a big lookup table. In terms of saved binary space? Considering the volume of the code, I'm not sure there's that much space saved. It might even be negative. Claude might be bullshitting on the tradeoff aspect
2025-11-27 15:53:15 <isene       > Yeah, I did snip the CC response to match your feedback size. Here's a bit more:
2025-11-27 15:53:38 <isene       >   The feedback is a gift. It's honest technical review from experienced developers.
2025-11-27 15:53:40 <isene       >   What they're really asking:
2025-11-27 15:53:42 <isene       >   1. Will this architecture scale or collapse under complexity?
2025-11-27 15:53:44 <isene       >   2. Is the pure object model robust for real use?
2025-11-27 15:53:46 <isene       >   3. Can you actually build DEVICE-* on this foundation?
2025-11-27 15:53:48 <isene       >   To prove the model:
2025-11-27 15:53:50 <isene       >   - Implement DEVICE-* (original vision)
2025-11-27 15:53:52 <isene       >   - Use for real problems (demos/challenges)
2025-11-27 15:53:54 <isene       >   - Document conventions properly
2025-11-27 15:53:56 <isene       >   - Show it can mature without becoming spaghetti
2025-11-27 15:53:58 <isene       >   The pure object model we just added addresses some concerns (scalability, consistency).
2025-11-27 15:54:00 <isene       >   Next steps to validate:
2025-11-27 15:54:02 <isene       >   1. Implement SCREEN following DEVICE-* pattern
2025-11-27 15:54:04 <isene       >   2. Build something real with it
2025-11-27 15:54:06 <isene       >   3. Show the architecture holds up
2025-11-27 15:54:12 <isene       > I did iterate a few times and will commit the result soon. Stay tuned in the repo
2025-11-27 15:55:46 <vdupras     > no, what I'm really asking is a detailed response on .try_swap, a detailed tradeoff analysis. What exactly is meant by "less efficient"
2025-11-27 15:57:56 <vdupras     > You see, I'm confident that you yourself are a human, but because of the incomplete knowledge you have on Claude's creation, we can't even talk about it without you relying on Claude for interpreting questions, which means that even when we actually converse with a human, we in fact converse with Claude. It's disconcerting.
2025-11-27 16:03:01 <veltas      > Yeah I will check that out later isene
2025-11-27 16:08:29 <isene       > I was here simply releying some snippets from CC that you asked about and purposefully not interjecting any of my own opinions into this. Since you asked how CC responded to criticism, I gave you the above. For me this is an interesting adventure at the edge of AI. I have written a fair amount of MCODE for the coconut processor (as you can see in my repos) and also Forth in various environments up
2025-11-27 16:08:31 <isene       > through the past 30+ years, But this is about researching the opportunities and limitations of AI in coding.
2025-11-27 16:09:05 <veltas      > Don't mix me and vdupras up by the way :P
2025-11-27 16:09:47 <veltas      > I'll look at your portfolio later I'm just busy right now, I've been interested by what you've said so far which is why I'm engaging with it and leaving my thoughts
2025-11-27 16:10:12 <veltas      > I'm definitely sceptical, especially after reading the code, because there is a lot of strange unexplained stuff in there
2025-11-27 16:10:49 <veltas      > I wouldn't write it off over that but then also frankly there's a lot of societal anxiety regarding AI and I don't exactly blame people for being nay-sayers or doom-sayers
2025-11-27 16:11:44 <isene       > ah, a slight hit of "dyslexia" over the two nicks. Sorry about that.
2025-11-27 16:13:30 <veltas      > What used to get me is I used irrsi's nickcolor.pl script for years which had a terrible hash, where anagrams were the same color, and in the lua channel there was two regular contributors who had the same name of xyzxyz or something similar with different orders of letters
2025-11-27 16:13:47 <veltas      > So I could never tell them apart
2025-11-27 16:13:50 <isene       > I am very interested and curious about people's responses and emotions when it comes to AI. I take all responses and feedback as food for my research into the human/AI area. I cover this in a couple of chapters in the book I write.
2025-11-27 16:14:16 <isene       > veltas: Yeah, in my weechat here you are both purple. Dosn't really help
2025-11-27 21:29:16 <veltas      > isene: I like your website, and XRPN
2025-11-27 21:44:47 <veltas      > Oh by the way I think XCHG is actually really bad on some older chipsets like some of the atom processors
2025-11-27 21:44:55 <veltas      > Although maybe not any 64-bit wide ones?
2025-11-27 21:46:17 <veltas      > But yeah I'm not sure XCHG is always more efficient, better use of space though maybe
2025-11-27 21:50:23 <veltas      > You wouldn't usually use R14 as TOS, you'd use a register like e.g. RAX that works better with some ops like divide, and has a shorter encoding sometimes if REX isn't required
2025-11-27 22:17:14 <isene       > veltas: Thanks for the input, appreciated.
2025-11-27 22:20:41 <veltas      > Dot would usually print a blank after so you can do 1 2 3 . . . and get "3 2 1 "
2025-11-27 22:21:00 <veltas      > I mean it doesn't have to but would usually, it's your Forth
2025-11-27 22:21:30 <veltas      > Looks like `words` is broken on latest commit
2025-11-27 22:23:34 <KipIngram   > I've often seen (.) print with no space, and then : . (.) SPACE ;
2025-11-27 22:24:46 <veltas      > : test 1 2 3 ; test  leaves 1 2 3 0 on the stack somehow
2025-11-27 22:25:00 <isene       > It isn't broken. I decided to clean up SimplicityOS by explicitly not following the Forth conventions that I find ugly or inconsistent - like commands autoprinting, handling of strings, etc. Commands can only output to stack - so you need to do "words ."
2025-11-27 22:25:14 <veltas      > Scrolling is broken
2025-11-27 22:25:24 <veltas      > My bad
2025-11-27 22:25:50 <isene       > Also, there is no breaking or RPN - no prefix ugliness - like "see dup"
2025-11-27 22:26:07 <isene       > No scrolling yet
2025-11-27 22:26:44 <isene       > ...so it is "dup ? ."