On Sunday, February 8, 2004, at 05:36 PM, Dan Shafer wrote:
FWIW, I'm always, always, always going to argue against any change to xTalk syntax that makes the language one iota more complex than it is....
And those folks, as I said in my earlier post, are vanishingly unlikely to change languages to any other tool, particularly one which is accessible to those who have not "paid their dues" and become members of the "Programming Priesthood."
Though you avoided comment on making the language less complex than it already is, I'm reminded of how politicians use the slogan "no more taxes!" rather than "less taxes!"
It seems that to various degrees that we have paid our xTalk dues. There is a learning curve.
One of the ways xTalk is complicated is in all the exceptions. A quick check showed 45 articles in the documentation containing "except" and 261 containing "cannot".
Removing exceptions can simplify xTalk and enhance its power.
I think generalizations can also simplify xTalk and enhance its power. (I recognize that what I call simpler, others might call something else.)
For example, if 'f()' is a built-in function then we can apply it as 'f()' or 'the f'. By why limit this to built-in? Why not allow this for custom functions, too?
Right now we have 'read' and 'read socket' using two different syntaxes and options. Why not allow all capability for both?
I think there is lots of room for simplifying xTalk.
(And then that will leave room for adding what I want.)
Dar Scott
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
