Path: utzoo!attcan!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!media01!pkr From: pkr@media01.UUCP (Peter Kriens) Newsgroups: comp.object Subject: Re: Do we really need types in OOPL's? Message-ID: <1426@media01.UUCP> Date: 9 Oct 90 09:33:22 GMT References: <0yw10qr@Unify.Com> <60700003@inmet> Reply-To: pkr@media01.UUCP (Peter Kriens) Organization: Mediasystemen, Netherlands Lines: 142 I can't stop myself from entering the discussion. I have been following it for quite some while now and it seems that most people live in the type camp or the dynamic camp. I would like to join the discussion with some "statements". 1. Typing is preferred by people who never enjoyed a typeless language. 2. A typed language gives you the freedom to make more errors, of which only some are catched by the compiler. 3. A strict typed compiler does not allow you to skip a thorough test. 4. The result of an error in a typed language is usually disastrous 5. A typed language forces you the write and maintain the same functionality multiple times. 6. A typed program makes your runtime a little faster but your development a lot longer. 7. With a typed language language the development cycle time is exponantially proportional with the project size and a dynamic language it is almost independent from project size. Because some of these statements are quite provocative, I would like to give some background for the fanatics who are really interested: > 1. Typing is preferred by people who never enjoyed a typeless > language. Most people I have met who enjoyed the joys of a "fast" Smalltalk system seem to have a hard time going back to an environment like C(++). And if you like at the amount of information you have to type in for a C(++) program and Smalltalk, this is quite understandable. When I write in C, I always feel like explaining to my 2 year old daughter what I would like here to do. If you look at a C program, it is 80 percent telling the compiler the types, the templates, the keywords and 20% defining a function. > 2. A typed language gives you the freedom to make more errors, > of which only some are catched by the compiler. When you like at a C program it seems that number of errors you are allowed to make are a magnit4;1Hude bigger. For example if I have two structures A and B that do maintain something (information hiding, even in C), than if I have two procedures pA and pB that are supposed to do the work from the structures, I get a crash if I call pA(B) or pB(A). So it is nice to have a compiler that checks this for me. In Smalltalk, the run time mechanism makes the choice and this particualar error could not occur. I agree that in some case it would be nice to have some "capability checking", but it is undoubtedly true that there are a lot more errors to make in C than in Smalltalk. > 3. A strict typed compiler does not allow you to skip a thorough > test. A lot of people say that static typing is necessary because a test will not get to all the places in the code. If that is true, can you really have confidence in the code? When I was writing in Pascal, a VERY strict typed checked language, I never was able to have a faultless program the first time it ran without compilation errors. So it seems that testing is still necessary, even with static type checking. And if it is still necessary, I would prefer an environment which told me where he went beserk, instead of a crash because of an overwritten pointer or something like that. > 4. The result of an error in a typed language is usually > disastrous It seems that errors in static typed languages are much more disastrous than errors in dynamic typed language. When I was writing in C and PL/M the errors I got were usually a machine that died on you. And then after a night debugging you found the pointer that went astray or the misinterpretation of that routine. In a dynamic language the error shows up with a smoking gun in its hands. > 5. A typed language forces you the write and maintain the same functionality > multiple times. A great example of this is the select funtion in smalltalk. If I have a collection I can call it to make a subselection according to a certain criteria. One method works for all collection, while the collections can contain any kind of object. Well lets compare that to the Booch classes where he needs a float set, a float orderedcollection, an integer sortedcollection etc. And then for each class you need to write that select function. Even in Smalltalk I think it is not perfect. Because of the fact that inheritance is done by way of a tree, I still have to write that select function in all branches that act like a collection, or build the tree in a way which is unfavarouble in another way. I would like to assign the select method to a number of classes. > 6. A typed program makes your runtime a little faster but your > development a lot longer. There is no dout about the fact that typed languages are faster. They can bypass a lot of checking and indexing in runtime. And even though vendors claim that a message send is only 25% slower than a procedure call, this doesn't mean that the difference is is only 25%. In C many statements are executed inline, in Smalltalk, everything is a message send. This results in a considerable overhead. But how I have seen so many times programmers spending much more time developing code than that code will ever save in the field, that I wonder where the priority should be. And because most programs usually only have a small critical section, I think optimising that section and writing the remainder in a better language is very much preferrable. > 7. With a typed language language the development cycle time is > exponantially proportional with the project size and a dynamic > language it is almost independent from project size. In a static typed language, the compiler needs to know "everything" of all the classes. For example in C++, the compiler needs to know the size of the instance variables to create stack space, and for virtual binding it needs to know all the superclasses. This results in an explosion of include files. Because there are so many include files, the changes of a change in any of those files becomes greater, a change enforces a recompile of all dependent modules. A normal development cycle is normally linear dependent on project size, but this close coupling of modules makes it exponential. ------- When I write these lines I always try to think how my grandchilderen in 2045 will look back to these days. I think they will have the same feeling as we have now looking back at the first days of automobiles and televisions. Things which seem funny to us now were taken very serious then. But I think that they will have a much more efficient way of telling the computer what to do than C. ================================================================= Peter kriens Tel. (31)23-319075 Mediasystemen Fax. (31)23-315210 Waarderweg 19 Home (31)23-251942 Haarlem Postbox 4932 Zip 2003EX