«

On 2009-04-28 16:31, Charlton Wilbur <> wrote:
>>>>>> "PJH" == Peter J Holzer <hjp-> writes:
>
> PJH> If you have a bad SQL join it is completely irrelevant whether
> PJH> you call it from PHP or Perl or C, and whether your PHP/Perl/C
> PJH> code is in turn invoked by a request from Firefox or Opera or
> PJH> IE. All your PHP/Perl/C code will do is wait while the RDBMS is
> PJH> slogging through gigabytes of data, and all your browser will
> PJH> do is wait for your PHP/Perl/C code.
>
> Which touches off another argument: even if you have a *good* SQL join,
> and your database is perfectly tuned, the I/O will still probably take
> an order of magnitude more time than any computation you do with the
> data.

Most of the time, yes. But I've seen cases where a perl process consumed
nearly 100 % CPU time in a loop like this:

while ($r = $sth->fetchrow_arrayref) {
set_bit($r->[0]);
}

Here the database was able to deliver rows a lot faster than perl was
able to process them, even though the processing was rather simple.

hp

>>>>> "MV" == Michael Vilain <> writes:

MV> Yes, companies can just "buy bigger computers" but at some
MV> point, that's a waste. Guess you haven't gotten the memo that
MV> companies aren't buying new systems right now. They want to
MV> extend the use of their systems another couple years.

Consider this scenario.

You go to your manager, and say, "We could develop this new project in
C, which will take a team of six programmers six months, and we predict
that it will require one server at a cost of $2000 to run. Or we could
develop it in perl, which will take a team of six programmers five
months, but we predict that one server will not be sufficient at peak
load, so we recommend two servers at $2000 each."

Question 1: How much would the programmers have to be paid per year
before choosing C would make financial sense?

Question 2: Given that your programming team is probably making a lot
more than that, how likely is your boss to go for the C solution?

That's the sort of programmer time versus computer time tradeoff that
Uri is talking about. Computer time is *cheap* compared to programmer
time. This is not an argument in favor of never optimizing, but it's an
argument in favor of using tools that reduce programmer time investment
even if they increase computer time investment.

Charlton



--
Charlton Wilbur

Uri Guttman wrote:

>>>>>> "NK" == Nathan Keel <> writes:
>
> NK> Uri Guttman wrote:
>
> >> it also shows you have no clue about what is important these
> >> days. development time is way more expensive than running time.
> >> you can always get a faster computer but you rarely can speed up
> >> a development schedule.
>
> NK> If you know the language, development time isn't an issue, so
> comparing NK> an experience C programmer (whom will have libraries
> (their own), NK> template scripts, etc. to re-use, unless they are
> an idiot) and compare NK> it to an interpreted language and
> development time, it's likely not
> NK> going to be a whole lot different. And, the compiled code, if
> it's NK> written well, will easily out perform the interpreted code.
>
> study some computer history and come back when you have finished.

Please don't resort to acting like your view is fact and anyone that
doesn't agree with you is somehow ignorant. I "get" what you've said,
I just don't agree with it.

> have
> you ever worked on a computer which actually accounted for your cpu
> time? you don't understand my point which is well known and
> supported. cpu time used to be the major expense in those days,
> developer time is the major expense now.

That's only true to a point. Many things have changed since the 60s and
70s. Indeed, we have a lot less to worry about as developers, but
that's no excuse to be lazy or stubborn about the topic. Certainly you
must agree that some compiled programs are much better suited for some
situation and applications? If so, you can't really knock C because
Perl is quicker to develop in.


> NK> I quickly turned down the guy's offer, because he said exactly
> what you NK> did above "If people want the program to run faster,
> they can get a
> NK> faster computer". That's an awful and often ignorant attitude.
> Never NK> settle for code that's inefficient for the sake of a quick
> turn around
> NK> time. Perl is my favorite language, but if I care about speed
> (and I
> NK> mean really care), I'll plan to write it in C. If you are
> speaking NK> from experience and how "in the real world", it's
> important to consider NK> that you won't get jobs if you want to
> create the best programs, that's NK> one thing, but hopefully not
> many people have to work for shitty NK> companies that are that
> clueless (or people above them that force them NK> into that
> situation due to lack of planning or understanding the
> NK> project). But, to each their own. I just hope I never end up
> having NK> to work for someone like that, and luckily I've always
> been able to NK> tell them to f--- off.
>
> you don't get it.

I actually do, I just don't agree with your arrogant attitude.

> study some history as i said. computer power is dirt
> cheap today.

Yes, it is, but there are still limitations. If you think that slow
programs are fine, and say people should get faster systems if they
don't like it, then you're not as smart or knowledgeable as you
(clearly) like to think.

> cheaper than you realize.

Apparently you claim to know what I realize about prices on systems and
components, too? Be arrogant if you want, but don't say stupid things.

> developer cost is way more
> expensive.

Probably, yes. However, that doesn't automatically mean it's either A
(hardware) or B (development time). You MUST understand there's a
middle ground, where you want efficient and suitable code, regardless
of the hardware aspects?

> so buying more/faster computers is usually more economical
> than hiring more and better developers.

Or when any idiot can create an inefficient program that uses up all of
the CPU and/or memory and/or system I/O and your theory about faster
systems falls on its face. Plenty of people suck at coding and people
also make mistakes (in code or the design) and these things just mean
that it takes 20 minutes to crash a "faster" system, than the 5 minutes
it takes for it to crash a slower system.

> of course this isn't always
> possible but it is a very strong rule of thumb. and note, i am a speed
> freak coder.

If you say so.

Anyway, you certainly must agree that it's not always the best or viable
solution. I think that's a careless rule of thumb. My code is not
really any longer to develop than other peoples, and my code runs fast
and efficient on any system. I don't agree with the rule of getting a
faster system to account for inefficient or poor coding choices.

> most of my cpan modules (id: uri) are about doing things
> as fast as possible. and they usually succeed.
>
> for a starter, read the mythical man month.
>
> uri

I've read it. I've done research. I've been coding for a while (even
if not as long as you might have, I really don't know or care). I
still disagree. I think it's arrogance, ignorance, carelessness and
laziness that accounts for every situation where people's "solution" is
to upgrade a system when it's not otherwise necessary. Sometimes it
is, but if you have to because of a design choice, slow code, or choice
of language, then you should probably find a new line of work if that's
your general, generic "rule of thumb".

On Wed, 29 Apr 2009 16:16:22 -0400, Charlton Wilbur <> wrote:

>>>>>> "MV" == Michael Vilain <> writes:
>
> MV> Yes, companies can just "buy bigger computers" but at some
> MV> point, that's a waste. Guess you haven't gotten the memo that
> MV> companies aren't buying new systems right now. They want to
> MV> extend the use of their systems another couple years.
>
>Consider this scenario.
>
>You go to your manager, and say, "We could develop this new project in
>C, which will take a team of six programmers six months, and we predict
>that it will require one server at a cost of $2000 to run. Or we could
>develop it in perl, which will take a team of six programmers five
>months, but we predict that one server will not be sufficient at peak
>load, so we recommend two servers at $2000 each."
>
>Question 1: How much would the programmers have to be paid per year
>before choosing C would make financial sense?
>
>Question 2: Given that your programming team is probably making a lot
>more than that, how likely is your boss to go for the C solution?
>
>That's the sort of programmer time versus computer time tradeoff that
>Uri is talking about. Computer time is *cheap* compared to programmer
>time. This is not an argument in favor of never optimizing, but it's an
>argument in favor of using tools that reduce programmer time investment
>even if they increase computer time investment.
>
>Charlton

That is total bullshit. Nobody uses C in large comercial applications.
C alone is not even used for development anymore. Legacy C library's stay intact,
and can be called from C++, but nobody uses C for new development, not even for
embedded/real-time stuff.

Perl is not used in comercial applications. Its uses are in a small niche and are
not sold because of its extreme limitations in speed, functionality and incomprehensible
syntax.

Perl is just a wrapper on the C language itself, or hadn't you noticed?
Even the mighty Expat library, written in C, the fastest flat xml parser in existence,
is 5-10 times slower when called from a Perl wrapper, the Perl interface to it.

You talk about development time and how expensive it is. You talk about buying more
cpu's. Thats absolute insanity. Your actually talking, in a 'macro' sense, what,
'distributed processing'? Sort of like, what, 'pipelining' macro code?

So let me get this straight, Perl is going to take over anything done in hardware,
specialized, like parallel matrix processor's.

Don't make me laff.

-sln

Uri Guttman <> wrote in
news::

>>>>>> "NK" == Nathan Keel <> writes:
>
> NK> Uri Guttman wrote:
>
> >> it also shows you have no clue about what is important these
> >> days. development time is way more expensive than running time.
> >> you can always get a faster computer but you rarely can speed up a
> >> development schedule.
>
> NK> If you know the language, development time isn't an issue, so
> comparing NK> an experience C programmer (whom will have libraries
> (their own), NK> template scripts, etc. to re-use, unless they are
> an idiot) and compare NK> it to an interpreted language and
> development time, it's likely not NK> going to be a whole lot
> different. And, the compiled code, if it's NK> written well, will
> easily out perform the interpreted code.
>
> study some computer history and come back when you have finished. have
> you ever worked on a computer which actually accounted for your cpu
> time?

For a few years Haven't looked back ever since I was able to afford
my first PC.

In any case, I think the following article is somewhat related to the
point you are trying to make:

http://prog21.dadgum.com/29.html

Sinan
--
A. Sinan Unur <>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

Charlton Wilbur wrote:
>>>>>> "MV" == Michael Vilain <> writes:
>
> MV> Yes, companies can just "buy bigger computers" but at some
> MV> point, that's a waste. Guess you haven't gotten the memo that
> MV> companies aren't buying new systems right now. They want to
> MV> extend the use of their systems another couple years.
>
> Consider this scenario.
>
> You go to your manager, and say, "We could develop this new project in
> C, which will take a team of six programmers six months, and we predict
> that it will require one server at a cost of $2000 to run. Or we could
> develop it in perl, which will take a team of six programmers five
> months, but we predict that one server will not be sufficient at peak
> load, so we recommend two servers at $2000 each."

Did you account for the time needed to design this very complex system
so that it could seamlessly and efficiently spread the load over two
computers? Or is that why Perl development is only 17% faster than C?


Xho

Dr.Ruud wrote:

> Uri Guttman wrote:
>
>> you don't get it. study some history as i said. computer power is
>> dirt cheap today. cheaper than you realize. developer cost is way
>> more expensive. so buying more/faster computers is usually more
>> economical than hiring more and better developers. of course this
>> isn't always possible but it is a very strong rule of thumb. and
>> note, i am a speed freak coder. most of my cpan modules (id: uri) are
>> about doing things as fast as possible. and they usually succeed.
>>
>> for a starter, read the mythical man month.
>
> Uri, please stop wasting your precious developer's time on these
> types, because they will never get it.
>
> We could also discuss algorithms that run processes in parallel that
> wastefully produce overlapping results which are then merged and
> deduped in order to get the final result much much earlier then when
> we would let a speed addict touch it. But we can't discuss them if we
> are too busy implementing them.
>

If you think it's a waste of time to discuss programming in a
programming news group, and think it makes sense to not look for the
best language or best programmers, instead of worrying about comparing
system costs vs. development costs, then no wonder you two are so
confused. There's nothing to "get" here. It's a matter of what's
appropriate and what options you have available. Just dismissing the
fact that some languages are better suited when they are compiled (like
C compared to Perl) is dumb (if you actually think it's going to take
"that much longer" and cost "that much more" just to code in C over
Perl). It doesn't take "that much longer" if you know C well (and that
was just an example). Most of my stuff is coded in Perl and scales
well, but there's a point when buying systems to make up for the
efficiency is going to be futile. If you agree with this, then you
must realize that "these types" DO in fact "get it". There's no hard
and fast rule.

I feel sorry for anyone that thinks buying systems is an appropriate
solution for poor decisions, when the real development time in C over
Perl isn't that much different if you have experience, intelligence and
use existing and well tested modules, libraries, code and function
templates, etc. (just like any developer would do in any language).
Or, you can think like that and jump on the Ruby on Rails bandwagon and
have everything pre-packages for you in simple ways and just call
yourself a programmer when you're only using toys other people made for
you. Then what happens when you don't have a
neat.little.function(available)?

What happens when you find that the language isn't fast enough? You buy
another system because you wanted to avoid a couple more hours of
development costs? Or do you often work with unqualified C programmers
to believe it's going to be that much more expensive and time
consuming? There are variables here that say what's better suited, and
if people don't "get it", then regardless of their arrogance, they are
the unfortunate one's. It think it's pathetic that people have to nit
pick the details of the topic and act like anyone that strives to be
the best coder are just nitpicking trivial speed that you can "buy for
less". This is not a true fact in every situation. I don't see anyone
suggesting people rock the boat with the company they work for or
contract out to, or to drop some language that works efficiently enough
as is (such as Perl) and refuse to code in anything other than C or
something, but logic is logic and it's silly to say people "don't get
it" because they disagree with you with the "default" outlook about
development costs vs. hardware. No real programmer would think this
way, but maybe you guys are just old and jaded and think whatever you
think about any topic brought up here, that you know best and your
ideals are always best, too. You, too, can be wrong (and you are about
this).

wrote:

> On Wed, 29 Apr 2009 16:16:22 -0400, Charlton Wilbur
> <> wrote:
>
>>>>>>> "MV" == Michael Vilain <> writes:
>>
>> MV> Yes, companies can just "buy bigger computers" but at some
>> MV> point, that's a waste. Guess you haven't gotten the memo that
>> MV> companies aren't buying new systems right now. They want to
>> MV> extend the use of their systems another couple years.
>>
>>Consider this scenario.
>>
>>You go to your manager, and say, "We could develop this new project in
>>C, which will take a team of six programmers six months, and we
>>predict
>>that it will require one server at a cost of $2000 to run. Or we
>>could develop it in perl, which will take a team of six programmers
>>five months, but we predict that one server will not be sufficient at
>>peak load, so we recommend two servers at $2000 each."
>>
>>Question 1: How much would the programmers have to be paid per year
>>before choosing C would make financial sense?
>>
>>Question 2: Given that your programming team is probably making a lot
>>more than that, how likely is your boss to go for the C solution?
>>
>>That's the sort of programmer time versus computer time tradeoff that
>>Uri is talking about. Computer time is *cheap* compared to programmer
>>time. This is not an argument in favor of never optimizing, but it's
>>an argument in favor of using tools that reduce programmer time
>>investment even if they increase computer time investment.
>>
>>Charlton
>
> That is total bullshit. Nobody uses C in large comercial applications.
> C alone is not even used for development anymore. Legacy C library's
> stay intact, and can be called from C++, but nobody uses C for new
> development, not even for embedded/real-time stuff.

I know of plenty of people and programs in C. Your feelings about the
matter aren't fact. I'm pretty sure "somebody" is not "nobody".

> Perl is not used in comercial applications. Its uses are in a small
> niche and are not sold because of its extreme limitations in speed,
> functionality and incomprehensible syntax.

There are commercial applications in Perl, actually (but you're right,
probably not used in "comercial" applications).

> Perl is just a wrapper on the C language itself, or hadn't you
> noticed?

A "wrapper"? Seriously?

> Even the mighty Expat library, written in C, the fastest flat
> xml parser in existence, is 5-10 times slower when called from a Perl
> wrapper, the Perl interface to it.

That's an awful comparison.

> You talk about development time and how expensive it is. You talk
> about buying more cpu's. Thats absolute insanity.

I agree with you here. Maybe I should get my head checked or reconsider
my position? *fear*

> So let me get this straight, Perl is going to take over anything done
> in hardware, specialized, like parallel matrix processor's.

I get what they are saying and why, but they have also made a poor
argument for a "standard" reaction to a problem better solved on
another level (usually anyway). Though I can't argue if the person's
boss or contracted company has unreasonable demands or limited time
frames.

> Don't make me laff.

Don't make me get a DICtiontary.

>>>>> "NK" == Nathan Keel <> writes:

NK> Uri Guttman wrote:

>> study some computer history and come back when you have finished.

NK> Please don't resort to acting like your view is fact and anyone that
NK> doesn't agree with you is somehow ignorant. I "get" what you've said,
NK> I just don't agree with it.

then you don't get it. cwilbur also covered this. sorry but no more
lessons for you.

>> have you ever worked on a computer which actually accounted for
>> your cpu time? you don't understand my point which is well known
>> and supported. cpu time used to be the major expense in those days,
>> developer time is the major expense now.

NK> That's only true to a point. Many things have changed since the
NK> 60s and 70s. Indeed, we have a lot less to worry about as
NK> developers, but that's no excuse to be lazy or stubborn about the
NK> topic. Certainly you must agree that some compiled programs are
NK> much better suited for some situation and applications? If so,
NK> you can't really knock C because Perl is quicker to develop in.

you still don't get it. sorry. it is not about any particular
application. i wouldn't write an embedded rtos in 64k of ram with
perl. i would do it in assembler like i did on an lsi-11 back in
1980. hell, perl wasn't even invented back then. but given what i was
doing then on modern cpus, i would probably do it in perl as the cpu
speed is enough and the development time would be massively shorter. and
yes, i have also done those types of programs in c including a major web
crawler for northern light. so i know of something about development
time vs cpu power. can you make the same claim? me thinks not.

NK> I actually do, I just don't agree with your arrogant attitude.

no you are ignorant, vs my experience. NYAH NYAH NYAH!

now i will predict you will call me some more names. please do as it
will validate my ESP powers.

>> study some history as i said. computer power is dirt
>> cheap today.

NK> Yes, it is, but there are still limitations. If you think that
NK> slow programs are fine, and say people should get faster systems
NK> if they don't like it, then you're not as smart or knowledgeable
NK> as you (clearly) like to think.

check out my cpan modules. try to make them faster. please do and send
me patches. i will use them (if you can but you can't) and even give you
all the credit.

>> developer cost is way more
>> expensive.

NK> Probably, yes. However, that doesn't automatically mean it's either A
NK> (hardware) or B (development time). You MUST understand there's a
NK> middle ground, where you want efficient and suitable code, regardless
NK> of the hardware aspects?

boo hoo. you seem to be fighting for no reason. i never said any of
that. you don't get it again. it is the bigger picture.

>> so buying more/faster computers is usually more economical
>> than hiring more and better developers.

NK> Or when any idiot can create an inefficient program that uses up
NK> all of the CPU and/or memory and/or system I/O and your theory
NK> about faster systems falls on its face. Plenty of people suck at
NK> coding and people also make mistakes (in code or the design) and
NK> these things just mean that it takes 20 minutes to crash a
NK> "faster" system, than the 5 minutes it takes for it to crash a
NK> slower system.

MMM to the rescue. please read it. i think they have a version written
in 4th grade level english for you.

NK> Anyway, you certainly must agree that it's not always the best or
NK> viable solution. I think that's a careless rule of thumb. My
NK> code is not really any longer to develop than other peoples, and
NK> my code runs fast and efficient on any system. I don't agree with
NK> the rule of getting a faster system to account for inefficient or
NK> poor coding choices.

all rules of thumb are careless. that's why they are CALLED that. duh!!

>> for a starter, read the mythical man month.

NK> I've read it. I've done research. I've been coding for a while
NK> (even if not as long as you might have, I really don't know or
NK> care). I still disagree. I think it's arrogance, ignorance,
NK> carelessness and laziness that accounts for every situation where
NK> people's "solution" is to upgrade a system when it's not otherwise
NK> necessary. Sometimes it is, but if you have to because of a
NK> design choice, slow code, or choice of language, then you should
NK> probably find a new line of work if that's your general, generic
NK> "rule of thumb".

well, then you get to manage a group of perfect coders who all do what
you want to do in zero time (just like Quantum::Superpostions! . and
you will make tons of money. otherwise you are stuck in the same
boat. you haven't experienced the real world yet it seems. good luck in
your fantasy.

as for my business it is recruiting and placing perl developers. i don't
think i will ask you for your resume in the near (or far)
future. claiming you know all this but not understanding it is not a
skill i would promote to my clients.

have the appropriate amount of fun!

uri

--
Uri Guttman ------ -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

Uri Guttman wrote:

>>>>>> "NK" == Nathan Keel <> writes:
>
> NK> Uri Guttman wrote:
>
> >> study some computer history and come back when you have finished.
>
> NK> Please don't resort to acting like your view is fact and anyone
> that
> NK> doesn't agree with you is somehow ignorant. I "get" what you've
> said, NK> I just don't agree with it.
>
> then you don't get it. cwilbur also covered this. sorry but no more
> lessons for you.

Your pitiful arrogance is incredibly unappealing. I get it fine, you're
just acting like you know it all, because you can't handle someone
disagreeing with you.

> >> have you ever worked on a computer which actually accounted for
> >> your cpu time? you don't understand my point which is well known
> >> and supported. cpu time used to be the major expense in those
> >> days, developer time is the major expense now.
>
> NK> That's only true to a point. Many things have changed since the
> NK> 60s and 70s. Indeed, we have a lot less to worry about as
> NK> developers, but that's no excuse to be lazy or stubborn about
> the
> NK> topic. Certainly you must agree that some compiled programs are
> NK> much better suited for some situation and applications? If so,
> NK> you can't really knock C because Perl is quicker to develop in.
>
> you still don't get it. sorry.

Don't apologize because you feel the need to accuse people of not
getting it because you can't handle someone disagreeing with you.

> it is not about any particular
> application. i wouldn't write an embedded rtos in 64k of ram with
> perl. i would do it in assembler like i did on an lsi-11 back in
> 1980. hell, perl wasn't even invented back then. but given what i was
> doing then on modern cpus, i would probably do it in perl as the cpu
> speed is enough and the development time would be massively shorter.

Sure, if Perl is the right fit, and it usually is, then there's no
argument. Really, this has nothing to do with paying for CPU time back
in the 70s, so spare me. Anyway, I'm not speaking specifically of Perl
either, but certainly am using it in the relevant examples, since that
was the TOPIC of the thread.


> and yes, i have also done those types of programs in c including a
> major web crawler for northern light. so i know of something about
> development time vs cpu power. can you make the same claim? me thinks
> not.

When you use snobby and childish phrases like "me thinks not", you might
understand why it's difficult putting much faith in anything you say.
I've done plenty of interesting and large scale projects over the
years. I don't care what you've done, you're either right or wrong
about your views, or there's only room for opinion if there's no actual
right or wrong. In this case, I believe you are wrong. You believe
I'm wrong. This is going to get us somewhere by repeating what we
think of each other? By the way, I think your "shift" key is broken.

> NK> I actually do, I just don't agree with your arrogant attitude.
>
> no you are ignorant, vs my experience. NYAH NYAH NYAH!

Hey, that's you doing that, not me. You have no idea what I've done,
and you base your attempts at insult on the fact that you don't like my
disagreement with you. Instead of reading what I said, you'd rather
try and rail on me about things by saying how much more experienced you
are. The only thing you've actually illustrated, is that you're at the
very least not socially mature and you're arrogant. That doesn't mean
a flippin' thing to me.

> now i will predict you will call me some more names. please do as it
> will validate my ESP powers.

Your ESP powers suck, I never called you a name. So, you're resorting
to claiming knowing someone's knowledge, experience and what they've
said to try and save face? What's the purpose? You think you own this
damn group and you feel some need to throw a tantrum, or are you
foolish enough to think that my interpretation that you're arrogant and
ignorant (too stubborn to accept anything anyone says because you would
rather fight with them to tell them how smart you think you are), is
somehow name calling... and if so, if you somehow think it's okay for
you to call other people clueless and ignorant?

> >> study some history as i said. computer power is dirt
> >> cheap today.
>
> NK> Yes, it is, but there are still limitations. If you think that
> NK> slow programs are fine, and say people should get faster systems
> NK> if they don't like it, then you're not as smart or knowledgeable
> NK> as you (clearly) like to think.
>
> check out my cpan modules.

I've seen them.

> try to make them faster. please do and send
> me patches.

I've not ever claimed I would or could make your modules faster. Maybe I
can, and maybe I can't. My point was about how some compiled languages
compared to some interpreted languages, are going to be faster running
and more efficient. Assuming both examples are done by qualified
developers. You claim that based on that information that it's more
appropriate to just use an interpreted language and get a faster system
to run it on (if there's a problem with the program's speed), rather
than having someone develop the program in a compiled language like C.
That's ridiculous. I agreed that in a lot of cases, that might be
fine, there's nothing wrong with Perl, for example.

I never said people should take an existing program and re-do it in C
just for the sake of having it run faster. I never said that people
have the choice or time. I never said that some companies or
situations don't make a faster system a better option than using faster
code. I never said that at some point, given enough processing needs,
that regardless of the language used, that you may have to upgrade to a
faster system anyway (or use some load balanced solution, or whatever
else might be available). Also, sometimes the job pretty much forces
people to do those things and faster systems are always better and more
fun to work on anyway. Somehow, when I said "however, a person should
be able to (within a reasonable difference in time) develop a solution
in C without a lot more development time (if any), if they are truly
qualified, and sometimes a situation can benefit from that, where even
upgrading to faster systems won't achieve that same result.

If you don't agree, fine, but don't start making **** up and putting
words in my mouth. I actually didn't disagree with you on a lot of
points, I just said that it's careless to think that development time
is always more costly than a system upgrade and that it's a foolish and
ignorant "standard" response/reaction to have to a problem that can be
solved in other ways. I didn't say that option was always available in
every situation though. It's like a company that makes a product, they
do the shipping also and the shipping costs are killing them do to the
weight of the items and the smaller engine. You could say "let's put
bigger engines in the trucks to ship", or you could ask the product
development team (who exists anyway in these scenarios) how the work is
going on the new product that is 50 times lighter and has the same
structural integrity. Not to mention smaller and more portable, which
opens new profit options for the company and their consumer base.

You can keep stuffing bigger engines in there, until you run out of
engine compartment room and then start looking at bigger trucks, but if
it's going to actually be cheaper (yes, it's true) to start producing
the more efficient (by size and weight) product in the same or less
time, I'd go for the latter. Maybe it's my "inexperienced" and
"younger" attitude, but it makes sense to me. I repeat, it's not that
simple for every situation, so don't start making broad statements and
acting like that blanket statement is somehow a "fact" or that people
whom state that "this isn't always the case" and that "other variables
play a role" in those decisions, are somehow the "ignorant" one's that
"don't get it", because, honest to God, no matter how much you go on
about your experience, your modules or what you've done, it makes you
look like an arrogant asshole that's too stubborn to accept another
view point, which in the end makes you look stupid. Instead of being
civil and asking me to elaborate or provide an example, or you actually
bothering to do the same, you resort to touting yourself. Well, you
don't impress me.

> i will use them (if you can but you can't) and even give
> you all the credit.

I don't give a damn about you or your challenges. I know you like to
think you're a big shot, as evidenced by your attitude in this group
over years. I look past it, because you offer insightful and good code
fixes for people or ideas, but that doesn't make you the smartest and
most experienced person here about any and every topic, and this one
here is proof of that. Instead of listening to what I said, you revert
to what you've just done. I don't think you're an idiot, but if you
can't understand what I've said, ask for clarification and don't be so
hostile, or maybe consider a different aspect and view of the topic's
subject, or maybe reconsider just how smart you think you are? Maybe
for kicks I'll check out your modules and maybe I'll make improvement
suggestions, and maybe I won't find any or think it's the best code
I've ever seen, but that still doesn't mean jack regarding the topic at
hand.

> >> developer cost is way more
> >> expensive.
>
> NK> Probably, yes. However, that doesn't automatically mean it's
> either A
> NK> (hardware) or B (development time). You MUST understand there's
> a NK> middle ground, where you want efficient and suitable code,
> regardless NK> of the hardware aspects?
>
> boo hoo. you seem to be fighting for no reason.

You need to get a grip and grow up. Also, try looking in a mirror.
There's no reason to be such a jerk because someone made a point you
don't agree with. This is ridiculous.

> i never said any of
> that. you don't get it again. it is the bigger picture.

What sort of jerk would just continue to claim someone doesn't "get it"
and not bother making their point? All you're doing is fighting with
me, which is ironic that you accuse me of just doing only that. You
really think you're someone special.

> >> so buying more/faster computers is usually more economical
> >> than hiring more and better developers.
>
> NK> Or when any idiot can create an inefficient program that uses up
> NK> all of the CPU and/or memory and/or system I/O and your theory
> NK> about faster systems falls on its face. Plenty of people suck
> at NK> coding and people also make mistakes (in code or the design)
> and NK> these things just mean that it takes 20 minutes to crash a
> NK> "faster" system, than the 5 minutes it takes for it to crash a
> NK> slower system.
>
> MMM to the rescue. please read it. i think they have a version written
> in 4th grade level english for you.

And if only you could use proper grammer, type with upper case for
proper nouns, and type the word "English" properly, it might make your
petty sarcasm more effective for the readers of the thread. You're a
world class asshole, man. Seriously. I realize you're a good Perl
coder and you've contributed some modules that are probably nice and
useful, but that doesn't give you a free pass to be an arrogant prick
and think I owe you something or you can treat any random person like a
piece of dirt. You're going to have to deal with the fact that people
don't think you're the genius you think you are. I've done a lot of
coding, too, and while I've not contributed a Perl module a lot of
people use, I've done some pretty complex stuff and am a good developer
and have a lot of experience. There are also a lot of people that are
just as good as you (and better) at coding in Perl, and they don't feel
the need to be an arrogant prick on this group. Apparently the only
way I can get through to you, is to recode your modules better (and
maybe I can), but what point would that prove? Is that the only way
you'd listen to someone? Do you think I need to prove something to
you, because you have it in your mind that you're just THAT special?
This is pathetic.

And, by the way, I've read plenty of MMM, I've even got the book and
everything. I have about 200 books that get into complex things, I've
read them and understand them. I've applied and used the information
and am able to formulate new ideas and theories and test them and
create and do. Yet, somehow your opinion isn't something I agree with,
so that makes me clueless to the point where you feel it's an
appropriate reaction to reply to me with insults and accusations about
my experience and knowledge, yet you know nothing about me. The only
thing this really tells me, is what sort of person you are. Your
pathetic attempts to apply your theories about me to make you feel
better about yourself don't actually make it true (though you're
probably arrogant enough to think that's all the basis you need for
your claims). Personally, anyone that reacts like that when they feel
threatened by someone on usenet disagreeing with them, I just can't
take too seriously.

> NK> Anyway, you certainly must agree that it's not always the best
> or
> NK> viable solution. I think that's a careless rule of thumb. My
> NK> code is not really any longer to develop than other peoples, and
> NK> my code runs fast and efficient on any system. I don't agree
> with NK> the rule of getting a faster system to account for
> inefficient or NK> poor coding choices.
>
> all rules of thumb are careless. that's why they are CALLED that.
> duh!!

Some are more careless and foolish than others (duh)

> >> for a starter, read the mythical man month.
>
> NK> I've read it. I've done research. I've been coding for a while
> NK> (even if not as long as you might have, I really don't know or
> NK> care). I still disagree. I think it's arrogance, ignorance,
> NK> carelessness and laziness that accounts for every situation
> where NK> people's "solution" is to upgrade a system when it's not
> otherwise
> NK> necessary. Sometimes it is, but if you have to because of a
> NK> design choice, slow code, or choice of language, then you should
> NK> probably find a new line of work if that's your general, generic
> NK> "rule of thumb".
>
> well, then you get to manage a group of perfect coders who all do what
> you want to do in zero time (just like Quantum::Superpostions! .

All sarcasm aside (can you manage to do that?) one needn't be a perfect
coder, just qualified and good. A bad coder or one that's considered
closer or further to or from being "perfect" doesn't matter what
language it is. The point was, your argument that someone it would
increase development time so severely by not just "getting a faster
system to solve the problem", was why it's a "good rule of thumb".
Untrue. So, do you make these decisions based on your lack of
experience and skills in another language, or because you can't chose
actual qualified programmers, or out of desperation, or just because
that's the gap that closes you and your code?

> and
> you will make tons of money. otherwise you are stuck in the same
> boat. you haven't experienced the real world yet it seems. good luck
> in your fantasy.

Apparently, if I say a good C coder with modules, libraries, code and
function templates (which any good C coder would have) can develop just
as efficiently as someone in Perl, you read that as "they do what you
want in zero time". Apparently, you're so arrogant that you can't
accept that some people have different experiences and opinions, else
NOW they also live in a fantasy world or lack "real world experience".
You're really something. Think you might be going a little too far in
your ranting there?

> as for my business it is recruiting and placing perl developers.

And now I feel sorry for a group of people I've never met.

> i
> don't think i will ask you for your resume in the near (or far)
> future.

And you get the impression I'd WANT to send you my resume or work with
or for someone like YOU in ANY capacity? Don't flatter yourself.
You're not keeping me from any work. You give yourself far too much
credit and influence points.

> claiming you know all this but not understanding it is not a
> skill i would promote to my clients.

I honest to God think you're clueless about this subject, or you're just
such an arrogant jerk that this is just standard operating procedure
for you.

> have the appropriate amount of fun!

Don't worry, I know nothing I said will get through that thick layer of
smugness. Not that I usually care, it's not abnormal to see on usenet,
but you've not earned nor deserve getting away with it. You're just an
impossible jerk, but I know you won't let anything I say change your
mind or attitude. Feel free to claim I suffer from whatever other lack
of skills or experience you need to, to make you feel better and more
important about yourself, but you've not really come out on top of
anything. In the future, try and understand why someone's not going to
put up with your smugness and arrogance and don't hold it against them,
especially when you're wrong.

> uri

nal cake.