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)
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.it's a huuuuuuuuge amount of technology in the standard library of mathematica, beyond the surface syntax and rewrite system, i mean.
All the best to the author, they definitely have fun doing this, but I've seen enough of such attempts. Having agents doesn't make much difference.
SPSS is hilariously painful to use. Still it's only losing ground ever so slowly. PSPP remains almost unheard of among SPSS core users.
And it failed at this.
However, I switched to Python during the last years.
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.
(AFAIK, you can run Mathematica sessions in TeXmacs, get proper typesetting, and can copy/paste expressions for simplification by hand or using other CAS sessions in the same TeXmacs document).
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.
https://writings.stephenwolfram.com/2013/02/what-should-we-c...
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.
How close is it to being able to run rubi: https://rulebasedintegration.org/?
Just like Python or any other language that looks easy for the learning examples, there are still hairy bits, they're just better hidden. The difference is that the debuggers for Python are far better.
Mathematica is great for quick stuff, but once you hit a particular level complexity it goes crazy. In this regard I find it similar to Bash.
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}
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)
- …
So not only do you have a closed loop system that has objective/automatic pass-fail criteria you also don't even have to supply the instructions about what the function is supposed to do or the test cases!
Obviously this isn't going to be 100% reliable (especially for edge cases) but you should be able to get an enormous speed up. And in many cases you should be able to supply the edge case tests and have the LLM fix it.
(Codex is still free for the next few days if you want to try their "High"/"Extra high" thinking models)
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.
I'm not claiming AI-written and human-reviewed code is necessarily bad, just that the claim that reviewing code is equivalent to writing it yourself does not match my experience at all.
I find people do argue a lot about "if it is reviewed it is the same" which might be easy when you start but I think the allure of just glancing going "it makes sense" and hammering on is super high and hard to resist.
We are still early into the use of these tools so perhaps best practices will need to be adjusted with these tools in mind. At the moment it seems to be a bit of a crap shoot to me.
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.