There is an architectural flaw in Woxi that will sink it hard. Looking through the codebase things like polynomials are implemented in the rust code, not in woxilang. This will kill you long term.
The right approach is to have a tiny core interpreter, maybe go to JIT at some point if you can figure that out. Then implement all the functionality in woxilang itself. That means addition and subtraction, calculus, etc are term rewriting rules written in woxilang, not rust code.
This frees you up in the interpreter. Any improvements you make there will immediately show up over the entire language. It's also a better language to implement symbolic math in than rust.
It also means contributors only need to know one language: woxilang. No need to split between rust and woxilang.
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)
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
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.Is it not that Mathematica, and most of the Wolfram innovation, is about a smart way of applying some rule-based inference. I think of it as parametrized PROLOG rules, with large lib. So term rewriting all the way to the end, correct me if I'm wrong.
Where does the mini-core+JIT come into this?
Thanks for taking time to answer.
it's a huuuuuuuuge amount of technology in the standard library of mathematica, beyond the surface syntax and rewrite system, i mean.
SPSS is hilariously painful to use. Still it's only losing ground ever so slowly. PSPP remains almost unheard of among SPSS core users.
Now Mathematica notebooks (still remember, it is .nb) do not have the novelty factor. But they were the first to set a trend, which we now take for granted.
That said, I rarely use notebooks anymore. In the coding time, it is much easier to create scripts and ask to create a visualization in HTML.
Mathematica's notebooks are the only environment where I can do some computation to arrive at a symbolic expression. Copy the expression from the output cell into a new input cell. Then manipulate it by hand into the form I want. Then continue processing it further.
Also, symbolic expressions can be written nicely with actual superscripts and subscripts, and with non-latin characters.
One of the best features of Mathematica system.
From a purely programming language theory, it's pretty unique.
I once tried to find a language that had all the same properties, and I failed. The Factor language is probably the closest. But they are still pretty different.
It's a worthwhile effort. If successful, Woxi can enable a large mass of scientists and engineers who don't have access to Mathematica to run legacy code written for it. Also, Woxi would give those scientists and engineers who regularly use Mathematica a non-proprietary, less restrictive alternative, which many of them would welcome.
How does Woxi compare to other "clean-room implementations"[a] of the same language?
--
[a] Please check with a lawyer to make sure you won't run into legal or copyright issues.
I'm not sure how important but- for-bug identical output really is.
How close is it to being able to run rubi: https://rulebasedintegration.org/?
Better license? Allowed for commercial operations?
- Faster startup time because of no license check
- Can run multiple instances of Woxi at the same time
- Embeddable via WASM
- Configurable via compile time flags (which features should be included)
- …
Here is e.g. all the values for the Plus[] function:
$ wolframscript -code 'WolframLanguageData["Plus", "Ranks"]' {All -> 6, StackExchange -> 8, TypicalNotebookInputs -> 5, TypicalProductionCode -> 6, WolframAlphaCodebase -> 6, WolframDemonstrations -> 4, WolframDocumentation -> 4}
An ai based development workflow with a concrete oracle works very well. You still need the research and planing to solve things in a scalable way, but it solves the "are the tests correct" issue.
What we've done is pull out failing property tests as a unit tests, makes regression testing during the agentic coding loop much more efficient.
If you have Mathematica installed you can write CLI scripts and notebooks.
what's stopping some Mathematica employee from taking the source code and having an agent port it. Or even reconstruction from the manual. Who owns an algorithm?
Will everything get copied eventually?
Laws against theft. Also the same reason employees don't release the code on pastebin or something.
> Who owns an algorithm?
The org or person who was granted the software patent. https://en.wikipedia.org/wiki/Software_patent
> Will everything get copied eventually?
If we're lucky. More likely everything bitrots as technical capabilities are lost. Slowly at first, then quickly.