Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!att!cbnewsc!lgm From: lgm@cbnewsc.att.com (lawrence.g.mayka) Newsgroups: comp.object Subject: Re: Do we really need types in OOPL's? Summary: Dynamic typing in large software systems Message-ID: <1990Oct5.013201.12459@cbnewsc.att.com> Date: 5 Oct 90 01:32:01 GMT References: <0yw10qr@Unify.Com> <411@eiffel.UUCP> <736@tetrauk.UUCP> Organization: AT&T Bell Laboratories Lines: 61 In article , cline@cheetah.ece.clarkson.edu (Marshall Cline) writes: > You act like the ability to send *any* message to *any* object is a > wonderful feature of weakly (dynamically) typed languages! In fact it > pointedly shows that the compiler can't (and doesn't try to) statically > verify that the message is ``safe'' (``safe'' meaning ``that object *IS* > equipped to handle this message''). This very ``feature'' (``ability'' > to send any message to any object without the compiler helping you > statically determine if you'll crash and burn at runtime) makes > dynamically typed languages the wrong choice for very large software > systems. (Not that this is their goal in life -- they make *great* > interactive rapid prototyping environments -- but they don't scale -- > which is ok so long as both tools are used for what they are designed). The "safety" of static/strong/compile-time typing is a guarantee of definition/usage type agreement across a "finished" program assembled at a single point in time. This assumption is fundamentally incompatible with the development and evolution of large software systems, which - like living beings - are never "finished" until they're *dead*! Large systems - successful ones - undergo continuous evolution from their initial genesis in the lab, throughout their lifetime, all the way up until the retirement of the last remaining specimen from service. They must continually face new situations different from those explicitly planned by the original designers. The ability to reuse most software without change in new, unplanned circumstances is essential, as is the related ability to introduce even major architectural improvements incrementally. Compile-time "consistency" between two bodies of code is simply another word for "dependency" - i.e., a need for synchronization that, on a massive scale, slows down new development to a crawl. The occurrence of a type error, far from being a "crash and burn at runtime", is merely a software exception like any other, and responds to similar treatment by the appropriate exception handler. Keep in mind that mere compile-time typing does not guarantee that exceptional situations will never occur. Far from it! In fact, since static typing virtually always implies a lack of dynamic typing, the former engenders a false sense of security that may permit serious errors (like a wild write from an uninitialized pointer) to cause catastrophic damage before discovery. I encourage those who claim that dynamic typing is "the wrong choice" for large software systems to actually run experiments on large (e.g., over a million lines of source) software systems, comparing dynamic vs. static typing - above all, for ease of modification and extension. Note that for the statically typed system in the experiment, you must not take advantage of any flexibility ascribable to dynamic typing (e.g., multiple executables tied together by Korn shell scripts/commands or ASCII pipes/files). Such usage is simply an admission that beyond a certain size, your total program is unwritable and/or unusable without dynamic typing. No, you must look instead at a very large, statically typed software system that runs in a single address space (or in multiple address spaces that communicate via statically typed messages). Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.