"Robert G. Brown" <rgb at phy.duke.edu> writes:
>> By the way, this isn't special to computer science. Imagine if laymen
>> were directing the physics research . Progress in physics might be
>> rather slowed down, don't you think.
>> The problem here or anywhere is money.
I'm reminded of an analogous problem. There is a saying in many
chemistry labs that "a month in the lab can save you an hour in the
library". The man too busy to learn wastes time.
Sure, it is difficult and expensive to teach people the appropriate
skills. The question is, can you afford *not* to? We're now in an era
where scientific computing resources can cost millions of dollars. Is
it really a savings to avoid personnel costs at the expense of
projects costing vastly more money or even being unachievable because
someone doesn't see that an algorithm can be converted from O(n^4) to
O(n^2), or doesn't even understand what big-O notation means?
The resource constrained are in an even worse situation. If you have
barely any cash to spend on resources, you really need to make that
cash count.
> There are ten times as many problems and projects and groups where one
> is lucky to be able to afford enough grad students to barely keep your
> research moving, buy computers with money that you dragged out of a
> reluctant grant agency, and that you can only run at all because your
> University provides electricity and housing for them because your grant
> literally couldn't afford to pay the power bill once the above are paid
> for.
I know many people who claim they're too busy to do time management of
their day, which of course means they waste more time than they've
saved by avoiding doing planning.
It is not very different to see people with limited resources saying
they can't afford to figure out how to make optimal use of them. The
man with $3M to burn on computers needs to understand how to use them
properly so as not to waste money, but the man with $5000 *really*
needs to understand how to use them properly because that's going to
make the difference in getting something done *at all*. The difference
between the right algorithm and the wrong one is the difference
between running a mediocre cut down version of your problem over the
course of six months and running a reasonable version in one.
This doesn't apply to people who are just running pre-written
software, that's a different story, but if you need custom code, you
need the people designing the software to understand the problem, and
at least some of the people who understand the problem to understand
how to design software.
Perry
--
Perry E. Metzger perry at piermont.com