<ara.t.howard / noaa.gov> wrote in message news:Pine.LNX.4.62.0608220913440.21284 / harp.ngdc.noaa.gov... > On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote: > >> If the language were statically typed, I would know straight away >> what >> type the parameter was and can look up, exactly, what it does and can >> probably easily discern what it's role is. > > i think that's a silly thing to say. straight away, tell me what role > this > function plays: > > void (*signal(volatile int x, void (*const y)(int )))(int ); > > ?? > > and i don't think that's being unfair. the reason is that static typing > builds up mountains of information for even mildly complex function > definitions. there is a reason a program exists (cdecl) to decode them! > it's > very existence backs my assertion that little can be groked 'staight > away' > merely by statically/explicitly typing function signatures. 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). > in addition, languages like ocaml, while also statically typed, leave > this > information out of the source while still be readable: > > let double x = x * 2;; > > let sum x y = x + y;; > > let factorial x = > if (0 > x) then (raise Exit) else > match x with > 0 -> 1 > | n -> (n * (factorial (n - 1)));; > > > notice - this is statically typed. also notice the lack of explicitly > encoded > typing - the compiler figures it out. You're right. I'm talking more about explicit typing rather than "static typing," so perhaps my thread is ill named... > so, to drive it home further, you seem to think 'static' means > 'explicitly > written by the programmer' - but of course that's not what it means. > fortunately, the 'explicit' route is available to you in ruby by simply > following certain pratices, either comment functions or cast arguments > using > the 'class name as casting ctor pattern' used all over the place in ruby. > for > isntance > > def m a, b, c > a = String a > b = Integer b > c = Float f > > .... > end > > now, that's not static, but it is explicit. you can obivously follow > this > pattern with user defined classes. 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... >> Now, don't misunderstand me, I'm not advocating turning Ruby into a >> statically typed language. I enjoy that Ruby has no "templates" (in the >> C++ sense) because every method is "templatized!" The mere fact that >> C++ >> has templates is testimony to the power of dynamic typing. > > templates are not dynamic typing though - i'd say they are testimony to > how > much of a bastard a strong/static/non-inferred type system can be and how > adding compiler features to do the work for us is essential. note that > templates and any other sort of compiler inference feature __remove__ > explicit > type info from the source! ...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... >> I'm just saying that static typing "ain't so bad," in that this is one >> problem I would not have had were I working with a statically typed >> language. > > correct - you'd simply have different ones. 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'm also looking for how people deal with this issue, since it surely >> must >> come up from time to time... > > well, i showed one solution above. there are plenty of others. Well, I can't wait to hear them!