Tuesday, September 9, 2008

URBBR #2: How Bad Is This Book?

[The following has been... well, only the names have been changed to protect the endangered toads.]

We have a One-Paragraph Test for fiction. Not a complicated test, it involves reading the first paragraph and then deciding. If We are really undecided We can read a second paragraph, but that is a Bad Sign.

For non-fiction We look at the blurbs the author managed to suck out of unwilling blurbers. Well, OK, We do not really want the blurbs to be from blurbers, We want them to be reviews and We know they have cherry-picked the review sentences so everything gets discounted about an order of magnitude. 

And there are two such reductions applied, the second for the source of the review. Kirkus Review of Books... well, just quoting them gets a book back onto the shelf. In the wrong section, upside-down, binder in.

Here is the Gold Standard for non-fiction back covers (hmm, the URL goes to the whole book, be clever and click "Back Cover"): The Glory of Their Times. Yes, you need to read this book, and no I do not give a rat's ass if you like baseball just read it.

We turn now to a book I have been asked to review, which will go unmentioned for the same reason I restacked it binder-in:
"This work strikes a balance between the pure functional aspects of Blub and the object-oriented and imperative features that make it so useful in practice, enable .NET integration, and make large-scale data processing possible."
The clever unwilling blurber always manages to say something nice by talking about something else, in this case the language .... instead of the book for 90% of the blurb. What does he say about the book? 

It strikes a balance. Wow. How big a put-down is that? Note that the reviewer did not say "a perfect balance" or even "a good balance". And what the Hell does balance buy me anyway?

The good news is that We cannot discount that 90%, Our micrometer does not go that low. But We better check the author of the blurb.
—John Doe, PhD, Researcher, Blubber Ltd.
Oh. The people selling Blub.

The neat thing is that We now know the book is awful and that John was slowest to hide under his desk when the marketing people came around looking for a recommendation.

Unread Book Review: Zen Style Programming, Nils Holm

On comp.lang.lisp, Nils M Holm wrote:
> I am happy to announce that free pre-release copies of my latest book
>           "zen style programming"
> are now available.
> Blurb
> The primary purpose of programs is to be understood by fellow human 
> beings,

Nonsense! Nils has been reading Knuth or something. The purpose of programs is to model other processes so the most important virtue of a language is the ease of building programs with it. Yes, those programs should tend to be clear but that just requires powerful constructs, long names, and support for the functional paradigm. 

Besides, "revise"  means "rewrite from scratch anyway because the way this was done is all cocked up" so we do not generally have to understand programs to work on them.
> hence programming languages should have certain properties:
Bzzt!  The source of obfuscation is the programmer, not the programming language.
>     * Small size and uniformity
Hand-waving! Nils has been reading Graham or something. Small size as a requirement does not follow even if one were to exalt human readability to Prime Directiveness. You could just have good names for functions, like pathname-sans-file. And an editor that knows how to get to a hyperspec.

     * Unambiguousness
     * A high degree of abstraction
     * Achitecture neutrality
 
 The first part of this book introduces the concept of functional  programming and describes a purely symbolic language that fulfills these requirements. This language is a minimalisti variant of Scheme whose only data types are symbols and ordered pairs. Nothing else is required to describe algorithms for solving a variety of different problems.

The second part of the book shows how to apply the techniques of  symbolic programming to some problems of varying complexity. Topics discussed in this part range from simple functions for sorting or permuting lists to ``lazy'' data structures, regular expression matching, formal language translation, and declarative programming.

The third part, finally, shows how to implement the abstraction layer that is necessary for solving problems in an abstract way on a concrete computer. It reproduces the complete and heavily annotated source code for an interpreter of symbolic LISP and provides an example of clear and readable C code.

This book contains the full source code to a source-to-source compiler, a meta-circular interpreter, a logic programming system, and to the language that is used to implement all of these. 
Damn, that was a lot of work. I should be nicer to Nils. Here's the book, anyway. Let us see what it says:
"The first points are no-brainers."
Come on, Nils, we talked about the hand-waving. 
"If a language is too complex..."
Well, by the meaning of the word "too" I think you are on safe ground for the rest of that sentence, but it begs the question of how too is too? Nils needs to make his case or judge someone else's case, not both.
"...programmers will have to look up things in the manual perpetually instead of concentrating on the actual problem."
So now we need programs to be understandable by people who do not know the programming language? I think that was a design goal for COBOL. Anyway, that does not give you a language with a small instruction set, it gives you a language with long, well-chosen names. Like COBOL.

As for looking things up, I want to meet the guy who looks up delete-duplicates when the status bar is saying:

    delete-duplicates sequence &key from-end test test-not start end key

Let's see if there are any more self-serving rationalizations....
"The class of problems that can be solved by programs is much smaller. It typically involves very clearly defined tasks like
-- find permutations of a set;
-- find factors of an integer;
-- represent an infinite sequence;
-- translate formal language A to language B;
-- find a pattern in a sequence of characters;
-- solve a system of assertions.
Of course these tasks have to be defined"

Nils must be a professor of computer science. Programs exist to model real-world entities of arbitrary complexity, tho good luck with the human mind. OTOH, simulations of car crashes are admitted into evidence by finicky courts and some people even model human private Algebra tutors. Unfortunately those things are a ton of work which is why you will not see academics doing that.

Now about the title. Zen zen zen, what an affectation! Zen this, zen that. I am going to write a book on The Zen of Ordering Take-Out Pizza.

What is zen about zenlisp? Never justified, never even addressed. Does the author think zen means small because it is a small word? I like that, actually. I tried googling for synonyms: oops. I think they would be pleased down at the monastery. 

So much for the name. How about the language itself? Raison d'etre? 
Zenlisp is similar to Scheme, but simpler.
That sounds like being rescued from a desert island and then dropped off in the middle of the Sahara. No, the only reason ZenLisp exists is because Lisp is a venus flytrap of a blackhole delivered by John McCarthy an alien from outer space sent to stop good programmers from Actually Programming. Apparently Grace Hopper was just a few lines of code away from anti-gravity and time travel so They sent John down with Lisp so any good programmer would get so excited about the language itself they would stop programming time-travel applications, take out their CodeWarrior CDs, and start implementing a Lisp using (wait for it) C.

The ones who really want to avoid programming will then write a book about their language. 

So I wonder what Nils will do now.