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

[Kassen]

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