Em 12-11-2013 19:49, Scott Wilson escreveu: > I think the idea of a js synthdef interface (and others) is good, but > I think a switch to js entirely would be a serious step backwards in > language design. I somehow like sclang. There's something good about > it, I think. There have been attempts at other language bindings, but > despite that sclang has remained the centre of gravity. > > Besides, even if we could agree to switch to another language, how > likely is it that we could actually get any consensus on which one? > ;-) As someone who has used both scala and haskell for supercollider interfacing I can report on my experience. The pros of using those languages for me were: * Debugger - I can't even express in words how amazing having a debugger is... * static typing - specially in the case of haskell, if it compiles, there's 80% chance that it just runs as it should. Haskell type system can be practically invisible you can type a whole program without writting any types if you want, it inferes them for you. * interfacing with other libraries - there are libraries for almost anything under the sun in mainstream languages. Also the toolchain is more developed, there are packaging systems, etc. * performance - specially haskell, which can be comparable to c. * loads of computer science experts (the ones that write papers on compilers) actually working and improving the compilers/toolchain etc for those languages. * on a personal note, I was interested in exploring functional programming and current research on that paradigm, so obviously, those languages allowed me to learn about such things. In the end I returned to supercollider because: 1* none of those languages had a usable (for me) just in time coding environment, i.e. live coding. Haskell has emacs bindings but I'm not an emacs persoon (yet), so I couldn't use that, even with that you can't really do proper live coding of functions etc. Compile/run just doesn't cut it for me, I need to select text and execute. 2* there was a lot of stuff missing that is already in supercollider. I.e., want a gui for server meter, code it yourself... not to mention patterns, etc, the effort is immense for just one or two persons to re-implement all that stuff... 3* gui coding was extremely complex (for my brain) in scala and moderatelly complex in haskell. Those gui toolkits are made for professional programming so they have a lot more options then sc, but that also means they are more complex. musical gui making doesn't need all the complexity of a general gui toolkit. 4* sc has a community that I can interact with. * the lack of real-time properties didn't really enter into the decision, but then again, I make mostly drone, not much of an event person :-) So for me, the ammount of people contributing code to any one musical language and using it for their musical endeavours, is as important as the language itself. I feel much more attracted to haskell on an intelectual level, but on a realistic level I get more stuff done in supercollider. Indeed agreeing on a language wouldn't be easy, some people are more into oop, others into fp, and within each paradigm into different languages. As to features, I would be interested in abolishing barriers between event level code, synth graph level code, and sample level code, meaning I would write at all of those levels using the same language and probably the same type of abstractions. I've seen that implemented already in Euterpea (a haskell library) and it seemed great indeed. That can probably only be implemented if the lang and server run together because you need to use the language to manipulate samples using normal functions of the language. I'm not sure that is doable within the confines of sc as we know it, though. Features I would love to have on sc4: debugger, and more advanced oop stuff (interfaces or multiple inheritance), lang concurrency, faster language, some more functional stuff (methods being functions too, do notation/monads - this would be just syntax sugar, currying, getting recursion working without weird stuff happening), namespaces, modules. best, Miguel Negrão
Attachment:
signature.asc
Description: OpenPGP digital signature