On Tue, 21 Sep 1999, D. Tweed wrote:
> Sometimes the problem that you're working on requires such
> a lot of computation (e.g., typical image processing stuff) that no
> savings from reduced writing time can by a machine fast enough to
> compensate for the slow-down.
I agree. The arguments "you are saving on development time
by using _the_ language" or "buy better equipment instead"
are quite old actually. I've heard them first time in relation
to perceived slowness of Smalltalk. Nothing has changed
over the years in this perception, even though computers
have become faster and Smalltalk itself has been significantly
improved speed-wise; the competing languages have simply taken
the same advantage of hardware.
Besides, our apetites grow up too and the problems to solve
become much more complex than before. What used to be
considered an acceptable limitation is not such anymore.
The speed is a relative concept: comparing to what?
If I compete against delivery time than it matters to
me whether I will get my results in 6 versus 12 hours.
Just 50% difference, but it counts when impatient
client wants it done for "yesterday". And it counts
even more if he comes with another bright idea of
changing the input a bit and asks me to rerun it
again and again. If I use a top of the line commercial
software, which has no practical competion (say Ansys),
then buying faster equipment obviously helps.
But not if I have written my own staff, say in Haskell,
which supposes to compete with similar programs written
in C.
Jan
