Subject: Re: Why typing? From: Erik Naggum <email@example.com> Date: 1995/09/21 Newsgroups: comp.software-eng,comp.lang.functional,comp.lang.lisp,msu.cps.misc Message-ID: <19950921T152258Z@naggum.no> [Peter Hermann] | The benefit pays off in a drastic(!) reduction of programming errors. the value is in early detection of programming errors, ideally causing a reduction of programming errors in the running code, but this is not necessarily the case as even those "errors" that there is no value in detecting are detected, and "correcting" them only adds unnecessary complexity to the program. further, as the number of types increases (as it is wont to do when users are encouraged to create their own types) and the interactions between types increase (as it is wont to do as users need to involve the type system in all the semantics that previously were implicit in less specific types), the ability of even very intelligent and highly experienced programmers to keep track of them and obtain the desired result in the presence of overloaded operators is decreasing dramatically. | With strong typing you are even able to introduce dimensioning | of types. examples: inch, centimeter cannot be added. they should be, and the result should be convertible to any unit of length. be careful not to make your type system too narrow, or you run into the problems outlined above. if you have created a type system where "inch" and "cm" are incommensurate types, you will have to write functions to add functions of _some_ incommensurate types, but not others, i.e., manual work to add such functions. if you instead had a type for length, and it knew the original unit in addition to the value in terms of the least common denominator, you could add inches and centimeters, but you would have to request a particular unit before the result could be displayed. | Dollars and D-Mark etc. etc. but that is incredibly useful! you would of course need to know the date associated with a currency amount, with function that returned exchange rates for a given date, so you could add them and obtain a meaningful value. also needed: future and indefinite dates with the ability to fix a date (exchange rate) later. in fact, you need dates in any currency type whether you deal with multiple currencies or not. in the presence of inflation and interest, the value of a currency is time-dependent. see the pattern? if you create types that are too narrow, you will seriously limit the usefulness of the type system, _and_ create a complexity from which you will find yourself wanting, but unable, to escape. that's why less restrictive type systems win. | Mechanisms can be implemented with the features of a strongly typed | language, which inhibit the multiplication of kilometer*kilometer | giving kilometer but instead allow (only) kilometer*kilometer giving | squarekilometer Mechanisms of that kind enforce your abstraction for | the sake of preventing lots of programming errors. seems that you need a "unit" system, not separate types. may I suggest a look at the HP 48 implementation of calculating with units? they have done it right. it is unfortunately very complex to get it right. this leads me to my second argument against strong typing. getting a type system right requires so much detailed specification that the cost is so high that mistakes are actively discouraged. this cost is not necessarily offset by the benefits of using such types, especially not if the program needs to adapt its speficiation to changing needs discovered only as the program is being used in preliminary forms (often called "prototypes", but I'm not sure building a prototype only to discard it and build "the real thing" is a good idea. it seems the projects that go into a state of completion such that they are no longer learning from the experience of use are extremely rare. projects that no longer _can_ learn from the experience of use is, however, quite common. the cost of mistakes in type systems is often caused by poorly understood or outright misunderstood relations between types. my conclusion is that less strongly typed (i.e., dynamically typed) systems are the ultimate type systems, because they allow growth and change, while preserving the ability to use machine reasoning about types. strict type systems, where every "object" is a type, do not scale well because the computer is not involved in the typing decisions, only in checking them. still, some of the lessons of "object-oriented" programming in the Algol family can be fruitfully employed in dynamically typed systems. CLOS and Dylan are both embracing the "inclusive object" where methods are added as needed, instead of the "exclusive object" where methods must be known a priori. essentially, it is the a priori aspect of strongly typed systems that is fundamentally unsuited to the process of acquiring the knowledge of the types necessary to implement them and relate them correctly. #<Erik 3020685778> -- there's a car that has more computing power than it took to get man to the moon: the BMW 750. but _you_ are stuck here on earth. haha.