Hi Sc iss, all,
Thanks for such a detailed reply. You outline many of the issues very well. I'd like to engage in a discussion on some of the points you raise, but I'm not sure to what extent this list should support this topic. I guess if anyone objects those of us who are interested can take it elsewhere. Failing that (objection)...
I'm sure you've acquainted w. the alternatives, but its good to get a 'type' perspective. On his blog site, Guido van Rossum has an item on Scala that has 30-odd replies which I found useful in getting a feel for the lay-of-the-land:
On 10 Mar 2009 04:42:33 +0100 (MET) Sciss wrote: ok, the general frame is my phd thesis which deals with the way we can approach concrete / electroacoustic material and how we manipulate it in (offline/real-) time.
by concrete, do you mean soundfiles? and electroacoustic - synth. generated? A big factor in the decision depends on the objective - personal, pragmatic, potential user base etc i have worked for all my projects with sclang for quite a while now, and i am encountering its limitations, particularly when developing a framework or a more complex application on top of it. the main problems are (not in any priority order though ; all my personal opinion):
... I agree with all your reasons but esp. wrt isolation and extensibility. Witness Stephan's recent posts on a request for affine transform routines. There are good implementations out there - (I just do "import ....") and the thought of having to stop work to build something as generic as that just presses the point, really. To be clear SCLang was a breath of fresh air when it arrived. And it _does_ perform well for what it was originally intended. I remember back in the SC0 days when Max was all the rage, rehearsing the arguments w. James as to why a script interface should be preserved. From my POV that arg. has been won by now. But the problem with being isolated on Paradise Island is that you've got to do everything with coconuts and jetsam. This is slightly off topic, but there was a recent post (sorry, I've lost it) describing csound as some sort of monolithic batch-processed monster, which is not quite accurate. I mention it in this context because they have gone down the track of separating the synth engine into a (C++) library from the API/ SClang-equivalent using wrapper code to generate the lang. interface for Java, Python etc. and the synth engine is incredible. No one I know uses cscore or whatever the lang. equivalent is now called. Of course SCsynth made the separation first and its positive implications have been far-reaching. It appears to me that if more stuff could be pushed permanently to SCsynth it might make SClang cleaner.
so this whole project doesn't aim at recreating sclang, but will rather allow me to create a specific framework that will use scsynth for sound synthesis and that will allow me to do a lot of stuff that sclang can do, e.g. creating musical structures in code, with focus on the _process of the composition_, e.g. tracking the creation of a piece in a confluently persistent editing tree among other things.
that last bit sounds interesting. i'm still undecided whether to stick to eclipse or netbeans or none of them. eclipse has the most mature plug-in infrastructure and platform API, but has SWT GUI which for me, as i obviously do everything in Swing, is a big minus, although you can mix SWT with swing. The Scala plug-in for eclipse - which will hopefully serve as a basis for the projects as you create code snippets in the scala framework - unfortunately is still quite buggy, but much more powerful than the netbeans cousin.
scala was chosen after some consideration. it is a very well designed language that has multi paradigm support like sclang, e.g. it is both objective oriented (with good things like trait-mixins, generics) and functional (without the suck of lisp-like syntax),
agree - really tight syntax but oh the look and feel and lack of readable compactness! If CLM was really going to take off it would have by now, I suspect. Not to be disparaging of course. it runs on the java VM (making it cross platform and since the bytecode tries to be very similar to the one generated by java, creating mixed scala/java projects is no problem), it is at the same time statically typed and has good type inference (producing rather compact code, not as compact as sclang, but it comes close when you design your libraries properly), and it has quite some facilities to add domain-specific-language flavours (although for example you cannot extend existing classes like you would do in sclang with the + {} syntax, something that would really be the killer-feature). scala is well rooted in the academic world, with a significant output of research papers,
academics like discussing type because it is easy to appear theoretical. Have you had any experience with Java and audio and threading? In my experience Java's platform independence is more of an idea than a reality once you try to implement anything substantial. Perhaps my expectations were set too high. [ All flames >> /dev/null ! ]
and it is gaining some crowd at the moment (as an indicator, there are quite a few monographs appearing this year on the market, and there are some major companies using scala). all in all it looks like a lot for more sustainable than other en-vogue languages, e.g. groovy, and while i'm not a prophet predicting the lifetime of a computer programming language, scala looks very robust and promising. apart from the support for java libraries (giving it out of the box GUI toolkits and comprehensive I/O) it comes with very interesting standard library (including comprehensive collections API and a very interesing actors library that could found the basis of both my scheduler classes and event handling / observer-patterns). this project is really in alpha state so it might go a completely different direction, although i have the feeling i have found a stable foundation. everyone who wants to experiment in this field is highly welcome to contact me about this, as to place this project from the very beginning in the open source was a deliberate step. this is not intended as a "user" project and there will be no support whatsoever, it will be my personal developing platform, but i'm happy to have other people onboard.
Of course!
while i have worked on the persistency stuff and multidimensional datastructures, regarding sc functionality, i have focussed on the basics that will allow me to quickly port code from sclang. e.g. consider the following ...
I see. Can I mention the elephant in the room? Would you like to say something about whether and if so why you have rejected python wrapping? One can use PySCLang to talk SCLang straight away and gradually morph it to a more complete form of PatrickKidds interface to SCSynth. At least then you've got access to a huge amount of stuff, SciPy, interface to eclipse via PyDev etc etc. I'm not proselytising (no need) but I am interested in the reasons. No one else has done it, that's probably a good one! which might at least be useful as 'canon' fodder :-)
Having an opportunity to discuss things away from devotee hype can be very productive. I can set up a forum if that would help.
ciao4now, David
ciao, -sciss- ----- original message -------- Subject: Re: [sc-users] Compiled language similar to sc ? Sent: Mon, 09 Mar 2009 From: David Worrall<sc3@xxxxxxxxxxxxx> > Hi Sciss, > Would you like to outline, firstly why you started to explore 'away' > from SClang and secondly why you chose scala-lang to explore, in > particular? > > David > On 09/03/2009, at 1:50 AM, Sc iss wrote: > > > it is statically typed but has good type inference so you don't have > > to type so much as for example in java. it is also functional so you > > can do most of what sclang can do, with the addition of types that > > saves you a lot of trouble when developing more complex classes. of > > course, it might be not for you if you want a quickly responding > > live coding system, but i'm trying to figure out how close you can > > get. it's also not the perfect language but well, i guess there is > > no perfect language, as everyone has there personal preferences, and > > supercollider has a lot of syntactic sugar that makes the source > > code more compact. it misses things like default argument values and > > method calls with argument names (EnvGen.ar( Env.perc ), doneAction: > > 2), but some are on the way for scala 2.8 i think. > > _______________________________________________ > sc-users mailing list > > info (subscription, etc.): > --- original message end ----
|