delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/06/02/19:51:29

Date: Mon, 2 Jun 1997 16:46:55 -0400 (EDT)
From: "Art S. Kagel" <kagel AT ns1 DOT bloomberg DOT com>
To: Mark T Logan <fwec AT juno DOT com>
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: <Pine.D-G.3.91.970602160439.7766A-100000@dg1>
Mime-Version: 1.0

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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019