Sorry, dropping into the conversation a little late here.
On Tue, Feb 10, 2009 at 4:18 PM, mike clemow
lacking. To be precise, the first 5 minutes of Chuck are pure joy, but it becomes an uphill battle from there to do anything of significant complexity.
This is why I tend to treat ChucK as a synthesizer rather than as a programming language. For me, I don't feel like ChucK was created to build applications out of it, or read and write data files, or display a GUI, etc. To me, it's for producing sound. Since it can be controlled remotely by OSC, anything else can be used to do the actual application logic. In my usage, ChucK is used in as stupid a way as possible, I give it as little information as I can to get the sound and timing I require, with _everything_ else being done elsewhere. Taken this way, I find ChucK to be pretty much adequate for what I want. Sometimes I need to implement data structures that have a certain complexity, but I really do try to keep this to the absolute minimum. Definitely sometimes I feel that it could be greatly improved by the use of closures or a better dependency system. But I don't really let this hold me back, because most use cases that I have don't really need this kind of flexibility, because I design things to be as stupid as possible. (i.e., retain only the information needed to play the right sound at the right time.) Certainly there are cases where this approach isn't adequate, but personally I find it just fine. Generally I've been doing the "other side" of my applications in Python, but any other language would do just fine as well. To me, the real contribution of ChucK is definitely not the language design. It is basically just C after all, with a few extra goodies. The real innovation in ChucK, as we all know, is the idea of being oriented around "strong timing". So, on the one hand, there's no reason these ideas can't be present in other languages, and on the other hand, there's no reason ChucK itself can't be improved to provide dynamic features. One of the biggest difficulties with extending ChucK is dealing with the VM. It's hard enough to port it to 64-bit, let alone implementing new features. Basically, the ChucK VM has a certain proof-of-concept feel about it when you look under the hood. Important for a thesis of course, but perhaps it might be time to think about replacing it with something where we can really leverage other people's good work in this highly-researched area. I think the right approach from here would be to just replace the VM completely, and using a different VM to execute ChucK code. I've been playing around with two ideas, and can't seem to decide which one is better. 1) Port the VM to LLVM. Since ChucK is statically typed like C, it would basically allow us to use ChucK to write code that executes as fast as C. This would truly allow writing UGens straight in ChucK code for example, with little to no drawback as compared to implementing UGens in C++. Drawback is that adding new language features would require implementing them basically from scratch. 2) Port the VM to JavaScript. Several JS engines are now available that provide exceptionally amazing JIT-based optimization. The browser wars are providing a great incentive for research here, and there's no reason we can't piggy-back on it. Using V8 or TraceMonkey, you'd get pretty good speed, while at the same time opening up the possibilities of adding dynamic features to the language. You get things like closures and memory management for free. Big downside: possibly lose real-time safety. Ideas of using Ruby and Python are good too, but I think both of these don't have the raw speed advantages of JS or the JVM for example, and aren't likely to see it soon. Here's a blog post I wrote a while ago about JS-ChucK: http://www.music.mcgill.ca/~sinclair/content/blog/ideas_on_transforming_chuc... Of course, on the topic of this thread, there's the whole point of whether it is really worth it to extend ChucK at all, or simply implement its strong timing features in another language. An interesting question, but it would be a separate project after all, so to me it's not something that is really on-topic for the ChucK community. One thing to check out on this topic however is Vessel, a ChucK~-like thingy running on top of Lua: http://www.mat.ucsb.edu/~wakefield/lua~/lua~.htm Steve