schallen@dinl.uucp (Eric Schallenmueller) (09/14/90)
Well folks, thanks for the help on my issue regarding the poor Ada response at compile time. The reason I didn't post the info regarding paging and cpu etc. is because I didn't have it. The only new info I have is that the box is a VAX 8800. That doesn't mean much to me since I'm using a VAXstation III. Also they have about ten disks. I don't know if they are full, fragm- ented or what, or even if the files are randomly distributed across each one. From the comments I have been getting, it looks as if the verdict is guilty on some counts, such as multiple instantiations of generics. This, I thought was a feature of Ada which should be heavily utilized, particularly for code reuse issues. It appears that this is not the case: that generics should be used, but in a limited way. Am I right in this quickly make conclusion? I hope not. Seems as if this would defeat the purpose of generics. One of the things that many of you asked is: why are you recompiling the world every time you do a build? Part of the reason is that the core of the system that they are having the most troubles with is used by EVERYONE, and so a single change to the core (kernel??) causes a massive recompile. Although this is probably a poor design/implementation, it can't really be changed at this point in the ballgame. Regarding the reuse issue. I read an article by Royce Walker of TRW about CCPDS-R where he talked about reusing 120k LOC to produce over 2 million LOC of machine language instructions. Am I reading too much into this, or did they really do that much code reuse with generics and still be able to have outstanding performance in compile and execution of their system?? This last paragraph seems to contradict my quick conclusion in the immediately preceeding paragraph. I think we'd all benefit if someone could straighten me out on this stuff. With much gratitude, Eric
firth@sei.cmu.edu (Robert Firth) (09/14/90)
In article <1732@dinl.mmc.UUCP> schallen@dinl.uucp (Eric Schallenmueller) writes: > >One of the things that many of you asked is: why are you recompiling the world >every time you do a build? Part of the reason is that the core of the system >that they are having the most troubles with is used by EVERYONE, and so a >single change to the core (kernel??) causes a massive recompile. Although this >is probably a poor design/implementation, it can't really be changed at this >point in the ballgame. Eric, let me urge you most strongly to rethink this position. You seem to be trying to fix a symptom - the long overnight rebuilds - rather than the cause - a software structure where a core module is too visible and too volatile. This is probably a result of poor design - somebody didn't do the right partitioning, layering, abstraction, information hiding or whatever. The grief you are experiencing is telling you, very plainly, that the design is broken. Under those circumstances, experience surely teaches us this: the design won't work; you won't be able to finish a quality product; and even if you do ship something, it will be unmaintainable. The ONLY answer is to go back and do it right. Moreover, if you have to backtrack, the sooner you do it - the earlier in the life cycle and development path you take the hit - the cheaper it will be and the better the result will be. The choice to stick with this design is not open to you. As I see it, your only choices are redesign or failure. Please take a hard look at this advice; it is based on a lot of my own mistakes that I would not want others to repeat.
schallen@dinl.uucp (Eric Schallenmueller) (09/15/90)
In article <8587@fy.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes: > > Eric, let me urge you most strongly to rethink this position. You seem > to be trying to fix a symptom - the long overnight rebuilds - rather > than the cause - a software structure where a core module is too > visible and too volatile. I'll certainly pass the info on, Robert. Unfortunately the decision is not mine to make. I can only make recommendations, such as yours to my colleagues and hope they take the appropriate action. > Under those circumstances, experience surely teaches us this: the design > won't work; you won't be able to finish a quality product; and even if > you do ship something, it will be unmaintainable. The ONLY answer is to > go back and do it right. Moreover, if you have to backtrack, the sooner > you do it - the earlier in the life cycle and development path you take > the hit - the cheaper it will be and the better the result will be. I agree and appreciate the input. It's unfortunate that circumstance didn't allow (ooh, bad choice of words here) the proper design to begin with. We have certainly learned a lesson -- I hope. > The choice to stick with this design is not open to you. As I see it, > your only choices are redesign or failure. Please take a hard look > at this advice; it is based on a lot of my own mistakes that I would > not want others to repeat. I hear you loud and clear. We'll see what happens. Thanks again, Eric P.S. Robert, I believe you know a colleague of mine: Cathy Peavy, from the Ada Technology Conference. Ring a bell?