Just to add a little to the "hell bent on OO"
Actually the statement "OO is slower than procedural"
is a murky one to make at best and flat outright WRONG
at worst.
C++ is a poor implementation of an Object Oriented language.
Java is better, Javas implementation also has its drawbacks.
However combining a natively compiled language as a standard
with a native executable compiler and I feel real sure that
C++ applications can run as fast as a procedural counterpart.
The problem is a language such as C has had over 20 years to
mature and there is so much out there and so much practical
use and experience with C compilers that they are very highly
optimized, especially on x86 platforms (MSVC++ is the fastest
on windows).
The point is OO in theory can be just as quick if not quicker
than a procedural compiled language. The programs dont take
up any more memory or more "processing" power to run, that
entire line of thinking seems a bit asanine to me. Like
saying this marble rolls faster than that one because
it is red.
Even given that most implementations all have their problems
give them time to mature, in the mean time enjoy the ease
of use of OO.
As far as game developers, I feel games fall into one of
those special categories that the rest of the world doesnt
really apply to (kind of like dave said :)))
Example: Just yesterday I had to hand optimize my graphics
drawing routine in assembler to gain that edge in performance
on my CF app... *NOT* hehe.
Of course game developers arent going to want OO, if you
downloaded the source to QuakeI (which is GPL'd) you would
see that it is all written entirely in C and it cuts corners
using the forbidden "goto" keyword ;), and several as low as it
gets graphics drawing routines in assembler. Business
apps dont need the speed.. period. And a lot of the code is
sped up and when you optimize things you tend to make things
a little scarier, like reading assembler is harder than
reading C, and using two or three goto's even well commented
can obscure the purpose of the code even more. I just
dont see how writing reusable components with (currently) a
minor performance hit that can be easily negated with
proper configuration and a little more hardware, makes
OO a suddenly invalid method. I always have seen this
debate and my question at the end of it is, what SHOULD
we use if OO is so crapy? Go back to writing strictly
procedural code so that that financial record loaded
a half a second quicker but now the code is more complex
and prone to contain errors, is that a "solution" to the
"problem" that is OO programming?
Jeremy Allen
[EMAIL PROTECTED]
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 02, 2000 12:07 PM
To: CF-Talk
Subject: RE: Fusebox [CF-Talk]
> Why are people so hell bent on OO, lets face it OO seems to
> be a good idea. But good ideas cost us in the long run. Lets
> look at c++ for instance, before c++ was introduced programs
> where smaller memeory wasn't and issue and hard drive space
> either was not an issue. Then somwhere along the lines we began
> coding with OO, then we needed 10 times as much memory and now
> we need thousands more hardrive space.
People are "hell bent" on OO because it solves quite a few problems, and in
cases where it's the appropriate answer, the fact that OO code is less
efficient from a performance standpoint is outweighed by its advantages.
> Ask a games developer what the prefer and you will find that
> they opt out of oo big time, remember that when you inheret a
> class you inherit everything about that class everytime you
> need it. So this means that the code runs slower becuase it
> has more work to do, it becomes larger because it has more
> code that is compiled that is maybe not needed.
While I respect game developers as much as anyone else does, asking a game
developer what they prefer is relevant if you want to develop games, but not
necessarily if you want to develop business applications.
Game developers build applications which fit within a specific niche - where
performance and efficiency count more than anything else. They can't afford
to waste resources in storage or calculation.
Business developers, on the other hand, build applications within a
different niche - where maintenance and extensibility count more than
anything else. They can't afford to build applications that are so low-level
and tightly written that they can't be maintained.
I'm a big fan of Quake, but I don't think people will be playing it twenty
years from now. A successful business application may well be in existence
that long, or longer - just ask all the COBOL developers who were patching
applications last year!
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
----------------------------------------------------------------------------
--
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
