Hey Mike!<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In a recent article in Computer Music Journal, the Chuck team finally<br>
came out and admitted that "readability and clarity trumps performance<br>
and conciseness." In as much as Chuck was designed as a pedagogical<br>
tool for the PLOrk class (and now SLOrk), the choice of a simple<br>
imperative language (painfully C-like) I think is justified.<br>
</blockquote><div><br>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.<br>
<br>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.<br>
<br>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. <br>
<br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
It's hard for me to accept this, since, like you, I find the language<br>
lacking. To be precise, the first 5 minutes of Chuck are pure joy,<br>
but it becomes an uphill battle from there to do anything of<br>
significant complexity. The creators of Chuck want very much to keep<br>
it simple. In order to do this, they have to toe a very fine line<br>
between functionality and approachability.<br>
</blockquote><div><br>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.<br>
<br>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.<br>
<br>This makes such code hard or sometimes even impossible to write but to me that's a bug issue and not a language one.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The upsides of this include the fact that many novice programmers are<br>
attracted to Chuck, and it's easy to get started. I think that the<br>
success of any addition to the language depends on two things. The<br>
first is that it provides a unique and demonstrably useful<br>
functionality that previously did not exist. The second is that the<br>
addition does not in any way limit the approachability of the<br>
language.<br>
</blockquote><div><br>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.<br> <br>
I too would like things like functors and i'd like (chuck-) operator overloading but not at the expense of coherence.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'm trying to get this community to share their code a little more so<br>
that we can collect tools that make the use of Chuck more powerful.<br>
</blockquote><div><br>This is clearly great.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Also, Michael Heuer has provided a git repository of some library code<br>
that he uses to do functional programming (using functors, since<br>
functions are not first class objects in Chuck) and tweening, etc.<br>
Honestly, I'm still trying to wrap my head around it (being a novice<br>
myself). It is here:<br>
<br>
<a href="http://github.com/heuermh/lick/tree/master" target="_blank">http://github.com/heuermh/lick/tree/master</a></blockquote><div><br>Wow, how did I miss that? That looks great! <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Rambling again...<br>
<br></blockquote></div><br>Not at all, it all seemed quite coherent and sensible to me, even if I didn't agree with every point you made.<br><br>Yours,<br>Kas.<br>