From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c7b637f8b783b7c X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,c7b637f8b783b7c X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,c7b637f8b783b7c X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,c7b637f8b783b7c X-Google-Attributes: gid1108a1,public X-Google-Thread: 107d55,c7b637f8b783b7c X-Google-Attributes: gid107d55,public X-Google-Thread: 103376,c7b637f8b783b7c X-Google-Attributes: gid103376,public From: Mike Charlton Subject: Re: The great Java showcase (re: 2nd historic mistake) Date: 1997/08/29 Message-ID: <1jwoh6hm2mr.fsf@nortel.ca>#1/1 X-Deja-AN: 268935084 References: <34023FC9.59E2B600@eiffel.com> <3404670B.C3A2C4A2@pagesmiths.com> <01bcb38a$8ddc1200$1c10d30a@ntwneil> Organization: Nortel (Northern Telecom) Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.java.tech,comp.lang.c++ Date: 1997-08-29T00:00:00+00:00 List-Id: dewar@merv.cs.nyu.edu (Robert Dewar) writes: > James P. White wrote in article > <3404670B.C3A2C4A2@pagesmiths.com>... > > Even though Java lacks anything as comprehensive as DBC, in our > > experience the simple matter of having automatic memory management and > > pointer protection has yielded a productivity boost of several hundred > > percent. > > If automatic memory management really cut down your development time by > a factor of several, I hate to think of what on earth you were doing to > waste that much time previously. Sure memory management problems can be > persnickety, but if they are taking up 80% of your time, something is > VERY wrong with the way you are writing programs. A couple of people have said that Robert's statement is a cheap shot. I'd have to disagree. I think the difference of opinion comes about from different ways of measuring productivity. Automatic memory management will surely not affect the requirements stage. It should only slightly affect the design stage (the design will be different, but you really don't have to spend all that much time worrying about memory issues). In coding, it will have some effect on productivity, but if you have some experienced programmers, it shouldn't be more than 20-30% of the time (IMHO). Back end testing shouldn't uncover too many issues (especially if you have already used a memory checking program like Purify). So again, 20-30% of your time should be plenty. Support and maintenance is another question. Tracking down memory problems is a real pain. In my experience, 10 or 15% of issues are memory related. They also take an inordinate amount of time to deal with. Making sure you have good code reviews should keep this to a minimum, though. Anyway, I agree with Robert. If you are spending 80% (or even 50%) of your time *for the whole project* on memory issues, you have some serious problems (lack of code inspections and inexperienced people qualify as serious problems with me). I have worked with both large C++ projects and large projects using a proprietary language with automatic memory management. Yes, with C++ we spent a lot of time thinking about memory. However, using automatic memory management, we spent a lot of time thinking about performance. I'd say it's a bit of a toss up. No one solution will work well for every problem. Mike