[NCLUG] programming question

[mike cullerton]

on 7/1/01 8:08 AM, Gary Rogers at garyr at dmin.net wrote:

> Well, I'll say this from a person who's had to run hurd on web programmers,
> find bottle necks and make them believe that it's their code...
> 
> When dealing with the web remember that most of the languages/application
> servers out there are interpereted languages, then have to be compiled at
> runtime everytime you take a page hit. It doesn't matter too much if you've
> got a very clean oo program, or a scruffy perl nugget, it's still going to
> spike your processor on a page hit. You can get away from this by using java
> servlets, or compiled c. Of course then the servlet engine introduces
> overhead ;)

true, but all programs use processing. my concern is including a fundamental
flaw in my program that isn't noticeable during development but rears it
pointy head when thousands of folks are accessing the application.

> 
> If you have a set standard to develop and write to, that's probably more
> important than the speed and effiency of your code. An ounce of
> maintainability is worth more than a pound of 'OO'. If you code is
> maintainable by someone else written in 'oo' cool, if it leaves your
> replacement scratching their heads, it's not worth beans.

i'll agree that, other things being equal, well documented, well organized,
well written code is a good thing. however, i'm guessing that well
documented, well organized, poorly written code probably isn't a good thing.

> 
> In my experience writing CGI's and system support scripts copious
> documentation and well-thoughtout procedureized code is where you want to
> go. Breaking everything out into multiple subs/functions/procedures that
> each do a small manageable bit of work is best for maintainability and
> code-reuse, it's 'oo' like without having to fully implement objects and
> inheritance and such. Now that said I understand that there are places for
> objects and 'oo', but you've got to ask yourself, in my current coding team,
> or the person that tinkers with thise code after I've moved on (and believe
> me the smallest little thing could be used again) will they understand my
> code and be able to easily modify it? If you can answer yes then your code
> is efficient.

[whether or not to use oo for this project isn't up for discussion. the
assumption here is that we are using oo. even if only to learn about it.]

you appear to be using the term 'efficient' in a different manner than was
intended. i meant runtime. you appear to mean coding time.

however, as other folks are pointing out, it is this human time that may be
more important. what i'm gathering from this discussion is that it's
important to make choices that allow the program to be readily written (and
maintained) as long as there are no fundamental flaws in the program's
design. one can always tweak a program for greater efficiency, but is it
really necessary and what other project could you be working on instead :)

> 
> As for Keynote, don't diss the 'Note! They've saved my bacon more than once
> when I could go to the programmers and say 'see your page is taking 3
> seconds to load.' and go to the security guy and say 'see your firewall is
> causing initial connections to take 3 seconds'.

hey gary, i'm not really a soldier in this war, but let's just say that most
folks who run major networks aren't big fans of keynote :) for more info you
can search archives of the nanog (north american network operators group)
and inet-access lists.

:)
mike

> 
> g:wq
> 
> ----- Original Message -----
> From: "mike cullerton" <michaelc at cullerton.com>
> To: <nclug at nclug.org>
> Sent: Saturday, June 30, 2001 5:11 PM
> Subject: Re: [NCLUG] programming question
> 
> 
>> on 6/30/01 4:30 PM, Gary Rogers at garyr at dmin.net wrote:
>> 
>>> Are you sure that your time is spent in the application? Here's what I'm
>> 
>> 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.
>> 


 -- mike cullerton