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;"><div class="Ih2E3d"><br>
</div>Ha! &nbsp;It&#39;s true; what I should have said was that *I finally<br>
understood* why Ge et. al. designed Chuck the way they did.</blockquote><div><br>I think a lot of what we have now also stems from a &quot;make it work, make it right, make it fast&quot; order of doing things. Right now it (mostly) works but I don&#39;t see why being readable would need to be at odds with execution speed in some sort of magical ChucK 5.1.8.23 release in 2030. <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>
<br>
BUT, I do think that there are aspects of Chuck that make creating<br>
such abstractions from within Chuck kind of difficult. &nbsp;Yes, some of<br>
those things are bugs--we&#39;re here to find and squash them by putting<br>
Chuck to the test. &nbsp;;-) &nbsp;Some of the things are just ideological<br>
language-preference things.<br>
</blockquote><div><br>Yes, clearly, and some things follow from Ruby being interpreted and ChucK being compiled.<br><br>I do feel that language ideology may be a good way of arriving at a coherent syntax but it shouldn&#39;t become a limiting thing on it&#39;s own. I think that one of our challenges may be looking for ways of expressing some of these more advanced concepts in a way that&#39;s coherent with ChucK&#39;s syntax. ChucK is not C or Java, we do some things differently, for example concurrency, and I don&#39;t see why we shouldn&#39;t also do other things differently if that would make sense for our needs. Preferably easily as well.<br>
<br>As I understand it all some of the differences between C and Ruby come from Ruby being able to do various things thanks to it being interpreted. However, ChucK is different from C in having a parser, compiler and VM that are integrated. There have been some plans for using this to enable us to update/ extend running code, something that compiled languages don&#39;t normally do. This too was hinted at in the very early papers, there was a design for a sort of interactive syntax for this on the Wiki, but clearly bug-fixes, audio analysis and garbage collection were deemed more important. I agree with that, we should probably have GC before we look into updating/extending previously entered code and abstractions will likely lead to more garbage generating behaviour as well.<br>
<br>I think we need to look at things like &quot;power&quot; in their context. It&#39;s no more fair to expect a compiled language like ChucK to have all of Ruby&#39;s functions than it is to expect Ruby to sample acurately and concurrently process audio in real time. I don&#39;t think you could simply take ChucK, outfit it with Ruby&#39;s syntax and features, and expect it all to work as the features and syntax interact with and depend on the underlying functionality which is quite different and needs to be different.<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 think that ChucK represents an attempt at a sort of &quot;holy grail&quot; of<br>
programming systems: low barrier to entry, quick (enough) execution,<br>
concurrency, run-time code-swapping, and hopefully powerful<br>
abstractions. &nbsp;I also think that the more of these abstractions we can<br>
build in ChucK itself, rather than its C++ underpinnings, the better.<br>
Features like reflection, operator overloading, and the like would<br>
make things like meta-object systems and a functional paradigm<br>
possible / easier. &nbsp;I mean, in spite of the VM, ChucK syntax doesn&#39;t<br>
represent a huge advancement over C, with the exception of classes.<br>
There&#39;s a lot of room for improvement, in my opinion.<br>
<font color="#888888"><br></font></blockquote></div>Yes, I&#39;m in complete agreement with this. I don&#39;t see at all why higher level abstractions would be at odds with the current ChucK syntax and I&#39;m sure there are plans to go in that direction as well, considering some of the reserved keywords. The same goes for some of the namespace/shared data questions as well as updating running code. Those are all related anyway and on top of that they make sense musically.<br>
<br>Personally I suspect that the main reason we don&#39;t have some or most of this yet isn&#39;t linguistic but rather has to do with garbage collection taking longer to implement than anticipated. Another thing is that just a few years ago it really wasn&#39;t all that clear what a language like this would/could/should be like; as we are all learning how to express ourselves in ChucK it&#39;s also becoming more clear what ChucK should be like. I sincerely doubt Ge planned this far ahead when he started; that would be disturbingly un-ChucKian (and maybe he would&#39;ve run while he could!). :¬)<br>
<br>Yours,<br>Kas.<br>