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."
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.
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
REDACTED
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B3
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}
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.
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.
(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).
It was Kernel that was most similar with the fexpr capability.
Pure is a good example too.
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.
https://writings.stephenwolfram.com/2013/02/what-should-we-c...
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)
And it failed at this.
However, I switched to Python during the last years.
// ∫ tan(x) dx = -ln|cos(x)| - not implemented (requires Log)
But that’s not true, because even if they did indeed hand-write the code, we as third parties wouldn’t have any reliable proof of that, and therefore still couldn’t draw the conclusion that they looked at the code.
Them claiming to have hand-written the code isn’t any better than them claiming to have thoroughly reviewed the code. We can’t know in either case.
It is better, because most people aren't out-right liars. If he said "I hand-wrote the code", sure it doesn't prove it, but I would believe him. When he says "I thoroughly reviewed the code"... yeah maybe. That's the sort of thing people do lie about (even to themselves).