larry@VLSI.JPL.NASA.GOV (03/03/89)
--
A discussion of whether top-down or bottom-up design is better is ridiculous.
It's like arguing over whether hands or feet are better. Each have different
but complementary uses. The person who can (or chooses) to use only one of
them is handicapped.
It's equally ridiculous to effuse over how wonderful object-oriented design is,
or rail against it. Like every other tool, OOD is has uses and drawbacks.
Similarly, CoBOL is an excellent language for the limited domain it was
designed for: complex I/O formats, simple numeric processing, and simple
programming logic. For many years 95% of all business problems could be
handled well with CoBOL. The problems came when CoBOL (or ForTran, or
whatever) programmers began to attempt to use their tools for problems outside
their useful domain. Hammers are poor tools for digging ditches.
The common theme in each of the three above areas is that the participants show
no idea of what trade-offs are and how to use them. "Trading off" is a core
concept in engineering, one that should be alloyed with every idea and
technique the SW professional possesses. If not, they aren't engineers but
only technicians.
Larry @ vlsi.jpl.nasa.govrjh@cs.purdue.EDU (Bob Hathaway) (03/04/89)
In article <890302220159.62f@VLSI.JPL.NASA.GOV> larry@VLSI.JPL.NASA.GOV writes: >-- >A discussion of whether top-down or bottom-up design is better is ridiculous. >It's like arguing over whether hands or feet are better. Each have different >but complementary uses. The person who can (or chooses) to use only one of >them is handicapped. > Umm, within modules several general approaches are possible. I've been using top-down to refer to starting with top level design and my last article asked for alternatives, I'm not sure there is a better way. Would you begin the design of the presented compiler front-end without the top level design? How do you go about designing your Adts, starting at the top and recursively applying design? I'm interested in cases and examples where this doesn't apply. >The common theme in each of the three above areas is that the participants show >no idea of what trade-offs are and how to use them. "Trading off" is a core >concept in engineering, one that should be alloyed with every idea and >technique the SW professional possesses. If not, they aren't engineers but >only technicians. > Larry @ vlsi.jpl.nasa.gov Yes, abstraction vs. efficieny is a tradeoff in good design that all proficient programmers are aware of, and I could go on. I'm not sure I would want to work with a (low quality) program which didn't use Adts or reasonable encapsulation constructs. Advocates of modern design and well engineered software are high quality engineers and not technicians, we simply prefer to work with state of the art techniques and are aware of the tradoffs involved. Bob Hathaway rjh@purdue.edu
shapiro@rb-dc1.UUCP (Mike Shapiro) (03/07/89)
In article <890302220159.62f@VLSI.JPL.NASA.GOV> larry@VLSI.JPL.NASA.GOV writes: <<< much deleted >>> >handled well with CoBOL. The problems came when CoBOL (or ForTran, or ===== ===== ======= Please learn the proper spellings: COBOL and FORTRAN for the current standards. ===== ======= If you're referring to the next standard, it's Fortran. ======= (See Foreward to X3J3 draft for document X3.9-198x.) -- Michael Shapiro, Gould/General Systems Division 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: ...sdcsvax!ncr-sd!rb-dc1!shapiro