> > You could use the standard C API that comes with MySQL. It
> > will be faster than an interpreted language like Perl or PHP
> > or Python.
>
> I am very curious. I have not programmed in C. 99% of my
> experience is with perl. I am of the impression that the same
> functions can be programmed in perl in much less time than in C;
> a programer using perl could get the same work done in say 50%
> of the time needed to do it in C.
that's a dangerous comparison.. there are many factors in
development speed, and choice of language is only one of them.
it's well documented that there are order-of-magnitude
differences in productivity between programmers with identical
resumes, working in the same language, and on the same project.
both IBM and NASA have done such studies, and the results were
the same both times. some people get ten times as much done as
others, even when they're in neighboring cubes.
when you factor in the difference between someone who knows the
problem domain and somone who doesn't, you add another one or
two orders of magnitude. it's entirely possible for a
programmer who knows the moves to whip out a piece of code in
1/1000th the time of one who's still trying to learn the moves.
i'm not kidding, either.. the 1000:1 difference is 1 minute vs
16 hours. a one-liner for Ralph, and two work-days of
tinkering for Fred. if you count the absolute time, as in
"when can we ship?" (which is *precisely* how the marketing &
finance departments measure things), those sixteen hours will
all take place in one stress-filled day of overtime.
the upshot is that when one programmer can be a thousand times
as fast as the next, in the same language, comparisons between
different programmers in different languages get just a bit on
the loose side.
in very broad terms, interpreted languages tend to be faster &
easier for small (less than 5000 executable statements)
programs, and execution environments which can absorb a lot of
slop. compiled languages, by contrast, tend to be better for
large programs, and execution environments where overhead needs
to be minimized. if you're going to base your choice of
language on anything, ask yourself how much an extra tenth of a
second really matters.
CGIs, on average, tend to fall in the category where interpreted
languages are strongest. even it your script is being hit
100,000 times per day, that only averages to 1 instance per
second. most of today's server hardware can handle that
without noticing. in that context, the benefits of fast
one-liners and easy updates outweigh the additional overhead.
the value of single-line power decreases as the size and
complexity of a program increase, though. translating the
Apache source tree over to perl wouldn't make that code any
easier to develop or maintain. for projects of that size,
well-defined subsystems and interfaces are more important than
how much you can do on a single line. meanwhile, the overhead
of the interpreter increases geometrically with the program's
size, so a perl version of Apache would be less desirable than
the current version in C.
'development speed' and 'efficiency' are topics programmers tend to
toss around like frisbees, without ever linking them to specific
issues of the job at hand. among the possible things that can
be defined as 'good' in code are:
- freedom from bugs
- richness of feature set
- speed of development
- portability
- readability
- ease of maintenance
- ease of upgrade
- execution speed
- efficient use of system resources
most of which are mutually exclusive. code that screams is
usually unreadable, almost always a resource hog, and only
portable through the purest of luck. the same is true for
programs written in a code blitz, except those generally aren't
very fast, either. portable code is slow as hell to write, and
usually plods along in execution, but it tends to be less buggy
and easier to maintain & upgrade. the list goes on ad nauseam.
part of the implementation programmer's stock in trade is
choosing the tradeoffs which fit the circumstances of the
current project. i've personally never seen a webserver that
consistently runs at more than 5% of its capacity, so i doubt
the added speed of the C library for MySQL would be sufficient
to justify it over perl in most cases. OTOH, if you already
like coding in C and are familiar with the library, i see no
reason to drop it in favor of perl.
in general terms, the best program is the one that's in
production and not giving you problems. whatever language &
utilities get you there are good enough.
BTW - Camille:
in answer to your original question, i doubt you'll find a
non-geek oriented piece of middleware that offers you good
flexibility. i'll second Steven's suggestion for PHP.. it's a
good package which emphasizes template-driven database
interaction.. but if you're doing anything complex, you'll
probably want to find a geek.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
