Subject: Re: Database Midware Software For the Web Sat Apr 10 05:38:59 1999 > > 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.