00:20:10
##forth
<anthk_>
got muxleq' eforth running the bundled sokoban
00:20:47
##forth
<anthk_>
I know sokoban.fs exists too, but I was just having fun
09:03:24
##forth
<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
09:03:46
##forth
<veltas>
At 64-bit DTC just doesn't seem worth it
09:06:37
##forth
<veltas>
With a 2 instruction NEXT you'd usually inline it (or make it a macro rather than jump in asm)
09:07:26
##forth
<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
09:11:10
##forth
<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
09:11:56
##forth
<veltas>
There's multiple calling conventions as a result, some functions are C-style using call's and some are using Forth's conventions
09:12:09
##forth
<veltas>
So you can't use the C-style stuff without a shim
09:13:48
##forth
<veltas>
I'm not seeing a dictionary
09:15:38
##forth
<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
09:20:47
##forth
<veltas>
The code does actually run and allow that session but I don't really understand where the dictionary comes from
09:20:54
##forth
<veltas>
Not a lot of error handling
09:40:42
##forth
<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
09:40:57
##forth
<veltas>
But not a proper listing of how you've allocated them for anyone writing assembly words
09:46:10
##forth
<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
09:46:40
##forth
<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'
09:47:29
##forth
<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
09:47:53
##forth
<veltas>
So I'm not really surprised if claude can write one
09:48:32
##forth
<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"
09:51:23
##forth
<veltas>
Looking at the transcript, it feels like the code doesn't really match the 'vision' that Claude talks beautifully about at the start
09:54:14
##forth
<veltas>
It's mentioned that the assembly is heavily commented, but personally I didn't find most of the comments helpful
09:56:10
##forth
<veltas>
I think I'd be more interested to see how this project *matures* with continued use, and to solve actual problems.
09:58:10
##forth
<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
09:58:56
##forth
<veltas>
The big question is how it deals with increasing complexity of the architecture, and technical debt building up
14:51:02
##forth
<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.
15:06:52
##forth
<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?
15:08:02
##forth
<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
15:26:22
##forth
<isene>
I actually did pass it straight to CC and it answered this:
15:26:54
##forth
<isene>
● Excellent, honest technical feedback! Let me analyze each point:
15:26:56
##forth
<isene>
Technical Critiques (Valid)
15:26:58
##forth
<isene>
vdupras:
15:27:00
##forth
<isene>
- "5 zeros!" - My comment, not copied code
15:27:02
##forth
<isene>
- Big table vs jumps - Fair, less efficient
15:27:04
##forth
<isene>
- "No human could come up with .try_swap" - Amusing
15:27:06
##forth
<isene>
- "Pretty bad code" - Harsh but technical honesty
15:27:08
##forth
<isene>
veltas's detailed review:
15:27:10
##forth
<isene>
Architecture:
15:27:12
##forth
<isene>
- 64-bit DTC unusual/inefficient - Could use token threading
15:27:14
##forth
<isene>
- No TOS register - Would be faster with cached top-of-stack
15:27:16
##forth
<isene>
- Mixed calling conventions - C-style + Forth style = messy
15:27:18
##forth
<isene>
- Register allocation undocumented - Should document R15, RBP, etc.
15:27:20
##forth
<isene>
Code Quality:
15:27:22
##forth
<isene>
- Printing in asm vs Forth - Should be Forth words
15:27:24
##forth
<isene>
- Redundant functions (word_cr) - True
15:27:26
##forth
<isene>
- Didn't 'think', just 'finished' - Ouch but fair critique
15:27:28
##forth
<isene>
- Comments not helpful - Should explain WHY not WHAT
15:27:30
##forth
<isene>
Big Questions:
15:27:32
##forth
<isene>
- Code doesn't match vision - Haven't done DEVICE-* yet
15:27:34
##forth
<isene>
- How does it mature? - Technical debt management
15:27:36
##forth
<isene>
- Use for real problems - Needs proof
15:27:38
##forth
<isene>
- Complexity handling - Key concern
15:27:40
##forth
<isene>
And then it went on with how it would plan to tackle every point.
15:32:20
##forth
<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.
15:33:06
##forth
<KipIngram>
I've mostly withdrawn from "intellectual" communities, because the prevailing culture is practically always judgmental and negative.
15:33:16
##forth
<KipIngram>
Rather than helpful and encouraging.
15:33:59
##forth
<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.
15:41:20
##forth
<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"
15:43:36
##forth
<veltas>
If Claude knows not to write WHAT instead of WHY comments then why did it write them lol
15:44:03
##forth
<veltas>
I guess because it doesn't 'know' anything and it's a black box of smoke and mirrors
15:45:03
##forth
<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)
15:49:52
##forth
<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
15:53:15
##forth
<isene>
Yeah, I did snip the CC response to match your feedback size. Here's a bit more:
15:53:38
##forth
<isene>
The feedback is a gift. It's honest technical review from experienced developers.
15:53:40
##forth
<isene>
What they're really asking:
15:53:42
##forth
<isene>
1. Will this architecture scale or collapse under complexity?
15:53:44
##forth
<isene>
2. Is the pure object model robust for real use?
15:53:46
##forth
<isene>
3. Can you actually build DEVICE-* on this foundation?
15:53:48
##forth
<isene>
To prove the model:
15:53:50
##forth
<isene>
- Implement DEVICE-* (original vision)
15:53:52
##forth
<isene>
- Use for real problems (demos/challenges)
15:53:54
##forth
<isene>
- Document conventions properly
15:53:56
##forth
<isene>
- Show it can mature without becoming spaghetti
15:53:58
##forth
<isene>
The pure object model we just added addresses some concerns (scalability, consistency).
15:54:00
##forth
<isene>
Next steps to validate:
15:54:02
##forth
<isene>
1. Implement SCREEN following DEVICE-* pattern
15:54:04
##forth
<isene>
2. Build something real with it
15:54:06
##forth
<isene>
3. Show the architecture holds up
15:54:12
##forth
<isene>
I did iterate a few times and will commit the result soon. Stay tuned in the repo
15:55:46
##forth
<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"
15:57:56
##forth
<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.
16:03:01
##forth
<veltas>
Yeah I will check that out later isene
16:08:29
##forth
<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
16:08:31
##forth
<isene>
through the past 30+ years, But this is about researching the opportunities and limitations of AI in coding.
16:09:05
##forth
<veltas>
Don't mix me and vdupras up by the way :P
16:09:47
##forth
<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
16:10:12
##forth
<veltas>
I'm definitely sceptical, especially after reading the code, because there is a lot of strange unexplained stuff in there
16:10:49
##forth
<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
16:11:44
##forth
<isene>
ah, a slight hit of "dyslexia" over the two nicks. Sorry about that.
16:13:30
##forth
<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
16:13:47
##forth
<veltas>
So I could never tell them apart
16:13:50
##forth
<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.
16:14:16
##forth
<isene>
veltas: Yeah, in my weechat here you are both purple. Dosn't really help
21:29:16
##forth
<veltas>
isene: I like your website, and XRPN
21:44:47
##forth
<veltas>
Oh by the way I think XCHG is actually really bad on some older chipsets like some of the atom processors
21:44:55
##forth
<veltas>
Although maybe not any 64-bit wide ones?
21:46:17
##forth
<veltas>
But yeah I'm not sure XCHG is always more efficient, better use of space though maybe
21:50:23
##forth
<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
22:17:14
##forth
<isene>
veltas: Thanks for the input, appreciated.
22:20:41
##forth
<veltas>
Dot would usually print a blank after so you can do 1 2 3 . . . and get "3 2 1 "
22:21:00
##forth
<veltas>
I mean it doesn't have to but would usually, it's your Forth
22:21:30
##forth
<veltas>
Looks like `words` is broken on latest commit
22:23:34
##forth
<KipIngram>
I've often seen (.) print with no space, and then : . (.) SPACE ;
22:24:46
##forth
<veltas>
: test 1 2 3 ; test leaves 1 2 3 0 on the stack somehow
22:25:00
##forth
<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 ."
22:25:14
##forth
<veltas>
Scrolling is broken
22:25:24
##forth
<veltas>
My bad
22:25:50
##forth
<isene>
Also, there is no breaking or RPN - no prefix ugliness - like "see dup"
22:26:07
##forth
<isene>
No scrolling yet
22:26:44
##forth
<isene>
...so it is "dup ? ."