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...