Date: Mon, 2 Jun 1997 16:46:55 -0400 (EDT) From: "Art S. Kagel" To: Mark T Logan Cc: adalee AT sendit DOT sendit DOT nodak DOT edu, djgpp AT delorie DOT com Subject: Re: Quake vs. Demos In-Reply-To: <19970530.213927.7111.0.fwec@juno.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 30 May 1997, Mark T Logan wrote: > you are cruisin' for a bruisin'. However, ask any software engineer, > computer science student, or for that matter a professor, and they will > tell that C++ and other object oriented languages are indisposable. You > see, when a team of twenty people start to work on a massive program, > a procedure oriented language simply ***will not work***. Ask anyone who has been coding for more than 5 years and you'll hear what I have to tell. C++ is neither more nor less than the embodiment of good structured coding techniques (and a poor embodiment at that since it does not enforce the use of its structure like other structured and object oriented languages). Good coding discipline is all that is needed to tackle complex projects, good tools just help make the job easier. Do not get me wrong. I like C++, it is an advance over C as it provides the tools to write good, structured, data centric code. However, good programmers have always utilized and promoted the techniques that C++ promotes. Data centric code (when appropriate), modularity, top down/bottom up coding styles, as well as reducing and formalizing the connections between modules and data objects. However, we were doing this in C and in FORTRAN and in BASIC (lord help us) and in PASCAL (yes and even in COBOL), languages which had no support and provided no encouragement. Do not be so vain that you believe that there were no complex programs before graphics and games. Try coding missile guidance systems, routing and delivery systems, warehouse distribution systems, parts and repair support systems, airline reservation systems, etc. Some of these have been around since the early 50's. All were coded in 'procedural' languages. > > The problem is that the complexity of today's software is too much for > the > human mind to comprehend. With a procedure oriented language, all > parts of the program are inextricably linked with the rest of the > program. This is just bad code! Read a few books on structured programming or P.J. Plauger's articles for 'Computer Language' magazine when he was there. Good structured programming deplores the problems that you describe and provides hard rules for preventing them. > You cannot write one part of the program without understanding the rest > of > the program, and that's impossible. I agree. However, let's rewrite you next statements using structured programming buzzwords: > With an object oriented language, you only have to understand the class With a structured language and data centric technique you need only > that > you are writing. The rest of the program is unimportant. Each class understand the data structure that you are writing. ... Each data module > handles > one task, has its own data members which cannot be accessed by any other handles one task, providing the functions to provide access to the data structure(s) which it exports. No other, direct, access is permitted. > part of the program. This allows a team member to write one part of the > program, > and integrate it with the rest of the program that has been written by > someone > else. The rest of your text can stand unmodified. Unlike Eiffel and other fully object oriented languages, C++ only provides the tools to code objects properly but does not enforce the rules. Just like us structured programming mavens from the murky past, we knew what to do but had to have the discipline to do things right, so it is with C++ programmers. Even then there were structured languages which provided the tools to write structure code and the enforcement to prevent sloppy coding. Languages such as Modula 2 were perfect for this. Modula 2 provided everything that one needed to write structured data centric code and the only tool it lacked was polymorphism. I like C and C++, and do not miss my days coding in FORTRAN, BASIC, Pascal, and COBOL, but I loved Modula 2. The bottom line? Be a disciplined programmer and no project is too complex. Just like a complex calculus exercise any program can be broken into simple modules or classes that match the data and functionality. 'nuff said. Art S. Kagel, kagel AT bloomberg DOT com