<ara.t.howard / noaa.gov> wrote in message news:Pine.LNX.4.62.0608221432440.21284 / harp.ngdc.noaa.gov... > On Wed, 23 Aug 2006, Just Another Victim of the Ambient Morality wrote: > >> ...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. Personally, I don't see these small "time savings" as a big advantage. Perhaps I shouldn't shrug off "syntactic sugar" so easily but features of a language that save a bit of typing aren't a big deal to me. I'm a fast typist and software is plagued by so many other issues... Please don't misunderstand me. Ultimtely, all features of a language are "time saving" ones, in that we obviously want to spend as little time as possible to get the job done. However, since I spend most of my time thinking about how to do things and figuring out why my implementation doesn't work (debugging) and very little time actually typing out my program, I prefer some of the more macroscopic features of a language. For C++, that would be templates (the STL and boost), typing and subtyping. For Ruby, that would be dynamic typing (which replaces the whole C++ template idea), blocks as closures and it's general run-time flexability (the fact that attr_accessor can be defined in the language itself is amazing!)... This may explain why I use other people's code so much. I'd rather not waste time re-inventing the wheel and will gladly borrow one from someone else... >> 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! ;-) Yeah, I'm not surprised that this might be one of those "what can you do? Life is hard..." problems. I was just throwing this out there in case it was interesting and that, maybe, someone might have a surprising solution or approach to this issue... Incidentally, what inspired all this is that I'm trying to use mechanize and it's totally not working. Specifically, some sites like slashdot.org work fine but rubyforge.org fails spectacularly. What happens is that all links at rubyforge.org are nil. Some debugging suggests that the problem is in htmltools, which mechanize uses to parse the HTML. So, someone else's code uses someone else's code to do the work. Now you can see why the term "node" comes up a lot in my example problems. Except for the copyright and license agreement, there's almost no documentation... I'm tempted to make another post asking other people who use mechanize (and/or htmltools) to go to rubyforge.org and see if they have the same problems I do...