Rust and Haskell are entirely different languages. Rust doesn’t even have automatic memory management. I don’t think anyone would suggest using that as a user-facing language for a computer music system.
I’m just talking about the type system. Rust has a simplified version of the Haskell type system - but I find even with that it takes reasonably experienced programmers quite a while to wrap their head around it.
Leaving it here. As always, and as said before, you won’t find the language that everyone loves. Like if you love parentheses and lisp, sure, and if not, sure too.
3 Likes
Fair enough. It’s less about languages that people love, and more picking the right tool for the job. Sometimes that might be the JVM and Scala, sometimes it might be C++. For new programmers, particularly those who don’t particularly want to program, Python is by far the most successfully learnt/adopted language followed by Ruby. Personally I will pick a language with a Hindley-Milner type system if I given the option. But I’ve helped enough experienced programmers with Haskell and Rust to know that Hindley-Milner type systems aren’t easy even for them to pick up.
The JVM is an outstanding piece of engineering that has been designed to handle heavy synchronous loads on a server with plenty of resources. To achieve this they have had to make a number of compromises (no shade - engineering is all about compromises) - and those compromises mean that it’s less than ideal for either desktop applications (though no worse probably than the new standard - the V8 engine), and not at all suitable for highly concurrent and distributed applications that require soft-RT (which is about more than just the GC), or situations where memory is at a premium. None of this really matters for the current SuperCollider language if you’re not doing MIDI, as you have about 100 miliseconds of latency between you and the server - even Python/Ruby can manage that. So in a way I’m being a bit facetious. However something I’ve noticed over the years is that a lot of people trying to do Realtime stuff with SuperCollider for installations and run into problems. So an environment that just worked with that stuff (and my god - the BEAM JVM just works) would be very cool, and which could get down to control signal latency would be nice. While I’m dreaming I’d also like HKTs in Rust before the end of the year…
Being more serious I don’t think there really is a perfect language for SuperCollider. But if SClang didn’t exist I’d probably go with Python at this point - not because it’s ideal, but simply because it lowers barriers to adoption, a lot of your possible user base will already know it and it gives you the widest access to libraries, GUIs, scientific computing etc.
1 Like
I’d imagine the most learned/adopted language is JavaScript (and there’s TypeScript if you want types…) and JS has the advantage of running in browsers so there’s that…
see Gibber for a sc-like in-browser experience
(I am actually a fan of sclang but its the first and only language I’m ok at!)
1 Like
The slowest part of sclang BY FAR is the garbage collector. JVM’s realtime collector is likely to be an order of magnitude more efficient than sclang’s current Baker treadmill implementation, and would probably result in both better realtime guarantees AND better overall performance for the language.
There are already scsynth clients in other languages, as well as libraries for composition / event processing / etc - I don’t think any of these would really constitute a “SuperCollider 4” - but rather just “LuaCollider” or whatever. With a critical mass of development effort, I could imagine one of these could become sophisticated enough to transition the majority of the community to it, but I don’t know of any solutions that very close.
If “SuperCollider 4” has at least some continuity with CURRENT SuperCollider - e.g. it would be possible to transition some of the class library and port existing code, even if there wasn’t 100% backwards compatibility - the best possible path forward is using graalvm and truffle to build an sclang implementation against a JVM backend. The parser-compiler-interpreter part of this is probably not even a crazy-large amount of work (though it requires some programming language expertise that’s hard to come by…).
The much bigger chunk of work would be porting all of the existing primitives (many many hundreds?), which would need to be more or less rewritten from scratch. Because a JVM port of sclang would be actually-fast, it’s likely that almost all of the primitives could be rewritten directly in sclang code with no detriment to performance, which is of course pretty fantastic. But this is still a HUGE code surface area, and would probably require large scale community participation if it ever had a chance at being finished.
The upside here is that - if sclang was ported to JVM, it would have as good or better performance than most scripting languages (graal ports of languages tend to outperform their own VM’s). This would put it waaaaay out at the front of the pack of creative programming languages - if this vision of SuperCollider 4 actually succeeded, it probably would mean a HUGE expansion in the SC capabilities and community.
It’s a cool future to imagine… I guess we just need to find a programming language / VM expert and the funding to pay for a year or two of development costs so it actually gets finished. 
5 Likes
You’re probably right here - I think it’s possible to make a language that is both strongly typed and accessible for beginners. Processing is strongly typed, and is MUCH easier to learn for a newbie programmer than SC.
The problem is that SuperCollider / sclang, as it stands now, leans HEAVILY on it’s dynamic typing. For example, it’s very hard to imagine reproducing the features of the Event / Pattern system in a statically typed language. If you were to convert the implicit dependencies of this system into explicit interfaces that could be implemented by classes, I worry that it could result in a nightmarishly complex web of class / interface relationships…
A statically typed solution WOULD be useful and cool, but as per my previous comment - I’m not sure it we can call something “SuperCollider 4” if it ditches backwards compatibility and the majority of the concepts and patterns from SC3.
Why 4?
Revolutions allways fail. Rewrites are like revolutions (Perl 6?). Evolution is the way. If there’s something seriously wrong with what we have now, fix it. Re-evaluate and find the next bottleneck. Chain and weakest link et al. If there’s something superfuous, ignore it or delete it.
Using a general purpose language instead of a DSL will not work. Forget looking into other languages. Go to the butcher, look at his work shop. Go to the carpenter, look at the workshop. Go to the black smith … All very simmilar yet so different. Look at wood workers, making their own tools. Tools for their trade. Tools adapted to their habits. A cabinet makers plane is different from a table makers plane. These differences is what makes that you can’t hammer red hot steel in a butchers workshop.
In software, I use POV-Ray SDL, a DSL, a lot. It has its quircks. Looking at all the web 3d stuff in javascript is terrible. It is expressive is all the wrong ways. The same with Python layers over POV-Ray SDL. The same with python layers over the current SuperCollider. Or the other variants available.
So, what is the bottle neck that 4.0 solves?
4 Likes
A different way to look at it:
In programming, major version jumps (3 → 4) signify breaking changes - a lack of backwards compatibility. SuperCollider 4 means a SuperCollider where you may not be able to run your SC3 code, where you may need to rewrite some of it, or you may not get the same results.
Breaking backwards compatibility can be hugely disruptive for users - it has a cost. But, maintaining backwards compatibility is extraordinarily expensive for the development team, and makes certain kinds of changes so expensive or difficult that you can simply never do them at all. It’s expensive for users as well, because they may be stuck with archaic/old/weird/bad patterns that only exist because they are needed for compatibility. In this sense, a 4.0 can be less expensive than continuing to iterate on a 3.x - depending on what you want to achieve.
So, the question of a 4.0 is: if we’re going to incur the cost of a bunch of breaking changes to our code, what is the feature list that would be worth this cost?
2 Likes
There will always be old gits that prefer 1.5.2 
What I see in the discussion for example is using different languages. Splitting server side and client side “completely”. Different type systems, other VM’s etc.
Yet, even with significant changes, the first question imo still should be what are the real bottle necks? Does solving them need breaking changes? I can’t (and won’t) judge. If there are, go ahead. If it’s “just new chrome”, don’t.
The second question is for whom. The live coder, the casual user, the non real time user… Not every user group is as vocal, never forget the “silent majority”.
Some language-related feature requests are: stronger typing and step debugging.
Also there’s a known interpreter bug where try unwinds the stack incorrectly. (This is a very very nasty bug, unfixed for a couple years now, I think.)
AFAIK at present nobody in SC land knows enough about interpreter internals to address these.
Another way to address these problems would be to go to a language with some stronger typing features (though here scztt’s remarks about type flexibility in the pattern/event system are on point), and a step debugger, and where error handling “just works.”
Btw a glance at the elixir intro docs made me 
and 
hjh
Just adding my two cents: if we were to switch languages/VMs, it would be great if it had a simple C interface, so people can easily integrate existing libraries. Currently, sclang only allows extensions written in sclang itself and is therefore very limited. It’s been more than once that I’ve hit a wall…Pd, on the other hand, allows you to interface with virtually anything.
1 Like
On top of my own wishlist:
- Unify the callback mechanism by basing it entirely on Object:changed. (Rewrite NotificationCenter to use changed mechanism)
- Simplify Responder Class Hierarchy, Refactor/cleanup CmdPeriod, but also OSCFunc, MIDIFunc possibly basing it on the Object:changed mechanism
- Rewrite Server class, especially simplify it and get rid of many confusing variables and helper classes.
- Refactor default parent Event. Simplify (or entirely get rid of) nested functions for playing event in Pbind, delegating them to Classes, while retaining or rather enhancing flexibility of behavior.
- Incorporate an Event playing class which has access to its own keys while playing a stream and can stop and restart from the place in the streams where they stopped as well as modify the keys of its event while it is playing.
1 Like
Something else that struck me: someone suggested class namespaces, but what could be useful as well is a kind of distinction, either through a namespace or through some naming convention or some other mechanism, of what code is supposed to run server-side and what code is meant to be running language-side.
1 Like
My 2 cents: We’ve seen many such discussions over the years, but little consensus. As Scott points out, SomeOtherLangClientCollider has already happened more than once. Some of those live on, some have fizzled. To become a replacement, I think such a client would need to have significant advantages to both new and existing users. Otherwise SC3 would likely just continue and remain the primary concern with server development.
With that in mind Scott’s proposal here is one of the few I’ve seen that seems likely to have a real chance of success. I quite like the different angle!
1 Like
If we’re doing wish lists, one thing I’d like is to move the Node/Buffer/Bus allocators into the server. This would simplify a mountain of code and make multi-user situations much easier.
This wouldn’t have to wait for an SC4 though…
1 Like
I would really like to see the community organizing some crowdfunding to maintaning/test this idea. I honestly think this is a cool thing do at the present moment.
This also makes me think, aren’t we currently needing something like a foundation (like Processing and Blender have theirs) to organize, fund, support, promote etc SuperCollider ? Feasible ?
3 Likes
I wanted to know how the community felt about everything, and just what road is this heading towards… what goal, what end game.
SC4 is an inevitability… but there is still time to change the course of it’s destiny, I believe.
Crowdfunding is one manageable idea… if we can’t build ourselves to commit to the active development, we could contribute to the source of funding that would enable someone more experienced to do so, for us.
While payment can replace passion… if we’re going to pay someone to make a significant change, what we should be paying for, I believe, is a way to make passion a payment unto itself…
Hi there,
How many core developers are currently working on maintening Super Collider ?
I imagine its a lot of work to garanty SC stability, bug corrections, port it to new os and so on.
Then it could be a good thing to see SC supported by more institutions maybe in order to make the task easier to core dev. and give them space to make big changes, improvements… ?
Best,
Pragmatically – software maintenance is a lot of grunt work. Rewriting the interpreter for graalvm would bring benefits, but it isn’t glamorous or fun, and it’s more work than you’d think. In a perfect world, that work would be intrinsically rewarding but we don’t live in that world (and I’m also reminded of the way that capitalist ideology sometimes uses the idea of “intrinsic rewards” just to avoid facing the cost).
We have Qt GUIs and the IDE because a couple of programmers got a grant to fund their development – they could work basically full time on it for part of a year. Without that intensive effort, those projects could easily have simply not gotten off the ground. It’s hard to build momentum when you’re stealing a few hours a week for it.
I don’t think SC4 is inevitable. People have to do it, and have to have time to do it. Passion isn’t enough.
hjh
3 Likes