[chuck] a toast

[Ge Wang]

On Jan 21, 2005, at 8:51 PM, qbxk wrote:

> i would like to propose an idea that might very well have good reasons 
> for not doing.  i'm putting this out here - phishing...
>
> i want perl and chuck to get married.

(Isn't ChucK a little young to be married (I mean, age difference 
aside)?)

> chuck & perl what a beautiful couple.  yeah, perlish things like 
> @arrays &  %hashes i need to throw at music. and map, grep, dothis if 
> something, and the bajillion perl modules that might create a barrage 
> of audio somehow.   good idea/bad idea?

Maybe both good and bad?  arrays + hashes are good things - going to 
appear shortly
(see below) - and extensive string handling is coming soon.  the 
bajillion Perl modules
are tempting.  Perhaps someone with more expertise in Perl (i.e. Alex 
and many
other Perl-enthusiasts who are on this list) can give a better answer.

I can, however, "articulate" one related aspect:

The design goal of ChucK is to enable the precise, elegant, and 
flexible programming
of audio, without loss of generality (i.e. completely flexible control 
rate, precise timing
  / concurrency), on-the-fly when appropriate.  This aim has driven and 
hopefully will
always guide (and modify) the future of ChucK.  It is the hope that we, 
as a group, can
figure out what is good towards that aim.

As you can tell, ChucK syntax is glued together from syntax and ideas 
of many existing
languages, ranging from C, Java, to Max/MSP, ML, to ChucK itself (some 
stuff had to
be "invented").  An advantage of building the language from the 
"ground-up" and not
necessarily committing the design to any one existing school of 
language design frees
ChucK from obligations and focuses on the design of the language to 
reason about
and control audio - we include what is useful, and leave out the rest.  
(It also means
we have to re-invent some wheels, but that can be good because 
sometimes a round
wheel isn't always we need)

There are certainly a great many things we can learn and take from Perl 
(like it's
powerful string/array processing, and the (sometimes ultra-)concise 
spirit of the
language).  There are other considerations which make tight integration 
difficult
- for example, Perl is weakly-typed, unlike the ChucK type system, 
which is
useful for things like resolving the ChucK operator, doing arithmetic 
on time and
duration, and makes larger systems much easier to reason about and
debug.

In short, ChucK could learn much from Perl - though they are quite 
different
in their "life goals".

As for arrays in the next release:

- there are arrays
- arrays are strongly-typed like the rest of ChucK
- arrays can be multi-dimensional
- all arrays are, by default, both integer-indexed and associative:
- more to come...

// basic example
{ 1, 2, 3, 4 } => int foo[ ];
// assign to element 0
10 => foo[0];
// assign to value mapped from key: "bar", on same array
24 => foo["bar"];

> if good how? run script thru perl interpreter which emits chuck code 
> fed into chuck?  line by line for speed?

This is an interesting idea to try, even for the sheer spectacle alone.

Best,
Ge!