From: "Phil G. Fraering" <pgf@srl.cacs.usl.edu>
Date: Mon, 25 Apr 94 17:07:56 PDT
To: cypherpunks@toad.com
Subject: Programming languages debate
Message-ID: <199404260003.AA04223@srl03.cacs.usl.edu>
MIME-Version: 1.0
Content-Type: text/plain





Phil Fraering writes:

> Aren't there freely available versions of Smalltalk for Unix?
> GNU Smalltalk apparently lacks the classical graphic interface,
> but from what I've seen, so does Perl ;-)
> 
> pgf

Timothy C. May responds:

\Yes, and you mostly get what you pay for: a "toy" environment that
/nobody I know uses for anything. (The Gnu Smalltalk is analogous to
\the toy implementations of Lisp and Scheme in C....a useful pegagogic
/tool, but lacking the richness that the full "environments" are so
\well-known for.)

(Damn, Tim's written a lot I want to respond to, I don't have an
indent script handy, and even if someone else did, my emacs version
isn't current. At least it fits in 50 Meg ;-)

\The serious work is done in ParcPlace's VisualWorks, DigiTalk's
/Smalltalk/V, or the new SmalltalkAgents from QKS.

I'd like phone numbers or other contact information for these companies,
if anyone has some handy.

\Besides, I don't _have_ a Unix machine and I have no interest in
/getting one (nor in trying to install a Unix on my Macs).  The above
\programs are available for Windows, Macintosh, and Unix, in varying
/degrees and combinations. (VisualWorks is mostly targetting Windows,
\Smalltalk/V is a cheaper alternative, for both Windows and Macs, and
/SmalltalkAgents has been released for the Mac, with versions for the
\PowerPC (Q2 94), and Windows32/NT and SPARCstations to follow.

Which implementation of UNIX for SPARCStations? Might it be runnable
under Solarisx86, or ported to some other binary Unix standard? I
need to find out before I spend...

/I'm not grinding an axe for Smalltalk, understand. Just commenting on
\some directions. Maybe TCL is the way to go, maybe mixtures of Perl
/scripts and short C programs are The One True Way (the remailers work
\this way, and they are our major public success to date, with new
/things like MagicMoney following the same path, so....).

\The proposed language "Joule" (which some of our list members are
/doing) may or may not be ideal, but in any case it is probably at
\least a few years off.

/--Tim May

(End of current message from Tim. I hope to do several in one message). 

Okay, I pretty much agree with what you wrote about GNU Smalltalk.
I don't know it, I've only read (most of the) standard Smalltalk book,
and by comparison to the original from PARC GNU Smalltalk is missing
crucial bits.

My point is not that GNU Smalltalk is good compared to uncrippled
Smalltalk, but that it may be better than Perl/TCL/whatever else
is being proposed.

One of the main merits of Perl seems to be that it's a free scripting
language that isn't dependent on what shell (bash, ksh, whatever) you
are using and is apparently highly environmentally independent.

Oh, I give up. What I'm trying to say is that it's a Schelling point.
(You'll have to look up what that is if you don't understand. I'm
sorry, but it's the best way for me to describe what I mean).

It gains a "developer," programmer, and user base because it is a
Schelling point, not because of any actual merits as a programming
language itself.  Please note that I am not saying that it does not
have these merits.

This is according to some the same reason C is used in preference to
C++, C++ in preference to Objective C, and Objective C in preference
to Nicklaus Wirth's current language of the month or the Lisp or
Smalltalk-like language of your choice.

Perhaps we should simply ignore what's a Schelling Point and simply
pick a language that's going to be the best one to implement the
algorithms in, and then worry about porting the program/making it run
on other systems.

On to the next message. Here's Tim:

\In this message I talk about C code, agents, TeleScript, Smalltalk,
/PGP tools, and the general and pressing need to somehow make all the
\diverse fragments of code available and (even more importantly)
/comprehensible and usable. (As I'm no expert in C++ and the like, take
\my comments as "moderately informed speculations.")

I probably should include similar disclaimers.

(Quotes from Hal Finney and Peter Murphy deleted for space
considerations. It's in Tim's original message.)

\...options, routes, and miscellaneous points. But I'll just make a few
/notes here. (The theme of the next Cypherpunks meeting, date not yet
\finalized, is "Protocols," so issues like this are presumably
/relevant. Depending on the date, I may be in L.A., and would welcome
\meeting with other Southland Cpunks to discuss ideas.)

I'm not going to be able to make it, whenever it is. I'm trying to
contribute now:

\I. What We Have

/* PGP...the most basic of all crypto functions (RSA
\encrypt/decrypt/sign/etc.), and it took over a decade to get a usable,
/public domain (?!) version. (Yes, I know about RIPEM, RSAREF, etc.)

Well, it doesn't seem to help much that RSA seemed to take a hostile
view of anyone "infringing on their patent." I remember ftp'ing rpem
one fine day and going back to the site the next and finding that it
had been removed thanks to ominous warnings from RSA. But I get the
basic point.

I also wonder that the effort *might* have a bottleneck in the RSA
encryption algorithm itself and its patented status. You're apparently
stuck with RSA in the form RSA Corp. wants you to use it, even if they
do release it. It is their right to do so (if one believes that software
patents are valid, although off-hand I don't know anyone who does).

It's still a bottleneck.

\(I mention this because _use_ of this protocol, even with a nice
/manual and whatnot from Phil, Hal, Derek, and others, still mysifies
\many people, and still is not easily callable from most mail programs,
/as you all know. This is *terribly important point*, to wit: if the
\most basic of all crypto functions is so long in gestation and so
/difficult to use interoperably, what hope do we have in integrating
\the vast range of crypto protocols to be found in Schneier, the Crypto
/Conference Proceedings, etc? This is the problem I'd like to see
\solved, hence my interested in "Computer-Aided Crypto Algorithms," or
/CACA.)

\* we also have fragments of C code accumulated and laboriously
/developed by Bruce Schneier.
...
\* there's the ProductCypher (sp?) code which Hal mentioned.
...
/* code in Perl obviously exists in various places, and both Hal Finney
\and Henry Strickland have written about TCL. Whether these scripting
/languages, with excellent facilities for accessing Unix utilities
\directly (as opposed to from deeply within a C program, like PGP),
/should or can form the basis of a Crypto Toolkit that others will
\actually use is unclear, to me at least.

\* other programming efforts presumably exist out there in Cypherpunk
/land, and some folks not on the List (unless by pseudonym, which is
\quite possible....after all, ProductCypher is obviously a talented
/programmer and may be one of the main folks posting algorithms and
\code fragments to sci.crypt) are clearly writing code for various
/purposes.

\...thus ends my informal summary of what's out there (it may be
/incomplete, or inaccurate in places...corrections are welcome, as
\always)

/II. What's Neeeded

\* Consider some things we like to talk about:

/- alternatives to RSA (elliptic functions, etc.)

Does anyone have any pointers to references to alternatives to RSA
encryption, or to any possible claim RSA might have to any
alternatives?

\- secret-sharing protocols
/- remailer-specific code (adding latency, mixing, padding, etc.)
\- dining cryptographers nets (DC-Nets, a la Chaum, Bos, etc.)
/- digital cash (a vast area of diverse protocols for clearing
\transactions, for blinding, for detecting double-spending, etc.)
/- random number generators (Schneier, for example, supplies code
\fragments for the Blum-Blum-Shub generator...need I again say that
/probably few of us know how to "call" this code easily?)
\- code for message pools, for chaining remailers, etc.....a lot of
/this exists as scraps of Perl in various places.
\- and so on

\My point? How can we achieve the Crypto Singularity (tm) when these
/algorithms and _conceptual functions_ (my term, meaning that each of
\these embodies almost an agent-like level of behavioral
/complexity....hence my interest in implementing these protocols as
\classes and methods in something like Smalltalk or even the new
/TeleScript) are scattered around, are hard to grok (a technical term
\invented by the neural programmer Heinlein), and are more or less
/going unused today?

I take it since we last discussed Telescript you've learned more about
it. Anyway, I think I'd hate to be implementing stuff like the above in
any language for which the main advantage seems to be "it's a lot better
than awk!" Is Perl being used as a true algorithmic programming language
in the above cases or just a fancy JCL, anyway?

\III. Some Approaches to a Crypto Toolkit

/* Large collection of C programs. The Schneier approach, except on
\steroids. Regularize the calling conventions, add further
/documentation, generate test sample, etc. A massive undertaking,
\fraught with problems.

/* C and Perl, and maybe TCL. As above, but use other Unix utilities as
\needed.

/* A class library for crypto, in C++. Encapusulate as much of the
\capability into classes and make them available. For example (and here
/I'm using Smalltalkish lingo), an "RSA object"...

\I'm not sure how feasible this would be in C++, as I know very little
/about C++ ...
\From my Lisp background (Symbolics 3600, Zetalisp, Common Lisp) and
/from my experiments with Digitalk's Smalltalk/V on my Mac, I think an
\object-oriented environment could be ideal.

/* TeleScript. Here I will go out on a limb and predict that the
\forthcoming TeleScript, which is nicely described in the latest "Byte"
/by our very own Peter Wayner, could be the basis for some exciting
\progress. With multi-platform capability, object orientation, and an
/explicit foucs on agents running around delivering mail, encrypting,
\etc., it could be a winner.

I'll have to check out the article. I think when we see Telescript
running we'll be able to make a decision about what it can do. I still
haven't heard anything from Motorola about their hardware. Has anyone
seen the PC/Mac/Unix versions of Telescript running anywhere?

\(Speculatively, my notion is to embed in Telescript agents many of the
/things we've been talking about, and then count on the market to make
\mailers and Mosaic drivers to talk to these agents. Lots to talk about
/here.)

Count on the market... hold on a sec, aren't we the market?

\* Speaking of Mosaic, what about using WWW/Mosaic as the basis for
/transparent use? I'm already impressed that on a non-Mosaic platform
\(I don't have either a SLIP or PPP connection at this time) I can use
/my cut-and-paste to easily do a "lynx http::blah blah blah" and get to
\a home page with arrow-selectable hypertext points. I can see
/WWW/Mosaic/Lynx/etc. as a common platform (set of utilities) for
\handling even encrypted traffic.

More specifically, you mean use http protocols as the basis for
transparent use. So you'd have http interfacing to whatever the
program on the bottom was. It's just an interface.

It took a while, but one question I have is, are there run-time packages
or "compilers" for the Smalltalk environments you spoke of above?
If not, would it be possible to write one, or to extend one of the 
publically available Smalltalk environments to be able to run whatever
you or others write using SmalltalkAgents? Is there interoperability
between SmalltalkAgents and Smalltalk/V?

I'm thinking seriously of spending some money on the Smalltalk, but I'm
not sure it's going to do a great deal of good if it turns out everyone
else has to fork over $ 200.00 or so just to run a couple-hundred-line
program I wrote over a couple nights.
                                        
...

\* Integrating existing tools (PGPToolKit, Perl scripts, Schneier's
/code, RSAREF) into new apps is basically *not* happening, at least not
\by the Great Masses here on our list (let alone the Unwashed Masses
/off the list!).

\* Interoperability with dozens of mailers, on several platforms,
/remains a critical problem.

\* Hence, *good luck* in getting all the whizzy new protocols we like
/to speculate about implemented any time soon.

\This is the challenge I see. To somehow deal with this set of
/problems.

\Thanks for reading...and I again apologize for just sitting down and
/writing this in emacs instead of using my Mac-based outline processor.
\Sometimes just writing is better than planning, reorganizing, and
/never finishing.

\--Tim May

I'd like to apologize for what I deleted and what I didn't.

On to Tim's next message:

\The challenge I mentioned in my last message can be summarized as
/follows:

\- hide the complexity of implementation in the code, so that other
/programmers, and especially end-users, don't have to worry about it.

I'm not sure, but as a casual observer it seems the programming
community is about ten to twenty years behind the academic community
in terms of agreeing on the need of hiding complexity. People seem
to be sticking to C the way "scientists" are supposed to stick to
Fortran. Won't it be *easier* to write this stuff in Lisp, or Smalltalk,
or Modula-8?

\- to pick a simplest example, a random number generator needs to
/generated a good random number without the user having to worry about
\a zillion related issues

I guess I'm guilty of some sins... I've been planning a
hardware-dependant random number generator, and I don't know
if there's ever going to be a standard for scintillators+a/d
boards, never mind if they're ever going to be standard on
PC's.

Now where did I put that pitchblend? It's all I have since they took
away the red mercury...

\(this may get flames....I'm not saying users should be blissfully
/ignorant of some of the assumptions that went into the RNG, only that
\most users want an RNG that operates consistently, has been tested by
/others, etc. This is the Mathematica function method: have experts
\devise the best factoring or primality testing approach, implement it
/efficiently (usually in C or even machine language), and then give it
\to the user as "FactorInteger[3858783237285638838513] for him to
/incorporate as a canned functon.)

I think a *good* overview of the sort of things Tim is talking about
can be found in a book called _Programming Language Concepts_. I think
the author's last name starts with an M. The book is (I think) at
home, so I can't say for sure.

Anyway, to reiterate: is there a way, once something is written in
SmalltalkAgents, to get it running in more widespread enviroments?


+-----------------------+-------------------------------------+
|"Standard Disclaymore" |"...drag them, kicking and screaming,|
|pgf@srl03.cacs.usl.edu |into the Century of the Fruitbat."   |
+-----------------------+-- Terry Pratchett, _Reaper Man_-----+