Levine, the genius taylor
It is impossible to begin a discussion of psychological principles of programming language design without recalling the story of “Levine the Genius Tailor.” It seems that a man had gone to Levine to have a suit made cheaply, but when the suit was finished and he went to try it on, it didn’t fit him at all. “Look,” he said, “the jacket is much too big in back.”
“No problem,” replied Levine, showing him how to hunch over his back to take up the slack in the jacket.
“But then what about the right arm? It’s three inches too long.”
“No problem,” Levine repeated, demonstrating how, by leaning to one side and stretching out his right arm, the sleeve could be made to fit.
“And what about these pants? The left leg is too short.”
“No problem,” said Levine for the third time, and proceeded to teach him how to pull up his leg at the hip so that, though he limped badly, the suit appeared to fit.
Having no more complaints, the man set off hobbling down the street, feeling slightly duped by Levine. Before he went two blocks, he was stopped by a stranger who said, “I beg your pardon, but is that a new suit you’re wearing?”
The man was a little pleased that someone had noticed his suit, so he took no offense. “Yes it is,” he replied. “Why do you ask?”
“Well, I’m in the market for a new suit myself. Who’s your tailor?”
“It’s Levine — right down the street.”
“Well, thanks very much,” said the stranger, hurrying off. “I do believe I’ll go to Levine for my suit. Why, he must be a genious to fit a cripple like you!”
Would it be inappropriate to concot a version of this story called “Levine the Genius Language Designer”? The first problem in discussing language design is that we do not know the answer to that question. We do not know whether the language designers are geniuses, or we ordinary programmers are cripples. Generally speaking, we only know how bad our present programming language is when we finally overcome the psychological barriers and learn a new one. Our standards, in other words, are shifting ones — a fact that has to be taken into full consideration in programming language design.
G.M. Weinberg, The Psychology of Computer Programming
Fun and programming
I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
Alan J. Perlis (April 1, 1922-February 7, 1990)
Interactive programming
Here’s an anecdote I heard once about Minsky. He was showing a student how to use ITS to write a program. ITS was an unusual operating system in that the `shell’ was the DDT debugger. You ran programs by loading them into memory and jumping to the entry point. But you can also just start writing assembly code directly into memory from the DDT prompt. Minsky started with the null program. Obviously, it needs an entry point, so he defined a label for that. He then told the debugger to jump to that label. This immediately raised an error of there being no code at the jump target. So he wrote a few lines of code and restarted the jump instruction. This time it succeeded and the first few instructions were executed. When the debugger again halted, he looked at the register contents and wrote a few more lines. Again proceeding from where he left off he watched the program run the few more instructions. He developed the entire program by `debugging’ the null program.
From an LtU discussion
Closure Satori
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing – is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil – objects are merely a poor man’s closures.”
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.
(Stolen from here)
Abelson and Sussman on Programming
Programs must be written for people to read, and only incidentally for machines to execute.
Abelson & Sussman, SICP, preface to the first edition
Imagine
Posted to comp.lang.scheme on January 17, 1996, for Scheme’s twentieth
birthday:
((I m a g i n e)
(shriram@cs.rice.edu)
(((Imagine there's no FORTRAN)
(It's easy if you try)
(No SML below us) (Above us only Y)
(Imagine all the people)
(Living for their Chez))
((Imagine there's no memory leaks)
(It isn't hard to do)
(Nothing to malloc(3)
or free(3) for)
(And no (void *) too)
(Imagine all the people)
(Living in parentheses))
((You may say I'm a Schemer)
(But I'm not the only one)
(I hope someday you'll join us)
(And the world will be as
(lambda (f) (lambda (x) (f x)))))
((Imagine those continuations)
(I wonder if you can)
(No need for C or pointers)
(A brotherhood of Dan)
(Imagine all the people)
(GCing all the world))
((You may say I'm a Schemer)
(But I'm not the only one)
(I hope someday you'll join us)
(And the world will be as
(lambda (f) (lambda (x) (f x)))))))
'shriram
A Bit About Late Binding From Alan Kay
Most software is made by programmers creating text files that are fed to a compiler and loader which makes a runable program. One can tell how early- or late-bound a system is by looking at the things that can be changed while the program is running. For example, it is generally true of C based systems that most changes in the program have to be done by going back to the text files, changing them, and recompiling and loading them. This is even true of Java. Organizationally, this often leads to at most one or two system builds a day before most bugs can be found.
A late-bound system like LISP or Smalltalk can change pretty much everything while it is running — in fact, both these systems are so good at this that their development systems are written in themselves and are active during runtime. For example, a program change in Smalltalk takes less than a second to take effect, thus many more bugs can be run down and fixed.
But late-bound has some deeper and more profound properties that include abilities to actually change the both the structure and metastructure of the language itself. Thus an important new idea can be assimilated into the constantly evolving process that is the system.
Another aspect of late-binding is the ability to change one’s mind about already instantiated structures that are already doing work. These can be changed automatically on the fly without harming the work they are already doing.
Etc. Wheels within wheels.
These ideas are not new, but they are quite foreign and out of the scope of the way most programming is done today. — Alan Kay.
