On Wed, 23 Aug 2006, Just Another Victim of the Ambient Morality wrote: > You're right. I did make a blanket statement about statically typed > languages that's not always true. However, it does often help to know > what types are being used when reading a function definition. Consider > this example: > > > def parse data, machine > node = data.index 0 > machine.process node > end > > > As it is now, it's rather contrived but you could add some (contextually) > sensible code around it without disturbing this basic functionality and > see it offers no clue as to what "node" or "machine" is. You could look > for anything with a "process" method but what "node" will be is much > harder to find and important to the understanding of what this method is > for (despite that it's obviously not important to understanding what the > method actually does). fair enough. i don't disagree here that explicit typing might __help__ here, but it's only one tool when statically analyzing code. > You're right. I'm talking more about explicit typing rather than "static > typing," so perhaps my thread is ill named... ok. > I may but others may not. I am looking over code that does not follow > this convention (nor did I expect them to) so it doesn't help my > situation... granted. > ...but they perform the same purpose. The purpose of C++ templates is to > reuse code. Often, you want to perform the same operations on different > types of data. A linked list of integers doesn't behave any differently > than a linked list of strings, except that one has integers while the > other has strings. The purpose of dynamic typing, as far as I can tell, > is to reuse code. Sure, you can reuse a variable for very different > purposes but is that really such an advantage? In my opinion, the > purpose of dynamic typing is so that methods can accept parameters of > varying types and perform the same operations on those types, thus > reusing the method code... hmmm. i see the primary advantage of dynamic typing as the time saving i gain by not spoon feeding the compiler and the associated productivity gain. you are pointing out that it does not always save time, but my experience is that it does for a large percentage of the time. > Of course... What do you think I'm trying to say here? That static > typing is the way to go and Ruby should adopt it? You can't probably > think that after everything else I've said so it must be something > else... I'm looking to see how people deal with the problems that come > up from being dynamically typed... i understand. still, these static/dynamic threads often get muddled by ill definitions and then ramble forever - it's best to get on the same page regarding terms and the problem... that's all. > Well, I can't wait to hear them! i guess what i'd offer is that mechanisms like - explicit typing - documentation - introspection (as in runtime debugging) - static typing - clear coding conventions all contribute to code understanding and that many of these features are available to ruby and not, for example, c and vise-versa. if someone leaves you with no tools then it's just bad code! ;-) in this case it seems nearly so but you do still have rtti under irb/debug mode. it's a powerful tool if not easy to get setup with an appropriate env... kind regards. -a -- to foster inner awareness, introspection, and reasoning is more efficient than meditation and prayer. - h.h. the 14th dali lama