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