www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/05/31/14:18:54

Message-ID: <c=US%a=_%p=Hassler_Communic%l=DAISY-970531181543Z-332@daisy.hcst.com>
From: Bryan Murphy <bryan DOT murphy AT hcst DOT com>
Cc: "'djgpp AT delorie DOT com'" <djgpp AT delorie DOT com>
Subject: RE: Quake vs. Demos
Date: Sat, 31 May 1997 14:15:43 -0400
MIME-Version: 1.0

>> C++ does not suck.  It simply is not the ideal language for all
>> situations.
>
>True.  The same is true of any language, for that matter.

Actually, the truth is no language sucks if the programmer is good.
(Well, maybe with the exception of Cobol, but that's just personal
bias).  If the programmer sucks, the language sucks.  If the 
programmers is good, the language is good.  Like guitar.  No matter
how crappy your guitar is, if your a good player you can make it
sound great.

(this next snipet from the message for the one I replied to)
>> If you try to code a procedure oriented program, such as a game, with it,
>> 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.  
>
What is wrong with doing Procedural oriented programming in C++?
Nothing.  All C++ is is an extension to C that supports OO conventions.
You are not forced to use them.  Usually it's not worth it to do it in
C++ because you get extra portability by doing it in C, but there really
is no loss by doing it in C++.  In fact, if you ask me you gain from it
becaues of C++'s stricter typecasting and extra features.
>
>> 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.  You cannot write one part of the program 
>> without understanding the rest of the program, and that's impossible.
>
>Rubbish.  You write it as modules, with defined interfaces, and test
>each part separately and put them together.  If the interfaces have
>been defined correctly, and people have implemented them as defined,
>there's no problem.

If Einstein can understand Relativity, we can understand some large
projects now and then, and somebody out there can understand a lot
more than the average person.
>
>"Object Oriented" is simply the latest in a series of fads in 
>programming.  Certainly it has its uses (I use it myself in some 
>programs) but it's equally certainly not necessary for all large
>projects.

Actually, I have to disagree with you on this last point (I agree with
everything else you said about C++).  Object Oriented programming
isn't a programming fad, it's a way of thinking about programming.
Even if you don't write an OO program, you can still write a program
using OO's methodologies, and these are where it really has its
benefits.  The Object Oriented languages are just languages with
special conventions that allow the implementation of OO concepts
easier in the software.  Seriously, if you ask me, Object Frameworks
are the future.   I don't think any serious large project in a few years
time is going to survive without frameworks.  Frameworks provide
some amazing code reuse possibilities and anybody who is stuck
programming procedurally is going to be left out in the cold.   Look
how nobody programs with Win32 SDK anymore, they all use
MFC.  You could never accomplish what you can with MFC using
just the Win32 SDK.

- Raw text -


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