upvote
I noticed the same thing, having also written an interpreter for the Wolfram language that focused on the core rule/rewriting/pattern language. At its heart it’s more or less a Lisp-like language where the core can be quite small and a lot of the functionality built via pattern matching and rewriting atop that. Aside from the sheer scale of WL, I ended up setting aside my experiments replicating it when I did performance comparisons and realized how challenging it would be to not just match WL in functionality but performance.

Woxi reminds me of some experiments I did to see how far vibe coding could get me on similar math and symbolic reasoning tools. It seems like unless you explicitly and very actively force a design with a small core, the models tend towards building out a lot of complex, hard-coded logic that ultimately is hard to tune, maintain, or reason about in terms of correctness.

Interesting exercise with woxi in terms of what vibe coding can produce. Not sure about the WL implementation though.

(For context, I write compiler/interpreter tools for a living - have been for a couple decades)

reply
I’ve personally had luck at correcting the complex one-off logic the agents produce with the right prompting.

and when I say prompting, I just mean code review feedback. All of this is engineering management. I review code. I’ll point out architectural flaws if they matter and I use judgement to determine if they matter. Code debt is a choice, and you can afford it in some situations but not others. We don’t nit over style because we have a linter. Better documentation results in better contribution quality. etc.

Agent coordination? Gastown? All I hear is organizational design and cybernetics

reply
Mh, I thought about this a little and came actually to exactly the opposite conclusion: Implement as much as possible in Rust to get the fastest code possible. Do you have any more insights why this should not be possible / unsustainable?
reply
You have two distinct products 1) An interpreter 2) a math language. Don't write your math in some funny imperative computer language.

Keep the interpreters surface area as small as possible. Do some work to make sure you can accelerate numeric, and JIT/compile functions down to something as close to native as you can.

Wolfram, and Taliesin Beynon have both said Wolfram were working internally to get a JIT working in the interpreter loop. Keep the core small, and do that now while it's easy.

Also, it's just easier to write in Mathematica. It's probably 10x smaller than the rust code:

    f[x_Integer]:=13*x;
    f::help:="Multiplies x by 13, in case you needed an easy function for that."
EDIT: Another important thing to note is the people who really deeply know specific subjects in math won't be the best, or even good rust programmers. So letting them program in woxilang will give the an opportunity to contribute which they wouldn't have had otherwise.
reply
Symbolic manipulation?
reply
Switching out to an interpreted language has got to be anathema to a rewrite-it-in-Rust project
reply
implementing addition in woxilang itself?? this gotta be terribly slow. am i missing something?
reply
Mathematica has symbolic and infinite-precision addition, so you can't automatically take advantage of obvious compiled code.
reply
What? Arbitrary precision arithmetic implemented in a compiled language will be faster than the alternative. This is no great mystery. The same is true of essentially all low-level symbolic or numerical math algorithms. You need to get to a fairly high level before this stops being true.
reply
You are missing the term "JIT", which would enable a host of runtime optimizations which include generating calls to some static piece of native code which performs addition.
reply