[rescue] spam WPOISON
Curtis H. Wilbar Jr.
rescue at hawkmountain.net
Mon Sep 8 16:27:16 CDT 2003
>From: Dave McGuire <mcguire at neurotica.com>
>On Monday, September 8, 2003, at 04:42 PM, Curtis H. Wilbar Jr. wrote:
>>>> For this application I wouldn't even consider C.
>>> I would.
>> Err... your choice... not right, not wrong... just a different
>> (and for this app, not my choice)
> The "right tool for the job" is not usually a matter of opinion.
Maybe I was too emphatic when I said I wouldn't consider C... however
it would not be my primary choice for this task. Maybe if I had the
hit rates in it some monster sized sites might have then it would justify
it and I would consider doing so... but for what most would see the
efficienty of speed is not necessary for such an application. I really
don't think that C is going to do the job so much more amazingly well
such that it is necessary for this task.
>> Given a running webserver with a memory resident language choice (Perl,
>> PHP, possibly others), I would use that technology because it is
>> there, and
>> it is resident. It may not be the fastest, but speed is not
>> There is the overhead of file handles, process management, memory
>> etc.... the fastest solution is not always necessarily the best
> Where computers are concerned, assuming the job is being done right
>(i.e. good error handling, etc) the fastest solution usually *is* the
I would say that this is an opinion (yours to be exact), and not necessarily
What about maintainability ? What about portability ? What about
development time ? etc... the decision of what language to use to do
the job "right" is not simply a decision of program speed or efficienty...
their are other factors.
>> Doing text processing in Perl or PHP is friendlier and more enjoyable.
>> don't potentially need to deal with memory management issues, the
>> is resident (in the case of modPerl and PHP), etc. Seems to me more
>> to the task at hand than C.
> You write it once, and you run it potentially billions of times. In
>recent years, there has been a very disturbing shift from "use language
>xyz because it's better suited to the task" to "use language xyz
>because it's easier". The notion of programmer time being more
>valuable than CPU time has always been bogus, and in this suit-fucked
>economy with half the professional programmers on this list being
>unemployed, it's even MORE bogus.
I was taking the efficiency thing to an extreme to make a point.
Sure, 'C' is portable in a source form, but if you were making the solution
and were not going to distribute source, you could write in assembly for
each target platform you chose to support... maximal efficienty... maximal
Depending on what you want to do with a program, the effort to do it in
C "efficiently" can be much greater than doing it in another language
(like Perl, PHP, etc) in less time and with more readability, maintainability,
and possibly with less debugging (as some languages make things much
easier to do than doing it yourself in C).
Time to market, etc is not important ? Maybe not from a technical aspect,
but from a business aspect it sure is. I'm not a "suit", but if you gave
me the choice in a hot market to put the procut out with language X at
1000 development hours, or language Y at 500 development hours, and both
would be perfectly up to the task and will perform properly, and adequately,
etc... why would X be picked ?
> Do it right...or don't do it at all. Multiple programming languages
>exist because no one language is the best tool for all jobs...not
>because no one language is the easiest. There's a reason, for example,
>why the language of choice in the HPC and scientific communities after
>all these years is still FORTRAN, which the "all computers are either
>web servers or web browsers" crowd seems to think is obsolete.
So maybe for this task, PHP is the best language for the job. I echo
that there is no one language good for all jobs. I don't believe the
C is necessarily the best for this job (that we were discussing).
Fortran is not obsolete as far as I'm concerned... although in what I
do (currently) it has no place... but I believe it has a place.
>> BTW, if you want this to be really efficient, code in native assembly
>> even better... in assembly as a Apache module. The ultimate in
> That'd make it nonportable. If Jon writes it in MIPS assembler on
>his SGI, I'd not be able to run it on my web server, which is an
>UltraSPARC-II. The ultimate form of ineffeciency is uselessness.
Depends on your target "market". If your in control of the source, and
the platforms you choose to support, you could write it several assembly
languages for several web browsers... maximal efficiency... (maximal
effort too... however if you had an app that was this on the performance
edge... this might actually be the best solution :-) ).
Hawk Mountain Networks
My e-mail is protected against viruses and spam by MailGuardian
Top notch protection at unbelievable prices
More information about the rescue