Yes! With or without any quark you can start scsynth or supernova from the command line and communicate with them however you like.
But if there is no sclang or SC-IDE, then developer focus would change. So I donāt think we can quite extrapolate from the current situation with editors such as atom that are not officially supported. If one of those is the official IDE, then we would have to make it just work.
This is true, but itās a lot easier to support a plugin for VSCode, than to support an entire IDE.
This is the direction Rust has gone in where they provide a VSCode plugin which is the default for the community and this (mostly) works.
Personally I think at this point it probably makes sense to make the IDE and language legacy. Modernizing those would be a huge endeavour and would likely result in something mediocre in comparison to the tools/languages people are used to. The developer tool/language landscape of 2021 is completely different to that of the early 2000s. Choices that made sense then donāt really make sense now. Maintaining a language is a huge endeavour.
What I would like would be if the server was completely independent and modular. So if I want to embed it in a piece of software there is a clear C API (much like CSound) that I can use. If I want to set it up as a server there is a way for me to not only communicate through OSC, but also MIDI. And it should be possible to use the server in a standalone fashion, which would mean limited scripting (maybe LUA) in the server.
And then if you want an out of the box solution you could provide something (including libraries) that worked well with either a common language (e.g. Ruby/Python/JavaScript), or a good language (Elixir, or some kind of LISP) thatās not too complex (I love Haskell, but good god thatās going to be a tough sell for most people). And then you could port over the good parts of the SuperCollider ecosystem, and provide a decent VSCode plugin.
For me the ideal language would be one with good soft real-time performance, with macros, decent support for functional programming and something OOP like. You absolutely want some kind of REPL/ability to code dynamically. Namespaces. Package management. Multi-threading also seems important.
A few thoughts:
-
Typing: I can understand why some people would prefer a static/strongly-typed system, but there are two very compelling reasons why I moving to such as system in SC would be a bad idea (and I suspect they are at least partially behind why we have the type system that we do):
A. Strongly typed systems are confusing to programming newbies. Remember that a lot of people come to SC from a music, not CS background.Strongly/statically typed languages may make it easier to build large systems, but they are also potentially more confusing to people who have never written code before.
B. At this point, changing to a strongly/statically typed system would break literally every piece of SC code in existence.
While thereās some discussion about making they type system optional, wouldnāt that be a pretty monumental undertaking from a dev standpoint? -
IDE: I personally really like the SC IDE, but beyond that, thereās also the newbie issue. Experienced programmers all have their favorite IDE/editor, but what about people who havenāt written code before or who donāt code outside of SC? It seems a bit much to expect someone to learn Emacs or vi on top of learning SC itself. And I say this as someone who does use Emacs for non-SC tasks.
1 Like
As mentioned earlier, over the years, I have witnessed many attempts to bring up something like SC4. All of them evaporated.
The endeavor to achieve something that is only nearly as powerful and versatile as SC3 is today (despite all its flaws) would be enormous, and I think that most people underestimate the required work and expertise. Even if all these factors would be there: thereās the social component of software development that makes such an effort unsure. As projects like SC, Pd, ChucK, and others show: at first, it needs an outstandingly competent and visionary personality behind it.
I also think that focussing on some of its limitations shadows the possibilities within the current version of SC. What to get out of it is primarily a function of time, effort, and reflection the user is putting into it. In many cases, itās a mind trap to think that creative work would be easy if only this and that additional feature would be there.
For all these reasons, Iād strongly favor improving SC3 as it is ā including the language ā but without destroying this fantastic heritage, i.e., without changes that break existing code. Sure, if people would start developing other clients in addition, fine.
But in my view, repairing some server issues would be an even more urgent task. E.g., there exist many eternal UGen bugs. The SC community doesnāt have enough DSP experts as developers who are volunteering to tackle them. Thatās not to blame anybody, but think about it: if this is the reality, how could you expect something like a Super-SC to come into being ā even more, if thereās no clear consensus on what this Super-SC should include.
6 Likes
Of editors:
Hmmmmā¦ Butā¦ my point was exactly suggesting to completely drop SC-IDE and replace it with a plugin for a different editor. So I donāt understand the use of ābutā here 
Emacs or vi would be terrible choices for a default editor (speaking here as someone whose mind would melt into a pile of steaming jelly without emacs org-mode)ā¦ but they are not the only choices.
Significant point:
These may be a bit at odds though: If we want step debugging, that takes developer hours away from fixing DSP bugs.
The point about a visionary leader is well taken.
hjh
itās called Scala
IDE: I personally really like the SC IDE, but beyond that, thereās also the newbie issue. Experienced programmers all have their favorite IDE/editor, but what about people who havenāt written code before or who donāt code outside of SC? It seems a bit much to expect someone to learn Emacs or vi on top of learning SC itself. And I say this as someone who does use Emacs for non-SC tasks.
VSCode is newbie friendly. Atom could also be made newbie friendly with the right plugins.
I donāt have a problem with the SuperCollider IDE, but I think unless a new developer comes along with an interest in extending it (or even supporting it), itās not going to evolve much at this point. A lot of work.
It runs on the JVM and has bad soft RT performance unfortunately (though I would pick Clojure personallyā¦).
I was kind of stacking the deck towards Elixir though if Iām being honest 
Thatās a myth from the 1990s. JVM is one of the most performative platforms out there, and Hotspot has a whole range of garbage collectors including some with very minimal pauses, so definitely a platform for soft real-time. You can also run Scala on a JS engine (node or browser), and there is experimental compilation to native, although Graal is new thing to do near-native (avoid JIT) things.
The idea that only stuff compiled to native code will be ready for real-time is outdated.
Edit: huh, Elixir runs on the Erlang virtual machine. 
On IDE and languages.
I agree that of course a specialised IDE can be advantageous for teaching, learning etc. Thatās why Arduino and Processing managed to get a following. But certainly the integrating with something like VS Code has a lot of other advantages. The main one being that you need to concentrate your resources really just on the language integration, and no need to reinvent the wheel from scratch. Microsoft did a real power move with the introduction of the LSP protocol. As far as my knowledge about this goes, this really allows a gradual implementation of language support. You donāt need to start of with a fully-fledged system, but you can step by step implement the features the IDE can support for your language.
I donāt believe a statically typed language is a major hurdle for adoption by people without programming background. Show me the study that proves people are significantly better learning and using a dynamically typed language. You anyway have to introduce types, you have to learn which class of objects understands which kind of messages. I think something like cooperative multi-tasking, that sclang uses (or JavaScript), have a much greater role in reducing the complexity for beginners, than the question of whether types get checked āfirstā or āat runtimeā, the boundary of which diminishes as you add a REPL/interpreter. Some type disciplines like OCamlās or Haskellās donāt even require that you annotate function parameters with types.
1 Like
I am concerned that without an IDE and a double click to install experience, SC will move further away from approachability for new users. SC as something more approachable for new users is something I think about a lot. Itād really be a shame to see SC move backwards on this issue.
5 Likes
Also, pardon my ignorance here, but since the IDE is already built - unless there are major changes to QT, isnāt having the IDE at this point largely about maintenance and incremental improvements? The heavy lift has already been done.
1 Like
Soft Realtime isnāt about performance, but the ability to guarantee that certain bits of code will always be run and also provide guarantees that they will be run when you say they should be. BEAM (the Erland VM) does make this guarantee, despite not being as performant as JVM in the average case. AFAIK there isnāt a JVM that can provide that guarantee, though certainly the JVM performs better than Python, Ruby, or JavaScript in this regard.
The BEAM is an astonishing piece of engineering, and Elixir is a nice dynamic language built on top of it. Iām well aware itās fairly non-mainstream, but I do honestly think it would be an excellent language for a lot of the stuff people use SCLang for atm. IMHO itās the perfect language for controlling installations, or anything distributed across a network. Elixir is sort of like Ruby, if you made Ruby functional. And it was reasonably performant.
In reality you donāt need to even need to tune this, a JDK 11 on a contemporary computer doesnāt produce GC that will create problems. Otherwise, use Z Garbage Collector.
You pretty quickly hit some limitations if you donāt understand the type system in Haskell/OCaml - and good luck teaching that to someone who really doesnāt care about programming.
Even something like Rust (which has a nice flexible type system, and avoids the complexity of HKTs and the like) is difficult even for experienced programmers to get to grips with. And if you have something less sophisticated than Rust, and you pretty quickly end up with a very annoying and verbose type system (hello Java).
My personal preference is for typed languages - love Rust and Haskell. But god knows, those are tough languages for newbies.
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