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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.software-eng:1111 comp.lang.ada:2030 Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!decwrl!megatest!djones From: djones@megatest.UUCP (Dave Jones) Newsgroups: comp.software-eng,comp.lang.ada Subject: Re: comments on comments Message-ID: <2325@goofy.megatest.UUCP> Date: 23 Feb 89 07:22:23 GMT References: <6093@medusa.cs.purdue.edu> Organization: Megatest Corporation, San Jose, Ca List-Id: In an article by rjh@cs.purdue.EDU, Bob Hathaway says that he usually uses ADT's to do top-down design and implementation... If it works for him, that's great. I too have been designing all my programs around "abstract data-types" for some time now, although not since my first program, as he has. I started programming for bucks back in '71, when we didn't think of such things. Indeed, I sort of evolved into the practice years later as a result of much head-scratching. Only afterwards did I discover that I was not the only one to have dreamed up the technique. But I don't usually do top-down. I do bottom-up. Design, implementation, test, everything. It actually shocks some people when I say that. In the seventies "bottom-up" became a dirty word. Never mind that top-down methods resulted in some of the most inflexible code every put to disk. Top-down good. Bottom-up bad. Unnngghh. :-) I'll freely admit, there are times when top-down is the way to go. But it's not the way I do most of the programs I write by myself. I start out with a "bottom" that consists of lots of -- okay, I'll go along with the name -- ADT's which are likely to be of use in just about any kind of program: lists, queues, hash-tables, avl-trees, flexible buffers, priority queues and so on. Next I use these to form ADT's which are specific to the low-level objects under consideration, etc. And so it goes from bottom to top. The payoff comes when you want to change something. All you have to do is reshuffle these building blocks, which are still quite useful. But if you go from the top to the bottom, a change at the top is likely to invalidate the whole blasted thing. I sometimes carry it to unlikely extremes. My group is writing a Pascal compiler. If ever there seemed to be a top-down kind of task, that seemed to be it. I mean, Pascal is already done, for Pete's sake. There are standards documents which tell you what a Pascal compiler absolutely *has* to do. But.. I started out with my bag of standard ADT's anyway, and then defined some more: Pascal blocks, types, parms, variable-accesses... just about every kind of Pascal-object you can think of. One by one we implemented them as we worked our way up to type-definitions, expression-trees, statements. The methods for these ADT's went into a library. It was only a matter of a few weeks, long before the compiler's high level was anywhere near finished, that it paid off. Another group was doing a mouse-driven frontend for the interactive embedded compile/load/go feature that we have. They needed to be able to capture all of the type-information, formal parameters and so forth about the program being run, then fish around in it finding all the variables of this type, building all the short expressions that are assignment compatible to the second formal parm of procedure foo, etc.. No problemo. Just link with the new Pascal-compiler-library and do yo thang! I was psyched. Try doing that with a Pascal compiler that was designed top-down to be a Pascal compiler.