This is a bit of a dead horse I trot out from time to time, but… the most core, important functionality in sclang is built on top of a VERY feature rich language with a handful of very specific syntax choices.
In it’s time it was a monumental achievement. 20 years later it’s looking very dated. Not surprising because those 20 years turned out to be the richest period for programming language innovation ever.
The SynthDef DSL, the pattern and event systems, array operations, functional programming techniques like composition, heavy use of lambdas / closures, predictable-pause garbage collection - ALL require this feature set.
Disagree. Some of these things are done poorly in SuperCollider (lambdas/closures, ‘macros’, patterns), and there’s much better support for them in other languages. There’s nothing terribly unique about SCs events (and they’re easy enough to implement in languages that don’t offer them).
Predictable pause garbage collection hasn’t been relevant for scheduling in a long time. Even in audio programming you can push the CPU surprisingly far before it becomes a problem on platforms like the JVM. Realistically any modern computer is fast enough that this will not be a problem, unless you’re doing something very weird.
Array operation is the only one, and while it’s nice, it’s hardly essential.
In contrast these are the things that SC_Lang doesn’t have. A good macro system. Dynamic compilation. Good functional syntax and libraries. Namespaces (my god, namespaces). Support for decent abstractions (Haskell). Good multi-tasking/synchronization/parallization primitives. Good error handling.
It also doesn’t have access to a large library ecosystem, so it’s missing out on robust libraries for all kinds of stuff (immutable data libraries, powerful libraries for list/array processing, network stuff, access to C/C++ libraries through CFFIs, true multi-threading, parser libraries).
There are no other mainstream languages that have the right features to enable these things - at best, you’ll get about 75% of the right things and with more frustrating syntax.
As someone who mostly programs in other languages I find SuperCollider’s syntax pretty frustrating and verbose, so to some degree this is a matter of taste. I really hate how functions are handled in SuperCollider, and I think the pattern libraries syntax is kind of a hack. It’s also not a hugely consistent language in ways that I find frustrating. It reminds me, obliquely, of JavaScript. Better than it seems on the surface, but far from perfect.
I use the Common Lisp front end and it does more than SCLang, and in my opinion better (the pattern library is more consistent and logical, I have more flexibility when defining synths and the LISP libraries offer a lot of functionality that I miss in SCLang). It also allows me to recompile classes without restarting my environment, and it has really nice error handling. On top of that I was able to write my own minilanguages for notation and Tidal stuff very easily.
The Haskell front end is similarly complete, and I have no doubt that one could write front ends in other languages that were similar. Most of what SCLang offers is baked into most languages - the layer that provides access to the server is surprisingly thin.
As much as sclang is a hot mess (it definitely is), the nearest contender in terms of functionality is Lua
This is simply not true. Not even close to being true.
I’d say that the closest language in spirit to SCLang that offers similar (well more, really) functionality is Elixir. A weakly typed functional language, inspired by Ruby, that runs on the BEAM JVM and which has a very good macro library. Really, what’s not to love 
Actors are first class and baked into the language, and it has a very sweet FFI.
Sad fact is: the options are either commit to sclang, or rewrite portions of the class library in another language with the knowledge that you’d be trading up on tooling/support/documentation/etc.
I think there are three arguments in favor of SCLang:
- Legacy: There’s a lot of code written in it.
- Coherence: The community are (mostly) talking in the same language, the teaching resources all speak the same language. SuperCollider is a small community, further fragmentation is bad.
- New Users: It’s good that you can point new users to a single IDE/language, and SuperCollider is pretty quick to get up and running and making a sound. And when they look for help, it’s all going to be relevant to them.
There are three arguments against it:
- It’s set in aspic: It takes a huge amount of developer man hours to improve and maintain a language, and that just doesn’t exist for sc_lang (plus language design is really hard). The SCLang of today (JIT, syntax, all of it) will be the SCLang of tomorrow. As time goes on it will seem more and more dated, and more alienating to users (the CSound problem).
- Libraries: The community is too small and focused to create high quality libraries for things that people take for granted today. For better, or worse, if its not in the language then you’re not going to get a reliable library for it.
- Performance: SCLang is already a slow language, and has the state of the art develops it will be (relative to other languages) an even slower one.
I don’t know there’s really a solution to this other than the entire community commiting to a new language (Elixir - come on people, you know you want to), which I think is very unlikely to happen. So I suspect what will happen is the same as today. People like myself who get frustrated move to a different language, and thus fragment the ecosystem. Some new people bounce because they dislike the language, never realizing that there are alternatives. And people who continue to use the language grumble more and more that it doesn’t do the things that they take for granted in other languages.
