On 3 Jan 2010, at 16:47, Kassen wrote:
If we're serious about changing the ChucK language, I'd put in my vote for a Ruby-style approach.
Personally I'm more interested in looking what issues those other languages solve, how those related to our concerns, then finally figuring out how to solve those things in a ChucKist way.
I think so, too. All computer languages have quirks, or "gotchas" as they are called here: http://en.wikipedia.org/wiki/Gotcha_(programming) In addition, languages tend to be well designed for a certain type of issues, and using them in other circumstances can be rather cumbersome.
If you are really interested in mixing ChucK and Ruby you may want to look at what's on Tom's cocktail menu; http://github.com/alltom/ruck
This link describes some peculiarities of Ruby, of which some are not so good: http://en.wikipedia.org/wiki/Ruby_(programming_language)#Deviations_from_beh... For example, imposing extra conditions on identifiers is not good - I use Haskell, in which variables can only start with lower case (those that start with uppercase are reserved fro types), and when one accidentally is doing wrong, one gets mysterious compiler errors. A declarative language, I think is best, which is essentially what is used in math - the road that ChucK is on. Another problem of languages is having too few precedence levels - some investigated math, and found that there are a lot more than in typical computer languages. Here, Ruby inherits the problem of Pascal for logical operators. A language benefits readability if one can eliminate the need of parenthesizes. Also, Ruby treats a line ending as an end of statement, which generally is bad if one needs to write something that takes up more than one line. This idea comes from scripting languages, like shell, which are good for writing simple things, but known to be problematic for outright programs (steeps learning curve, and hard to read and debug). Haskell uses an alternative called layout syntax: in addition to normal bracketing to environments one can drop them and use indentation instead. For example, -- Leading term in monomial order. lead :: Polynomial -> Term lead p = last xs where Xs xs = normalize p Here, the indentation of "where" says that the stuff that follows on the same indentation level belongs to the block. The problem is that the compiler tends to give strange error messages "possibly due to wrong layout" and one may have to guess if it is a layout problem or not. (Also, it sets a tab equal to 8 spaces when computing layouts, which has fallen out of use.) Haskell has the problem that the function name must be repeated often when defining a new function. Another quirk is the lazy evaluation, which is wholly incompatible with imperative structures, which leads to the introduction of the complicated concept of monads (an import from math category theory). Getting back to Ruby, it treats various objects as Boolean, which is a bad idea, inviting errors. The gotcha link mentions the classical C mistake, confusing the two if (a = b) then ... if (a == b) then ... The first is an assignment, and the second a test of equality - it is common to do mistakes on this one. But the problem could have largely been circumvented if types did not implicitly convert to Boolean types. Then the first one would have generated a compiler error, except when programming specifically Boolean types, but that does not happen so often. In general, it is a bad to have implicit type conversions to types which loose information. That is a C-quirk. Anyway, just examples on what one might have to think about when moving along. If people try out what works and not works and discusses it here, that may give the developers feedback. Hans