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
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:
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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users