Or ChucK could drop these data type shenanigans entirely. Really, who's benefiting?
Well, I didn't want to come right out and say it, but dynamic typing seemed like a no-brainer for a livecoding language.
Definitely relevant points, and certainly have been considered, and as with many things, we are continuing to evaluate different possibilities, including when/how dynamic typing is beneficial for a language like ChucK (I don't think either static or dynamic is the better solution all across the board). In terms of on-the-fly proramming, and not necessarily taking a particular stance on various shades of typing dynamism, one can make an argument that having static typing in many cases can facilitate aspects of live coding, as different semantic/syntactic contracts between the programming language and programmer present different "cognitive loads" when writing code. I'd say it depends on the nature of the thing being live coded, and I think we can find cases that would benefit from static and from dynamic typing. Finding a balance would be a totally rad area of future investigations. Best, Ge!
On Sat, Jun 21, 2008 at 4:03 PM, Tom Lieber
wrote: On Sat, Jun 21, 2008 at 12:51 PM, Kassen
wrote: I think this is to prevent worse issues. If you'd change your class's member-function return types that would lead to serious issues with other code that was already compiled using those. I think this matter is affected by many (if not all?)of the issues affecting the updating of running code.
Or ChucK could drop these data type shenanigans entirely. Really, who's benefiting?
Also, my small hacking skills, yada-yada. :)
-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users