I tried out numerous audio tagging apps (Kid3, Picard, …) and wasn't happy with any of them. They all try to work with some kind of library system of have a really bad UX (single line input for Lyrics???).
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?
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.
I'm not a PL expert but isn't building a decent JIT a massive undertaking? I guess you're saying that the JIT itself would be what makes a project like this worth using in the first place?
It's like most things in software, if you constrain the problem enough, focus on the problems you actually have and make some smart choices early on, it can be a very modest lift on the order of a week or two for a 90% solution, but on the other end of the spectrum, it's a lifetime of work for a team of hundreds...
Most humans like external validation. Having other people use what they've built is a common metric of validation in open source software. Economically, these metrics can be used as credentials for things like job applications or consideration in joining groups.
Such a massive undertaking would be almost impossible without AI agents, so yeah, they help me. But with around 5000 tests, they are actually helping to improve the software quality!
Reviewing the correctness of code is a lot harder than writing correct code, in my experience. Especially when the code given looks correct on an initial glance, and leads you into faulty assumptions you would not have made otherwise.
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.
Plus if you look at the commit cadence there is a lot of commits like 5-10 minutes a part in places that add new functionality (which I realize doesn't mean they were "written" in that time)
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.
You wrote: “If they hand wrote the code we know they at least looked at it once.”
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.
> 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).
Sure, but you've got to start somewhere! And with the amount of progress I was able to make in just a few weeks, I'm very optimistic that the polish will come sooner rather than later.
Based on the list of contributors to your project, I am not sure this starting location is optimally suited to the task of building a foundation for polished, reliable, expandable software.
I have no dog in this fight, but simply claiming a count of tests get you anything is like saying your code coverage is 100% - it sounds really good until you think about what 5000 unreviewed tests actually... do.
If I go by the contributor numbers on Github, I see Claude has committed something on the order of 300,000 lines of code. I don't think it's reasonable to review that much code, even in weeks worth of time.
I haven’t needed to do such a thing in a while, but my “rule” for explaining how unreasonable is to say “if I only glanced at each line of code for 1 second, without bothering to understand the details, it would take me 3 and a half full 24hr days non stop to simply look at”. So it’s definitely more than 1 work week because presumably other stuff is going to need to get done in that time too. Actually understanding it is going to be at least a multiple of that, and probably the multiple is ~30x.
It's a defense mechanism. I was guilty as charge as well initially. Suddenly most of your l33t skillz are trivialized and surpassed by an inhumane actor. It's a tough pill to swallow.
i'm curious if you intend to reimplement highly optimized numerical algorithms, symbolic algorithms, and so on, accumulated and tuned in mathematica since its 1988 release?
it's a huuuuuuuuge amount of technology in the standard library of mathematica, beyond the surface syntax and rewrite system, i mean.
