9 Feb
2010
9 Feb
'10
6:14 a.m.
On Tuesday 09 February 2010, Dave McGuire wrote:
On Feb 8, 2010, at 7:32 PM, N0body H0me wrote:
That's certainly an issue. I wonder how many applications are
slower and more overweight due to their being crafted with OOP than
they would be if they were coded using more traditional methods.
"More traditional methods"? Just "the way processors execute
code" would be a good start. Processors aren't object-oriented in
nature. This is one of the reasons why we have computers with multi-
GHz processors that barely get out of their own way. The constructs
commonly used in OO programming don't come anywhere close to mapping
to hardware efficiently.
But, isn't the point of programming languages to make it easier for the
programmer to create programs? Computers are fast; people are slow.
Have you ever tried writing code against GTK (not-quite-OOP jammed into
C) vs Qt (real OOP using C++)? GTK is such a pile of sh*t to try to
write code for, in my opinion.
Now, I'm not saying that I appreciate OOP in every case, but it seems to
be darn useful when writing GUI-based applications. Oh, and don't
forget that most of the code on running your favorite Mac was written in
Objective C...
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Here, here. The thing that impressed me about FORTRAN
(well, as
as science major, anyway) was that it could do complex numbers as
a *NATIVE* datatype!! Now, I know for you OOP and C++ guys,
custom, exotic datatypes are a dime a dozen. But in 1980, I was
sure glad I could do complex math without all of the extra
baggage that would have been necessary if I had to use, say,
BASIC-Plus.
Yeah, but how often do those C++ custom exotic datatypes map to
real datatypes supported by the hardware? (in other words, which
ones will actually be FAST?)