I don't think there is anything that a different language here is going to accomplish that a library couldn't, it seems like the main advantage is the environment that allows for more fluid iteration combined with functions for audio.
Not the author, but I'll give my take on this. The Soundpipe library underlying Sporth is ideally suited to doing exactly what you describe. It exports all the required functions in a way that can be easily integrated with any extensible language. So if you want to make a library-for-X version of this, everything is set up for you. Sporth can basically be considered a minimal demonstration of this ability. This minimalism is also one of Sporth's strengths - it made it very easy to port to WebAssembly, for example.
Also consider that Sporth is almost like a markup language for audio graphs, where each occurrence of a verb represents a node in the graph. The graph is then initialized and run with minimal overhead over all samples. It's certainly possible to reproduce this in a library, but I suspect it limits your options in terms of target languages.
> it seems like the main advantage is the environment that allows for more fluid iteration combined with functions for audio.
That's exactly right. Having a terse and precise notation for expressing a patch was originally why it was created. There are indeed lower level libraries in other languages powering this (Soundpipe), but I found working in C to be too slow for creative working. Sporth eliminated some of those keystrokes and enabled me to compose music I wouldn't have been able to do otherwise [0].
They are great as well! Especially Csound. That's where I started. In fact, Sporth uses a lot of DSP code adapted from Csound.
From a language/syntax standpoint, you're still typing way more keystrokes with Csound to do equivalent things in Sporth.
Design philosophies are different as well. Csound is divided up into an orchestra/score, where the orchestra defines the signal flow of an instrument, and the score has instructions on when to play the instruments. Sporth can only define a sound in terms of signal flow, similar to a modular synthesizer. In Csound terms, it's the equivalent of having a single Csound instrument that is always on.
Performance-wise, I've found that Csound has a slight edge, but not by that much. Both are mainly written in C, and both perform quite well in real-time. I use low-end hardware, and I almost never have any issues myself. I wouldn't recommend sporth for embedded systems at all, and to be careful when using it on a raspberry pi 1 (but I said the same thing about Csound too).
From a code infrastructure standpoint, Sporth is way cleaner. And this is mainly what motivated me to write Soundpipe + Sporth, and the biggest strength. It's a very tiny language... the core of it is only a few thousand lines of reasonably C code, with the rest of it being ugen code, which is repetitive and easy to understand. It is built inside of a POSIX environment using simple Makefiles. Sporth code is pretty portable, and can be trivially dropped into a project (AudioKit does exactly this). Csound, on the other hand, is a massive code base full of very cryptic legacy C code, with bits of C++ thrown in for good measure, and uses CMake.
Csound has an amazing collection of opcodes for creating sounds. It's an amazing ecosystem to explore. Sporth has 224 unit generators, which is a lot, but a fraction of what Csound has to offer.
