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

[mike clemow]

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 <signal.automatique at gmail.com> 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



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