T-Shirts, Neil Young, Asilomar, and Smalltalk

[David Taffs]

Pardon me for getting on a soapbox (again)

T. C. May, for whom I have the utmost respect (and whose messages
are always enlighting and enjoyable), says (in part):

                                                 And "Byzantine
   Agreement" (is this the same thing as Byzantine Generals?) shows up, I
   recall, in some crypto papers.

Yes, they are the same. You have N mutually suspicious individuals
trying to reach concensus about something -- what protocol do you use?

I believe the seminal paper (or at least some really good, polished,
early work) was by Leslie Lamport at Xerox Parc (et al.), but I may be
wrong.

   > Objects are Great; C++ (using objects, in I believe the way you mean)
   > is clearly the language of choice for the virtually the entire

   Yes, of course this is what I meant. That's why I mentioned the
   Smalltalk approach. (I won't get into issues of performance of C++
   over Smalltalk and Lisp systems...my contention is that there's a vast
   amount of computer power out there and a (relative) shortage of good
   programmers and their time, and that this implies that only truly
   time-critical things or many-times-replicated programs warrant writing
   in lower--level languages. A religious point, no doubt.)

Also a practical (== economic) point. When I worked at Mentor Graphics
(MGC), I was amazed at the enormous percentage of effort devoted to
optimization of our products (MGC builds the software to help design
circuits that go in workstations that run MGC software that helps
design circuits...). The _entire company_ (many hundreds of engineers)
just about spent _years_ making a recent release small enough and fast
enough to be commercially viable (luckily for me and them they
succeeded -- of course, there were bug fixes and some enhancements
added during the same time period).

At MGC and now at EBT, efficiency (= responsiveness, = salability) of the
delivered product is a virtually paramount goal, right up there with enough
functionality. If functionality cannot be delivered with adequate efficiency,
then nobody will buy it (except a few leading edge weirdos), and you go broke
(MGC lost big bucks during this time period, and experienced at two or three
waves of layoffs).

If anybody can afford large, expensive workstations to improve the
productivity of their superacheivers, it is computer manufacturers and
their circuit designers (one of the highest paid engineering fields I
know of). Their whole company depends (you may have guessed what I'm
about to say) on the efficiency (production efficiency and efficiency
in their target application) of the chips they are producing, for which
MGC tools were (at least the primary) design vehicle.

And yet it was cost effective to have me and many other engineers
(also comparatively highly paid, but not compared to circuit designers
I'm sure) spend several years trying to reduce the size of the object
code (and working data structure size) for the tools.

Earlier, when MGC was in the desktop publishing business for awhile
(which is where I was most of the time), efficiency was a major,
major concern. Keeping the size of data structures and code to a
minimum was well worth the effort it took to design more complex
systems. Every customer seemed to really care how fast our product
ran, which essentially translated into how much physical memory it
took to run the product. One of the major competitive advantages of
our (now discontinued) product was that it handled extremely large
documents relatively efficiently. But customers were always asking
to make certain operations more efficient, and this was often on
their top N list of enhancements.

So, even using a "lower level language" like C++, even for a high
end programming shop like MGC, even for not-many-times-replicated
programs (I don't know how many seats MGC has installed, but it is
somewhere in the tens of thousands), memory space was at a premium.

I still _can not believe_ that after all the progress semiconductor
manufacturers have made in the past 30 years that they cannot
manufacture enough RAM cheaply enough to hold our software. This
is truly INCREDIBLE! RAMs are still (at least as of a year or two
ago) sufficiently expensive that a significant fraction (maybe 1/3)
of programming effort must be wasted merely trying to keep memory
utilization as small as possible.

Ask how much time DBMS vendors spend on optimizations; it is huge!
(Arguably, it is their entire business.) Compiler writers -- same
thing (I did this in a previous job too). GUIs have to be speedy
too, and people I know spend a lot of time adding performance
hacks to speed them up. For real tools used in real applications,
apparently customer expectations have increased _significantly
faster_ than our ability to manufacture semicondutor components.

People have always said that "sufficient" computing capacity (or
network capacity, or what have you) will be Here Real Soon Now(tm),
but it hasn't happened yet, and I'm not sure it ever will in the real
critical applications where the rubber meets the road (and computer
circuit design is one of them -- data retrieval, publishing, and
networking are also).

Of course, this is all relative, and Internet clearly has the
bandwidth to support the CP list. My point is that in the real
world, efficiency (however measured) is still a major concern
for economic survival.

I predict that efficiency of cryptography will be important,
and it will be a long while before enough computer power is
widely available to encrypt all data, sensitive or not (i.e.
cryptography is cheap enough to not worry about whether to
use it or not).


   >    Food for thought. I'm wondering if a project to implement a kind of
   >    "Digital Money World," perhaps in SmalltalkAgents, wouldn't be an
   >    interesting project. (Many will probably tell me that a collection of
   >    Perl scripts would be more "portable" and more useful to the current
   >    Unixcentric community....something I'd like to see more discussion
   >    of.)
   > 
   > I suspect the framework of choice would be some sort of MOO or MUD. Of
   > course, once it hit production status, then transliteration into Perl
   > install scripts would be appropriate.

   I would agree, except the history of "develop it in an
   ultra-high-level language/environment and then port it later" has not
   been too encouraging: for whatever and various reasons, the ports
   rarely take place.

Right. Remember, Fred Brooks (in his classic on software engineering
_The Mythical Man Month_) says to plan to throw one away. So you build
the first one, and instead of porting it you redesign it from scratch.
(Of course, then you might perhaps want to worry about his "second system
syndrome".)

   > Of course, we'd better get strong crypto distributed before the Second
   > Coming -- you think the current US government is involved in a power
   > grab, you just wait!!! This new government will really know how to
   > take care of non-conformists -- Waco is nothing compared to what they
   > are planning (read: fiery brimstone)...

   You'll find many on this list who agree with every point here.

I hope my implied smiley was apparent here, and the McElwaine-like addendum
(deleted by Tim) was hopefully enough to convey my true attitude...

   > I wonder if Jesus can create a number so large he can't factor it?
   > 

   I haven't found one yet.

What haven't you found -- a number you can't factor? Or a number
that Jesus can't factor? (I bet at this moment there are a lot of
them, for example "12".) Or a number that your deity (if any) can't
factor? Or is this an implied-smiley-bearing reference to a potential
delusion of grandeur on your part? Or are you and he really working
on this problem collaboratively, in some metaphysical domain?

If you are saying that you can't find a "Jesus" who can create a
number so large he can't factor it, I would tend to strongly agree
with you. On the other hand, virtually every person who ever lived
can (with a little coaching, perhaps) create a number they can't
factor, and there are plenty of living people named Jesus.

Maybe it is just because you aren't looking in the right places... :-)

   > Pardon my excursion into various religious topics -- arguably this
   > list is also about religion ("religion is what you do" -- "cypherpunks
   > write code" -- belief that strong crypto should be widely distributed
   > is certainly a religious tenet for some on this list). I hope I
   > haven't offended anybody important...

   I enjoyed your comments, for one. 

Thanks -- I always enjoy yours.


   --Tim May

-- 
dat at ebt.com (David Taffs)