Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsp!johnson
From: johnson@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.arch
Subject: Re: Processing
Message-ID: <76700005@uiucdcsp>
Date: Sat, 18-Apr-87 13:54:00 EST
Article-I.D.: uiucdcsp.76700005
Posted: Sat Apr 18 13:54:00 1987
Date-Received: Sun, 19-Apr-87 18:08:44 EST
References: <2105@mmintl.UUCP>
Lines: 22
Nf-ID: #R:mmintl.UUCP:2105:uiucdcsp:76700005:000:1211
Nf-From: uiucdcsp.cs.uiuc.edu!johnson    Apr 18 12:54:00 1987


There are a number of programming styles that result in programs that
are small, easy to understand, and slow.  Logic programming and constraint
programming both fit into this catagory, and functional programming
probably does too, except that in the last few years, we have seen a 
number of efficient implementations of functional programming languages.
My favorite language is Smalltalk, and its sudden popularity is due in
no small part to the increase in speed  of cheap processors.  However,
it is still too slow for many applications.  Other interesting languages,
like SETL, suffer from the same problem.

What about 3D graphics?  I've used an IRIS workstation, and I'm sure that
you could sell millions of them if they were only a couple of thousand
dollars apiece.  100 MIPS is probably about right for that kind of
performance.

We need fast processors just to search large databases.  Naturally, you
can keep lots of indexes, but that takes lots of work, and some things
are hard to index.  In general, writing efficient programs is hard work.
It is easier to write clear programs and not worry about efficiency.  We
are still a long way from there.  It won't be long until 100 MIPS will
seem slow.