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

[mike clemow]

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



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