Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!rex!ames!haven!ni.umd.edu!uc780.umd.edu!cs450a03 From: cs450a03@uc780.umd.edu Newsgroups: comp.lang.misc Subject: RE: Dynamic typing (part 3) Message-ID: <20MAR91.08413246@uc780.umd.edu> Date: 20 Mar 91 08:41:32 GMT References: <602@optima.cs.arizona.edu> <2400035@otter.hpl.hp.com> Sender: usenet@ni.umd.edu (USENET News System) Organization: The University of Maryland University College Lines: 54 Nntp-Posting-Host: uc780.umd.edu Steve Knight writes: > >In response to a claim (or observation) made by David Gudeman that >"dynamically typed languages are generally half to a tenth the size >of programs in statically typed languages" Dan Bernstein reasonably >writes back. > >] I don't believe you. Give an example. > >Of course, this gets us into the foolish realms of anecdotes and virility >tests. It's somewhat worse, IMHO, in that there is no such thing as a true example. A true example would be a drop-in replacement for another program, maintaining its quirks and 'optimizations' as though they were mandated by <>. It is also false (as Peter da Silva has indirectly pointed out) to place all the credit for compactness on dynamic typing... some compactness is from dynamic linking (or its equivalent), some is because startup code isn't needed, some might be because the program is kept in a higher-level form (e.g. threaded code). And some benefits come from incidental features (it being very easy for example, to implement overlays on a system which doesn't have them in the os, if you can manipulate 'object code' with your language primitives, and call such routines with low overhead). Perhaps what we've been arguing is not so much for dynamic typing, but the inclusion of additional types of high utility? But what if that additional type is an array whose bounds are maintained at run-time? What if there are a large number of primitives to support manipulations of the list, and so on? Basically, dynamic-typing (the way I've been thinking about it) applies to languages which allow more structure that if/then/else and do/while. Things like data-selection operations and iteration over some sequence of values (where it DOESN'T MATTER what the data is, you just want to select it, and so on). I'm talking about making these first-class functions in the language, not in the sense of 'this is an ad-hoc feature which can be used to speed up performance on platform X', but 'this is a language feature, intended to replace lower-level operations'. And to any argument that 'This can be done in C', I respond, it can be done in assembly language too. (And to any who say "that's not portable", I add that it can even be done in 8086 assembly). In so-called statically typed languages, you are forced to think and program in a low-level fashion. Dynamically typed languages (If I say 'array'-oriented or 'list'-oriented, do I exclude Icon or ML?) tend to be higher-level languages. It doesn't matter how fast your solution is if it doesn't run. Raul Rockwell