From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 23 Apr 94 18:07:52 PDT
To: dat@ebt.com (David Taffs)
Subject: Re: T-Shirts, Neil Young, Asilomar, and Smalltalk
In-Reply-To: <9404240025.AA01558@helpmann.ebt.com>
Message-ID: <199404240107.SAA21666@mail.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


David Taffs writes:

(quoting me)

>    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)

(much of interesting story about Mentor Graphics elided to save space...)

> 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.

Oh, but I think you're making my point! The "superachievers" (=
expensive designers, engineers) were buying Mentor and Sun and Apollo
and other workstations, and the CAD tools that ran on them *precisely*
to allow these superachievers to operate at a higher "semantic level"
than they would otherwise.

That is, the various CAD packages, with features ranging from direct
object manipulation (circuit elements, not just pixels) to silicon
compilation (perhaps overhyped...), are essentially "HLLs" for VLSI
and other design environments. Ditto in related fields.

I'm sure David knows this very well, but it bears analysis in the
context of tools for programmers.

And the fact that Mentor was competing (not very successfully--and I
was Intel in Aloha, Oregon from '80 to '82 and knew some of the folks
who founded Mentor--same time as the even-shorter-lived Metheus) with
Sun and with high-end PCs meant that speed was very important. I agree
that a workstation that ran CAD software 3 times more slowly by using
Lisp would not be desirable (I can remember a couple of silicon
compiler outfits that attempted to sell Lisp-based silicon compilers).

Howver, most programmers I see are not writing this kind of
productized code. Perhaps this is just my bias, or the types of folks
I see.

Here on this list, Perl has been adequate. And it's just interpreted.
Furthermore--and this is one of my main points--most of the really
"neat and cool" ideas for crypto use, for crypto tools, etc., are not
getting done not because the code cannot be made small enough and fast
enough but because the "semantic gap" between our thinking about
crypto concepts and the tools to sit down and write them is so great.
(By tools I also mean "abilities" and conceptual classes (in C++
terms) or methods (in Smalltalk terms).

I think we need a "Crypto Toolkit." Henry Strickland is talking about
using TCL (a Berkeley-based C package, apparently used somewhat
analously to Perl, but with some differences) to provide a set of
crypto primitives.

My mention of SmalltalkAgents was more in line with the notion of a
"CAD" package for building complicated crypto protocols, with the
distilled knoweldge of the "Crypto" Conference proceeedings
implemented as classes and methods (even with objects named "Alice"
and "Bob," if needed). This could of course be done in C++, with a
class library of crypto functions.

This is the "high-level language" sense I was describing, with objects
that "behave as" digital cash, or communications channels, or even as
agents like eavesdroppers, spoofers, forgers, etc.

(I suspect you can see where I'm headed: an artificial ecology
(cryptecology?) of cryptographically-aware agents, thus creating an
environment for experimenting with and testing crypto protocols for
release into the world. The object-oriented approach is to allow
separation of functionality, so that the various distinct capabilities
are truly modular and are not just different chunks of code in a large
program, as PGP is currently an example of.)

My conjecture: 70% of all programmers now coding in C and planning to
learn C++ would be "better off" (more productive, more maintainable
code, fewer reinventings of the low-level wheels, etc.) with
higher-level languages. "Rapid prototyping" is another buzz phrase,
but an accurate one.

In cases where one's reach exceeds one's grasp, as appears to be the
case with all of these crypto ideas, bridging the semantic gap and
actually getting something out is, I think, much more important than
having it run faster (but not be built at all....).

--Tim May



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."