[chuck-users] ChubbY (ChucK in Ruby)?

[Kassen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090211/fa2e9e57/attachment.html>