Hey Mike! In a recent article in Computer Music Journal, the Chuck team finally

came out and admitted that "readability and clarity trumps performance and conciseness." In as much as Chuck was designed as a pedagogical tool for the PLOrk class (and now SLOrk), the choice of a simple imperative language (painfully C-like) I think is justified.

I'm not sure why you write "finally" here; I'm not even sure I can remember any ChucKian paper that *didn't* make this very clear, correct me if I'm wrong but I think this was explained in the early papers already and hinted at in the old priority lists and so on. I think this is a good choice, not just for novice users. Aiming something too much at the novice is -IMHO- a bad idea as people will only be a novice for such a short time. It's quite often that we see people sign up to the forum, ask how to get running at all and within a few days come up with a quite functional musical toy/tool. I'm not sure I'd call people "novice" after that any more. Being very readable is good for everybody. It's good in situations that are high on stress and/or beer, it's good at 3am and it's good for resuming work on a complicated project after a month or two. Basically it's good for all of us. I'm personally convinced clear language can/could save us all a lot of confusion and disagreements, often even arguments. Sadly in real life we are stuck with natural languages so some confusion there is unavoidable there. A few days ago I walked for a few extra Kilometers because the directions I got stated a certain road would "turn into" another. I took "turn into" to refer to "change into" while what was meant was that I could take a "turn" into this other road. Clearer directions would have saved more time there than a bike could've.

It's hard for me to accept this, since, like you, I find the language 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. The creators of Chuck want very much to keep it simple. In order to do this, they have to toe a very fine line between functionality and approachability.

I think I'm fairly aware of the sort of thing you are trying and doing and I'm not sure I agree what you are fighting is a actual language issue. IMHO the more relevant question there at this moment is some bad bugs and a lack of documentation. I'm thinking about the type system and casting in particular here. To me those are age issues (and developer time constraint issues) more than real language design ones. As you know very well; ChucK as a program doesn't always and everywhere follow ChucK as a language specification. Mostly the difference is pure bugs. Right now I feel that the problem with (very) advanced code is that -so far- relatively few people write it and so once you start doing that you'll run into a relatively large amount of bugs. This makes such code hard or sometimes even impossible to write but to me that's a bug issue and not a language one.

The upsides of this include the fact that many novice programmers are attracted to Chuck, and it's easy to get started. I think that the success of any addition to the language depends on two things. The first is that it provides a unique and demonstrably useful functionality that previously did not exist. The second is that the addition does not in any way limit the approachability of the language.

Agreed. Well, agreed as long as additions are made in a way that's coherent with the rest of the design. So far ChucK syntax is quite coherent and that in itself makes it easy to write. I too would like things like functors and i'd like (chuck-) operator overloading but not at the expense of coherence.

I'm trying to get this community to share their code a little more so that we can collect tools that make the use of Chuck more powerful.

This is clearly great.

Also, Michael Heuer has provided a git repository of some library code that he uses to do functional programming (using functors, since functions are not first class objects in Chuck) and tweening, etc. Honestly, I'm still trying to wrap my head around it (being a novice myself). It is here:

http://github.com/heuermh/lick/tree/master

Wow, how did I miss that? That looks great! Rambling again...

Not at all, it all seemed quite coherent and sensible to me, even if I didn't agree with every point you made. Yours, Kas.

Hey Kas,

I'm not sure why you write "finally" here; I'm not even sure I can remember any ChucKian paper that *didn't* make this very clear, correct me if I'm wrong but I think this was explained in the early papers already and hinted at in the old priority lists and so on.

Ha! It's true; what I should have said was that *I finally understood* why Ge et. al. designed Chuck the way they did. And, while I share some of Rob's desire for more powerful abstractions, I'm fully on board with the design ideas behind Chuck. BUT, I do think that there are aspects of Chuck that make creating such abstractions from within Chuck kind of difficult. Yes, some of those things are bugs--we're here to find and squash them by putting Chuck to the test. ;-) Some of the things are just ideological language-preference things. For instance, despite people raving about Ruby, I find Chuck slightly more readable than Ruby. I think it feels like Chuck's syntax reveals more of what's going on underneath... But Ruby's definitely more powerful. Chuck is also probably faster than Ruby. A sample-level intervention in Ruby makes my spine shudder, but trying to do build abstractions is easier with things like blocks, functions as objects, reflection, etc. Still, I use ChucK probably more than any other language and I am very interested in its development as a language. I would love to have more powerful abstractions, but not at the expense of its clarity and readability, of course. SC is a great example of a language that is concise and powerful but also almost illegible (don't tell them I said that). The learning curve to SC is almost a wall to someone who hasn't programmed before (and hard enough for those who have). I think that ChucK represents an attempt at a sort of "holy grail" of programming systems: low barrier to entry, quick (enough) execution, concurrency, run-time code-swapping, and hopefully powerful abstractions. I also think that the more of these abstractions we can build in ChucK itself, rather than its C++ underpinnings, the better. Features like reflection, operator overloading, and the like would make things like meta-object systems and a functional paradigm possible / easier. I mean, in spite of the VM, ChucK syntax doesn't represent a huge advancement over C, with the exception of classes. There's a lot of room for improvement, in my opinion. -Mike On Tue, Feb 10, 2009 at 9:04 PM, Kassen wrote:

Hey Mike!

...

In a recent article in Computer Music Journal, the Chuck team finally came out and admitted that "readability and clarity trumps performance and conciseness." In as much as Chuck was designed as a pedagogical tool for the PLOrk class (and now SLOrk), the choice of a simple imperative language (painfully C-like) I think is justified.

I'm not sure why you write "finally" here; I'm not even sure I can remember any ChucKian paper that *didn't* make this very clear, correct me if I'm wrong but I think this was explained in the early papers already and hinted at in the old priority lists and so on.

I think this is a good choice, not just for novice users. Aiming something too much at the novice is -IMHO- a bad idea as people will only be a novice for such a short time. It's quite often that we see people sign up to the forum, ask how to get running at all and within a few days come up with a quite functional musical toy/tool. I'm not sure I'd call people "novice" after that any more.

Being very readable is good for everybody. It's good in situations that are high on stress and/or beer, it's good at 3am and it's good for resuming work on a complicated project after a month or two. Basically it's good for all of us. I'm personally convinced clear language can/could save us all a lot of confusion and disagreements, often even arguments. Sadly in real life we are stuck with natural languages so some confusion there is unavoidable there.

A few days ago I walked for a few extra Kilometers because the directions I got stated a certain road would "turn into" another. I took "turn into" to refer to "change into" while what was meant was that I could take a "turn" into this other road. Clearer directions would have saved more time there than a bike could've.

...

It's hard for me to accept this, since, like you, I find the language 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. The creators of Chuck want very much to keep it simple. In order to do this, they have to toe a very fine line between functionality and approachability.

I think I'm fairly aware of the sort of thing you are trying and doing and I'm not sure I agree what you are fighting is a actual language issue. IMHO the more relevant question there at this moment is some bad bugs and a lack of documentation. I'm thinking about the type system and casting in particular here.

To me those are age issues (and developer time constraint issues) more than real language design ones. As you know very well; ChucK as a program doesn't always and everywhere follow ChucK as a language specification. Mostly the difference is pure bugs. Right now I feel that the problem with (very) advanced code is that -so far- relatively few people write it and so once you start doing that you'll run into a relatively large amount of bugs.

This makes such code hard or sometimes even impossible to write but to me that's a bug issue and not a language one.

...

The upsides of this include the fact that many novice programmers are attracted to Chuck, and it's easy to get started. I think that the success of any addition to the language depends on two things. The first is that it provides a unique and demonstrably useful functionality that previously did not exist. The second is that the addition does not in any way limit the approachability of the language.

Agreed. Well, agreed as long as additions are made in a way that's coherent with the rest of the design. So far ChucK syntax is quite coherent and that in itself makes it easy to write.

I too would like things like functors and i'd like (chuck-) operator overloading but not at the expense of coherence.

...

I'm trying to get this community to share their code a little more so that we can collect tools that make the use of Chuck more powerful.

This is clearly great.

...

Also, Michael Heuer has provided a git repository of some library code that he uses to do functional programming (using functors, since functions are not first class objects in Chuck) and tweening, etc. Honestly, I'm still trying to wrap my head around it (being a novice myself). It is here:

http://github.com/heuermh/lick/tree/master

Wow, how did I miss that? That looks great!

...

Rambling again...

Not at all, it all seemed quite coherent and sensible to me, even if I didn't agree with every point you made.

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

2009/2/11 Kassen :

Another thing is that just a few years ago it really wasn't all that clear what a language like this would/could/should be like; as we are all learning how to express ourselves in ChucK it's also becoming more clear what ChucK should be like.

Right on! -- Tom Lieber http://AllTom.com/

Hi Kas,

Yes, clearly, and some things follow from Ruby being interpreted and ChucK being compiled.

I would put it this way: Some things follow from Ruby being reflexive and everything in Ruby being an object. I think that it matters a lot less that it's compiled. After all, we're compiling to byte code that runs in a VM, correct? It's not native code that its running. But I don't want you to get the impression that I don't love Chuck. And I really don't want to perpetuate a comparison of ChucK and Ruby. What I'd rather hear is "Hey Ruby does this neat thing that allows me to do X," and then we all discuss how to do it the Chuckian way. Maybe wrap it up in a neat class and distribute it so we can all do it that way, if we want. This makes me throw up a little in my mouth to say, but what if there was something like CPAN for Chuck? Conceptually, of course. In practice CPAN drives me bonkers, but I really like the idea. Thinking out loud again, Mike On Wed, Feb 11, 2009 at 12:17 AM, Kassen wrote:

Hey Mike.

...

Ha! It's true; what I should have said was that *I finally understood* why Ge et. al. designed Chuck the way they did.

I think a lot of what we have now also stems from a "make it work, make it right, make it fast" order of doing things. Right now it (mostly) works but I don't see why being readable would need to be at odds with execution speed in some sort of magical ChucK 5.1.8.23 release in 2030.

...

BUT, I do think that there are aspects of Chuck that make creating such abstractions from within Chuck kind of difficult. Yes, some of those things are bugs--we're here to find and squash them by putting Chuck to the test. ;-) Some of the things are just ideological language-preference things.

Yes, clearly, and some things follow from Ruby being interpreted and ChucK being compiled.

I do feel that language ideology may be a good way of arriving at a coherent syntax but it shouldn't become a limiting thing on it's own. I think that one of our challenges may be looking for ways of expressing some of these more advanced concepts in a way that's coherent with ChucK's syntax. ChucK is not C or Java, we do some things differently, for example concurrency, and I don't see why we shouldn't also do other things differently if that would make sense for our needs. Preferably easily as well.

As I understand it all some of the differences between C and Ruby come from Ruby being able to do various things thanks to it being interpreted. However, ChucK is different from C in having a parser, compiler and VM that are integrated. There have been some plans for using this to enable us to update/ extend running code, something that compiled languages don't normally do. This too was hinted at in the very early papers, there was a design for a sort of interactive syntax for this on the Wiki, but clearly bug-fixes, audio analysis and garbage collection were deemed more important. I agree with that, we should probably have GC before we look into updating/extending previously entered code and abstractions will likely lead to more garbage generating behaviour as well.

I think we need to look at things like "power" in their context. It's no more fair to expect a compiled language like ChucK to have all of Ruby's functions than it is to expect Ruby to sample acurately and concurrently process audio in real time. I don't think you could simply take ChucK, outfit it with Ruby's syntax and features, and expect it all to work as the features and syntax interact with and depend on the underlying functionality which is quite different and needs to be different.

...

I think that ChucK represents an attempt at a sort of "holy grail" of programming systems: low barrier to entry, quick (enough) execution, concurrency, run-time code-swapping, and hopefully powerful abstractions. I also think that the more of these abstractions we can build in ChucK itself, rather than its C++ underpinnings, the better. Features like reflection, operator overloading, and the like would make things like meta-object systems and a functional paradigm possible / easier. I mean, in spite of the VM, ChucK syntax doesn't represent a huge advancement over C, with the exception of classes. There's a lot of room for improvement, in my opinion.

Yes, I'm in complete agreement with this. I don't see at all why higher level abstractions would be at odds with the current ChucK syntax and I'm sure there are plans to go in that direction as well, considering some of the reserved keywords. The same goes for some of the namespace/shared data questions as well as updating running code. Those are all related anyway and on top of that they make sense musically.

Personally I suspect that the main reason we don't have some or most of this yet isn't linguistic but rather has to do with garbage collection taking longer to implement than anticipated. Another thing is that just a few years ago it really wasn't all that clear what a language like this would/could/should be like; as we are all learning how to express ourselves in ChucK it's also becoming more clear what ChucK should be like. I sincerely doubt Ge planned this far ahead when he started; that would be disturbingly un-ChucKian (and maybe he would've run while he could!). :¬)

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Craig; and some of *those* (my own favorite is Squeak) can do music and garbage

collection at the same time without missing deadlines.

Ah, yes, Squeak! I remember that, and your "Quoth", the text-adventure livecoding system. Could I encourage you by saying I'm still very interested in that?

The thing that matters to me is the immediacy I get from dynamism. I don't ever want to have to stop the processes that make my music. ChucK comes close to that feeling, by making the edit/spork cycle very quick, but to propagate the effects of code changes I still have to kill shreds I would rather leave running during a performance. (Apologies if the situation has changed, I haven't actively used ChucK for my own work in several months. And apologies if I'm rehashing stuff everyone already knows. :)

No, that situation has remained basically the same. I agree with your perspective here; Whatever we decide to do (if anything) should make musical sense. The current temporary implementation of unchangeable public classes isn't very very powerful compared to some other languages -and that's a issue- but it also isn't very conductive to live performance and improvisation which I feel is another issue and one that should ideally be addressed by a solution to all of this. Yours, Kas.

On Wed, Feb 11, 2009 at 12:23 PM, Stephen Sinclair wrote:

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.

On Feb 11, 2009, at 7:10 PM, mike clemow wrote:

This is fascinating, but I'm disappointed that so many of these things get developed for Max/MSP and not PD--especially since the code bases are so similar.

This is one of the reasons I put all my code on-line, so that others may do this. I don't use PD, and I tend to allocate time for work related to my own music-ing. Too much fun stuff to do! And I've learned that time is, in fact, finite.

One of the PD developers teaches at my school. I hope to pick his brain about porting these things over to PD someday. The chuck~ object that Brad Garton has written is another one that I'd love to have in PD.

And this is a case where the put-it-on-line strategy worked. Thanks to Martin Robinson, ask and ye shall receive: https://lists.cs.princeton.edu/pipermail/chuck-users/2007-March/001619.html brad http://music.columbia.edu/~brad

And this is a case where the put-it-on-line strategy worked. Thanks to Martin Robinson, ask and ye shall receive:

https://lists.cs.princeton.edu/pipermail/chuck-users/2007-March/001619.html

Looks like it's not there anymore. That link links to a download of the first version, which is no longer there. :( But I also think you've updated your code to work with a newer release since he released the PD version.

... Wouldn't it be snazzy to be able to add chuck to any application/environment you want to compile by writing a few 'wrapper' functions to run the VM, parse scripts, etc.? And then just add a chuck.dylib or chuck.so to the linking? Building chuck into ruby or pd or lisp or lua or whatever would be so easy!

I totally agree. I think that ChucK could aim this direction, but probably is stand-alone partially due to its being Ge's thesis, which had to work-at-all before it was all-powerful-and-universal.

And for the record, I really dislike the OSC model for gluing apps together.

That's all well and good, but with ChucK (up until the recent, extremely limited FileIO object) you're options have been limited to MIDI, OSC, or NetIn for any sort of inter-process communication. OSC for IPC is kludgy, but I even think that you yourself expressed that Chuck is ideal for prototyping. Getting two programs to speak to each other in OSC in order to demonstrate an idea is attractively simple--even if it isn't robust, scalable, or safe. OSC: The duct-tape of network protocols. ;-) -Mike On Thu, Feb 12, 2009 at 12:23 AM, Brad Garton wrote:

One more thing about all this -- I really wish that music-synth languages would evolve in a fashion that they could be built as loadable or linkable libs instead of constantly thinking they need to stand alone in the world. We've worked toward this in the design of RTcmix (to the point where you can basically instantiate an RTcmix object and various methods then run the features of the language), but there are still some global var issues (chuck is similar in this respect). Wouldn't it be snazzy to be able to add chuck to any application/environment you want to compile by writing a few 'wrapper' functions to run the VM, parse scripts, etc.? And then just add a chuck.dylib or chuck.so to the linking? Building chuck into ruby or pd or lisp or lua or whatever would be so easy!

And for the record, I really dislike the OSC model for gluing apps together.

brad http://music.columbia.edu/~brad

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Brad, That's awesome, thanks! I'm going to see what it would take to update it to the latest version. Cheers, Mike On Fri, Feb 13, 2009 at 10:49 AM, Brad Garton wrote:

(re chuck~ for PD):

On Feb 12, 2009, at 12:05 PM, mike clemow wrote:

...

Looks like it's not there anymore. That link links to a download of the first version, which is no longer there. :(

I found the link:

http://www.cc.gatech.edu/ugrads/m/mjr/chuck~/

Be careful, some mailers don't include the "~/" as part of the imbedded link.

...

But I also think you've updated your code to work with a newer release since he released the PD version.

That's true. I don't know how much it would take to update Martin's code.

...

OSC: The duct-tape of network protocols.

This will be my quote-of-the-day!

brad http://music.columbia.edu/~brad

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Stephen Sinclair wrote:

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

That page has some interesting examples. Here's something similar to the Polyrhythm one done in Chuck and LiCK polyrhythm.ck: class Pattern extends FloatProcedure { dur step; float freq; float pan; SinOsc sin; fun void connect() { sin => Echo e => Pan2 p => dac; 0.2::second => e.delay; pan => p.pan; freq => sin.freq; 0.0 => sin.gain; } fun void run(float value) { 0.5 => sin.gain; step => now; 0.0 => sin.gain; } } Pattern right; 0.25::second => right.step; 440 => right.freq; 0.5 => right.pan; right.connect(); Pattern left; 1::second / 6 => left.step; 330 => left.freq; -0.5 => left.pan; left.connect(); spork ~ Loops.loop(right, right.step, 18::second).run(); spork ~ Loops.loopN(Loops.loop(left, left.step, 16::second), 0::ms, 2::second, 1).run(); 10::second => now; <<<"done">>>; The loop methods are loop(FloatProcedure, wait between procedure calls, total length of time to loop) and loopN(Procedure, wait between procedure calls, initial offset, number of times to loop) michael

On Feb 10, 2009, at 6:28 PM, Brad Garton wrote:

I have great contolling chuck~ from lisp using maxlisp...

I have great *fun* controlling chuck~ from lisp... jeez, some days I just can't type. brad http://music.columbia.edu/~brad