[NCLUG] programming question

[J. Paul Reed]

On Sun, 1 Jul 2001, mike cullerton wrote:

> i was wondering when you'd pipe in :)

You know me... I'm always around, lurkin'...

> [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]

You know, Cal Poly is going to be the 2nd school in the nation to offer a
software engineering degree, which is distinctly different from a computer
science degree.

I just thought I'd throw that in there because I thought it was interesting
that the engineering of software is really becomming a different area from
computer science.

> 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.

Hrm... well, then it would make sense that you would want to separate those
somehow.

One thing I've noticed as I do more OO-type design is that some things fit
really nicely i.e. messages (which can be subclassed by message type),
database connections (which can be subclassed by DB type), etc., and
sometimes, you end up getting these objects that don't make sense, such as
a "registration engine" or an "event loop engine" that represent a sort of
"manager" of other smaller object types and become points of execution for
management of those objects.

If you're really looking to do OO design well, you may want to take a look
at the standard book on the subject, excitingly titled "Design Patterns."

http://www.amazon.com/exec/obidos/ASIN/0201633612/o/qid=994017003/sr=2-1/102-3124347-5552128

> 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?

I think you can get a lot of the tenets of OO by doing procedural
programming and using good APIs, but at some point, you do hit a wall.

One of the things that OO languages (typically) give you is polymorphism...
that whole idea of "one object IS-A another object." You can't do that with
procedural languages (well... ok, you can, but it quickly gets confusing
for large scale projects and, assuming you do it in C, you end up faking a
lot of the built-ins in the C++ language).

> 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.

That the biggest difference/benefit of OO; a professor of mine says that
most programmers who've been doing good ol' C (or the like) for 10 or 20
years don't really want to take the time to learn and embrace OO because it
really is a different way of thinking about solving problems.

When you have someone who refuses to do that, lots of bad things in code
happen, and ironically enough, these types are the types of people who are
prone to say "C++ is slower, C++ sucks, blah, blah, blah" because they're
using the language... well... incorrectly.

As an anecdote, another one of my professors has observed something when
students are doing Java development that he calls the "static creep": the
compiler will complain that any functions that main() calls must be
declared static, because main() is static; so, instead of doing OO the way
they're supposed to, students end up turning Java into a procedural
language because the just go through and label all their functions static.

> > 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?

Well, as Charles said, it can be faster; I would argue that most of the
time, it just ain't, either due to misuse of the language or the fact that
it's just not.

If you're correctly using encapsulation and polymorphism, it's just a fact
that it takes cycles to look up the correct function in the v-table and
follow all the function pointers so the object calls the right function.
And then there's Java... which, like it or not, is just slower. Remember
how everyone complained about this when Java was first introduced... now
it's not as big a deal because the Java runtimes have gotten better but
more noticably because we've all got faster hardware now.

> > 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.

Well... we'll see... assembly is first on my list next quarter... you may
see me at the meetings half way through next quarter as well. ;-)

Later,
Paul
  ----------------------------------------------------------------------
  J. Paul Reed                preed at sigkill.com || web.sigkill.com/preed
  Homer no function beer well without.  -- H. Simpson, "The Joy of Sect"