On Wed, Feb 11, 2009 at 12:23 PM, Stephen Sinclair
Sorry, dropping into the conversation a little late here. And I'll be even later!
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. Yeah - the application I did to play the Long Now chimes had all of the logic in Applescript, and the sound production in ChucK. I daresay that if I was doing it again now, I'd add a shred to listen for a "please stop now" message.
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.
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 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. This is a darn good idea.
I wonder if the current Perl6 runtime (Parrot) would be a good target. It's already set up to handle stuff for very dynamic languages, and it's pretty fast as well.
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 Will definitely go look at that. Thanks for the ideas.
--- Joe M.