[NCLUG] programming question

[mike cullerton]

i was wondering when you'd pipe in :)

[just to make sure people know where i'm coming from, i've had no formal
training in programming except for 2 general pascal classes required for my
math degree 15 years ago. all my coding to date (which hasn't really been
that much) has been procedural. this current project is in php]

on 7/1/01 2:04 AM, J. Paul Reed at preed at sigkill.com wrote:

> On Sat, 30 Jun 2001, mike cullerton wrote:
> 
>> this is a theoretical question. i'm wondering, is there a difference, in
>> general, programmatically speaking, between having one large object, two
>> disjoint objects or an object that extends another object.
> 
> I think Charles was right on when he said it depends on the language, and
> also what exactly you're doing (which sounds stupid at first, but, in other
> words, how are the object communicating with each other, how often, and how
> do they make use of each others' facilities?).

this is kind of what got me to ask the question in the first place. user
code will be run on every page. registration code will be run much less
frequently. i wondered how the different approaches could take advantage of
this fact.

> 
> What I was going to point out is an extension of Charles' point on the
> language you use: if you consider C vs. C++ (and actually, most OO
> languages), there is a speed difference between the two.
> 
> Those who push OO do so because the practice (done correctly) supports code
> re-use, object-level testing, encapsulation, interfaces, and a host of
> other goodies all very well. Put another way: OO languages make the
> computer work a bit harder to the benefit of us human programmers, because
> (now), the largest expense is a human's time, not a computer's.

another question (or as plato says, a digression). i don't mean to start a
holy war here, but can't most of this stuff be done with procedural
programming and good api's? what is it that oo gives you that procedures
can't? oo has forced me to think about my programs in a different way which
has benefited all my programming. it also helps me organize my thoughts
somewhat as to what is actually going on with each piece of a program.

> 
> So, I would say that you should write the classes in whatever way makes
> the most logical sense for encapsulation, code re-use, the specific
> application, and most importantly, you and your colleagues.

which is kind of where i was heading when the question popped into my head.
i want the code to be understandable while remaining funtional.

> 
> Because once you've taken the leap to do OO, your code is going to be a bit
> slower anyway (whether it be C++, Java, or icky-disgusting 'OO' Perl)...
> you might as well do the "right thing" (tm).

is this really true? does oo in general make code a bit slower? in any real
perceivable manner?

> 
> And, of course, you can always optimize your code at the class level later,
> once you have built the thing and do some profiling on it.

folks have mentioned this a couple times. what is meant by profiling?

> 
> I mean... if we wanted everything unbelievably fast, we'd write everything
> in assembly... :-)

ack! i remember all the cs majors saying that assembly was the class they
used to weed folks out of the program. kind of like 5 hour calculus at 7am.

> 
> Later,
> Paul

 -- mike cullerton