[MUD-Dev] Languages

[Nathan Yospe]

On Thu, 22 May 1997, Caliban Tiresias Darklock wrote:

:On Thu, 22 May 1997 19:23:19 PST8PDT, Ben Greear
:<greear at pollux.cs.uga.edu> wrote:

:>Also, while you can do it all in c, classes and member functions, 
:>especially destructors and constructors are nice shorthand.  

:Yes, but hey... it takes very little thought and effort to build
:something similar in C. Most of my structures carry with them the two
:global functions 'makeX' and 'killX' that take care of all the init and
:destroy requirements. 

True, but there is no simple way to handle complex polymorphism, or the
more advanced applications of template libraries. You are aware that it is
impossible to write a CFront type C++ -> C converter for the current draft
standard? Incidentally, we've been through this whole argument before on
the newsgroups with Katrina. She also proved more opinionated than
informed. Its a rather pointless argument, anyway... You'll never convince
me to go back to C, and I don't really care if you start using C++. This
is generally the case... you will either end up in a heated, pointless
argument with members of other code religions, or in vapid agreement with
members of your own, or being patronized by code agnostics. (Yeah, I'm
slightly religious. I prefer OO, and use it even with procedural
languages. I don't do it because procedural is the devil, I do it because
OO is easier to wrap my brain around. At least for large projects, which
this mud and most of what I do at work count as.)

:>I'm curious about some things.  What exactly makes c++ slower?  Is it 
:>more class calls because most ppl make accessing class data a function 
:>call?  Perhaps inheritance mapping of some sort?  I head that a c++ 
:>compiler basically just translates the code into c before compile anyway..

:The problem I see in projects built using proper OOP in C++ is that the
:same data is validated over... and over... and over... and over...
:because none of the objects can make any assumptions about the others,
:so they can't ever take for granted that someone else has validated the
:data. If they did, they'd break the whole reuse thing. 

That's all done in the compilation/linking stage. Its called inlining.
Nice concept, that, and another reason I prefer C++. Of course, it does
bring to light a major difference between a clueless interpretation of
what the books say, and what an experienced programmer learns after some
time. DON'T use access functions! (get/put). True, inlining makes them
costless, but the truth is, until you stop using them, you are still in
essense a procedural programmer trying to write OO code. There is always a
more efficient and safer method than access functions. Personally, I
prefer message passing and verification. The point is, access functions
are pretty much a confirmation of the inner mechanics of the class, or the
kludged up remains of a class that was modified with extreme difficulty to
still handle those access functions when the accessed variables themselves
have been changed. Last time I considered maybe taking a CS class (I've
never actually taken one) I sat in on one of the last week classes before
signing up for the next semester. The course was object design theory, and
the prof was using access functions. After the class ended, I confronted
him about it, and he didn't know what he was doing wrong. I walked out and
signed up for another math course, in chaos. Much better. 

:>I concur.  And to be honest, the only code I reuse is my own, but perhaps 
:>if I was willing to wade through more manuals, and more libs were free
:>(and came w/a good manual) I'd use other ppls.  Fortunately 4 yrs of 
:>school have yielded several good classes to work with :)

:My time in school yielded very little applicable to much more than
:mainframe COBOL. The fast and loose style of C fits me; I get to do all
:the dirty work myself, because I *have* to, and that keeps me
:interested. ;)

I think this highlights the difference in styles. The reason I use C++ is,
when confronted with a large project, I refuse to include any hacks,
spaghetti, or feature specific code. I can toss off a project like that
(such as a mud) in C++ in a fourth the time it takes me to do it in C.
Were I big on hacks, on dirty work, as you put it, I suppose C would be
more my style. My time in school has yielded no programming skill, that
was all work and my own time. School yielded some VERY powerful math and
physics skills. Still continues to do so, and when they get powerful
enough, I can leave computers behind and work on more important things.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu