[REBOL] Re: Tools for Rebol Coders
From: sunandadh:aol at: 6-Jan-2002 17:37
Hi Joel,
Thanks for your thoughtful reply. I'll respond in one lump rather than trying
to pick out sentences to quote and comment on.
Implicit/explicit Return. This is a matter of style. I tend to always have an
explicit Return, to the extent of writing
return true
to show that I am NOT returning the result of the previous statement. I'd
expect a Lint dialect to enable me to turn that rule on, and you to turn it
off. That way we both get a usable Lint checker rather than none at all.
And yes, it would be difficult to write. And yes it may be derailed by
various dynamic changes as a program runs.
But who wants to write easy programs!? And I'd suspect most Rebol code would
not cause such derailings.
Rebol (at least on the web site) present itself as a language for
Internet/collaborative programming. But it seems in practice to make life
difficult for both those things:
-- I write some code that calls something from your site that calls something
from someone else's. And at some point it crashes with an "Error near a / b".
Is that my code or yours or the other person's or a Rebol-supplied mezzanine
function? I don't care how un-purist it is to expect the call stack to be
printed. But I need it at this point or the application is dead in the water.
-- I think we've all agreed that we find different styles harder to read than
others. So if you and I are collaboratively developing code, I'd want to
prettyprint yours into a style I prefer, and you'd do the same with mine.
This would open doors to collaborative programming.
I think there is a philosophical difference between your approach and mine.
You are making the case that it is difficult to do something 100%. Maybe that
makes you a purist. I'm saying, no worries there, give me the 75% that can be
done, and I'll live with the holes, or apply development standards to ensure
I don't go near them. I'm not sure what that makes me: a pragmatist or a
barbarian?
I hope you'll agree that we both have valid cases to make. I hope also that
RT are listening to this list and can apply their skills as language
designers to solve the problems I see while not damaging the purity we both
admire.
Sunanda.