[Cryptography] Use Linux for its security

[Henry Baker]

At 07:43 AM 10/1/2016, Ron Garret wrote:
>On Sep 30, 2016, at 1:24 PM, Henry Baker <hbaker1 at pipeline.com> wrote:
>
>> This also *guarantees* that Lisp can never compete
>> with some other languages in the efficiency of high volume I/O.
>
>But if you really care about reading arrays efficiently you probably want to use a binary representation with a header that tells you the size and use read-sequence.  That can be as fast as C.
>
>(Surely you knew all this?  Why are you of all people spreading FUD about Lisp???)

My problem is that Common Lisp deserved a lot of the criticisms aimed at it -- particularly its (in)efficiency on "stock" (aka C-language-oriented) hardware.

The major complaint about PL/I was its ability to invoke enormous amounts of machinery in order to do trivial tasks like AND'ing two bit strings; Common Lisp didn't listen to this criticism of PL/I, and thus fell for the whole CISCy series of complaints.

(I spent a good fraction of my early programming years bypassing & re-implementing truly awful PL/I library routines; e.g., each one started out by invoking the world's most heavy-weight register save protocol.)

C avoided this issue (at least prior to C++) by pushing all "CISC"-type complexity into its standard library.  Thus, the major signal for "unreasonable complexity lies ahead" was a .h header and a call to a standard library routine.  (This signal wasn't 100% reliable: "alloca" ideally is a compiler-generated register increment even though it looks like a heavy duty standard library call.)

My advice to computer language designers: when users have to routinely construct their own run-time systems to get around the built-in inefficiencies of the language's *standard* mechanisms, then you've failed.

The explosion in roll-your-own malloc's in C is Exhibit #1 in what's wrong with trying to be all things to all people on a standardization committee.  (BTW, "malloc" is short for "malware locator" -- where a malware writer looks for openings -- and if the NSA had been clueful about software back then, NSA would have been its most vocal proponent.)

My advice to every programmer: always look at the machine code that is produced by your source code *while* you're writing that source code; you won't believe what kinds of garbage that the compiler & run-time system occasionally puts out.  This applies in spades to "higher level" languages like C++, Lisp, etc.

P.S.: If you follow my argument to its bitter end, you realize that the *garbage collector* itself is the biggest offender in "hidden complexity".  Hence my interest in "linear types" ("linear logic") which allows the higher-level expression of a garbage collector to be exposed in a computer language's source language.