Re: Paul Graham's PyCon Keynote & The Programmer's Apprentice

[Adam Turoff <address@hidden>]

On Sun, Mar 30, 2003 at 11:50:15AM -0500, Peter J. Wasilko, Esq. wrote:
> > In fact, inefficiency is good because programmer
> > time is cheaper than computer time or computer power.
> 
> Greetings All,
> 
> I think Eli meant to say that inefficiency is good because computer
> time is cheaper than programmer time.

Yes.  Increasing programmer efficiency is a standard justification for
language features like garbage collection.  It's been preached for years
if not decades, and on the face of it, it may appear to be nothing new.

I believe Paul's point was that there are some areas where we have
learned to tolerate a certain amount of inefficiency today.
Wasting cycles on garbage collection is better than spending weeks
tracking down crashes and memory leaks.  Compared to computers as
we knew them 50 years ago, our usage is scandalously wasteful today,
until you accept that memory, storage and compute capacities are
stupidly cheaper today, and that this is a very wise tradeoff.

>From there, Paul said that if Moore's law holds, computers will be
78 quintillion times faster in 100 years (with similarly large
increases in memory and storage capacities).  Therefore, things we
still see as scandalously wasteful today will be quite acceptable
and even desirable tomorrow.  Finding these interesting inefficiencies
that directly lead to more elegant solutions and more productive
programmers are an area that deserves more attention.

As proof of his assertion, he talked about how wasteful it seems to
route an overnight package from NYC to Boston via Memphis.  It sounds
wasteful on the face of it, but it also allows for single-rate,
overnight delivery anywhere in the US.  That kind of inefficiency
provides for a certain kind of elegance which translates into greater
efficiencies elsewhere in the system.

However, Paul also did note that there will likely be situations where
it will remain necessary to code close to the hardware.  The language of
100 years from now will allow for these scandalously wasteful usage
scenarios which allow applications to be built quickly, and scale down
to situations that need to be ultra-efficient, like cryptography.

Z.