Saturday, September 24, 2016

What a Programmer Does (1967)

The following is a cleaned-up version of Google Doc OCR reading of "What a Programmer Does" - Datamation (April 1967). It was noted as possibly being written by someone named Moore. See also the discussion on HN:

WHAT A PROGRAMMER DOES

It has been believed that a programmer occasionally writes code and gets it running on a computer, and that this is what he is paid for. In spite of his obvious inefficiency, no one else seems to do this work more effectively. However, his activity is still observed principally as loafing-a kind of ritual (like the British and tea time) which must be put up with.

Another view of what a programmer does addresses more constructively all that 'wasted' time and ritual. To understand this view, we must see what it is the programmer is tying to build. We all have some idea of what a program is, but not very often do we see a program from its author's point of view. Whatever a program is, it exists as an organization of many pieces with a high degree of structural integrity, and it is stable in its environment. That environment includes the mechanisms of the program itself, as well as the input data. To establish this integrity is the usual debugging task.

However, there is more to the environment of our program. It must be stable with respect to the threat of operator misunderstandings, with respect to invalid data, and to changes in specifications, up to a point. Obviously, to develop a code structure that is stable in the face of all these unknowns is a very difficult task. As a matter of fact, we programmers all cheat. The structure we develop includes more than the running code, more than the symbolic code, or even the operator's guide, the maintenance guide, or the design guide. For in fact, in response to any serious breach of the program's integrity, a programmer will become involved, as part of the integral organization built by the original programmer. If one now looks closely, he can begin to recognize the intent of those steps in the ritual of programming.

program dybbuk

In this ritual, the programmer must clearly anticipate the sources of threats to his program. He must imagine techniques to deal with those threats, and anticipate the instabilities of those techniques. Of course, as the programmer has a mind trained in objectivity, he will realize that in fact he cannot scare off the dybbuk who already is making its home in his structure by the time debugging begins. It is at this point that the agony of programming begins. The structure is now nearly mortal, and its vitality may well be stolen by a form of the "enemy' which could and ought to have been anticipated by its creator. The enemy, the dybbuk, of course is entropy; it appears in many forms, and some times in many places simultaneously.

The program must not only have a static stability, in withstanding such things as invalid data, but must also further respond to dynamic changes in environment. Of these two types of stability the first can generally be provided by careful programming, provided the ultimate operating environment is reasonably organized. A program is rarely killed by a failure of static stability. The death usually occurs because of a failure in the program's mechanisms for maintaining stability, in its abilities to respond to environmental change.

One mechanism for maintaining stability is the maintenance programmer. The longevity of the program is therefore dependent on the capability, comprehension and intelligence of this person. But humans are not omniscient in comprehending programs. As a matter of fact one of the most difficult intellectual endeavors is the analysis and comprehension of an existing program structure. Thus the resistance of a program to unsettling forces is critically dependent on its structural clarity, as measured by the effort required to analyze and comprehend it.

We see, then, that the structure called a program consists of more than we first thought, and includes stabilizing mechanisms which are far broader than the code itself.

the traumatic periods

We should consider the traumatic periods of the life of a program. The terminal trauma of a program occurs when it is challenged by entropy beyond its capacity to adjust. Obviously every program will have, or has had, this trauma, after which it is of no use. Most programs go through at least two additional traumatic periods. The first is when the static stability is first being developed-that is, during debugging. The second is when the program is first placed into a real, instead of artificial, environment - during system testing.

In both of these periods a major problem is the exercise and further development of the stabilizing mechanisms which allow the program to run under extreme, unsettling entropic forces. In both of these periods the primary instrument of stability is the original programmer, who reacts toward an indication of disorganization (a "bug"). He may well have built into the program checks which aid him in identifying the disorder and its cause.

The ritual of programming is of great consequence because it deals with the communication between the original program author and the programmer responsible for maintaining the structural integrity of the program. When these two are the same man, there is still a significant amount of communication between them; in a large program one cannot remember the whole program. The author must organize the program into concept units, and leave a clear trace of the organization, as well as the content, of each unit. Thus that part of the ritual which attempts to provide the basis for comprehending a program structure is, in fact, the part of the programming activity which most directly supports the vitality of the program, from debugging on.

In fact, experience generally shows that an intense concentration by the programmer in optimizing the comprehensibility of a program's structure pays off, not only in debugging, but also in ease of coding and program layout. If a program is structured so that it consists of a set of functions that can be understood separately, then the layout of the program should be obvious, or at least explainable. Furthermore, the coding effort should be uncluttered by considerations beyond the algorithms for the "current" function.

the primary role

Thus, a programmer develops his program so that a human can comprehend it. Initially this is merely selfprotective, as he must understand the program enough to get into production. It would appear that all good programmers attempt to do this, whether they recognize it or not. Furthermore, no one has seen a program which the machine could not comprehend but which a human did. Not even bad programmers (those whose programs die young), write comprehensible code; if they did, their programs would survive and they would be better programmers. Both the value and quality of a programmer's work improve directly with the importance he places on communicating his program to a human, rather than merely to the machine.

A programmer does not primarily write code; rather, he primarily writes to another programmer about his problem solution. The understanding of this fact is a final step in his maturation as a technician.

Thursday, September 22, 2016

Tools for Free Virtualization Management

Some good tools to take a look at if you haven't already are ManageIQ and OVirt.

ManageIQ according to its FAQ, is a "cloud management platform (CMP) that adds additional capabilities to your existing virtualization, private cloud, and hybrid cloud infrastructure. ManageIQ provides scaleable self-service interfaces, provisions virtual system images, enables metering and billing, and provides workload optimization through established policies."

OVirt according to its about page, is a "virtualization management application. That means that you can use the oVirt management interface ( the oVirt engine) to manage hardware nodes, storage and network resources, and to deploy and monitor virtual machines running in your data center. If you are familiar with VMware products, it is conceptually similar to vSphere. oVirt serves as the bedrock for Red Hat's Enterprise Virtualization product, and is the 'upstream' project where new features are developed in advance of their inclusion in that supported product offering."

Both of these are sponsored by RedHat, and ManageIQ is at a higher level where it is managing existing virtualization providers, while OVirt is more of a virtualization provider, although it has a management UI.

Friday, September 9, 2016

Caltech Simulates Milky Way

Caltech has simulated the Milky Way (the one without chocolate) in realistic fashion. They anticipate that upcoming work using even more computing time 'should lead to predictions about the very faintest and smallest of dwarf galaxies yet to be discovered'. Looking forward to it! (Note: HN community also commented on this.)

Monday, May 30, 2016

Alan Kay's Reading List

Thought this was interesting. Alan Kay of PARC, etc. fame prepared a reading list for his students, as listed here on Squeakland. Please visit that page for links, but I've listed here just as a backup copy.

Technology & Media

  • Gutenberg Galaxy by MARSHALL MCLUHAN
  • Understanding Media by MARSHALL MCLUHAN
  • The Myth of the Machine by LEWIS MUMFORD
  • Technics and Civilization by LEWIS MUMFORD
  • Technology, Management,and Society by PETER DRUCKER
  • Innovation and Entrepreneurship by PETER DRUCKER
  • Amusing Ourselves to Death by NEIL POSTMAN
  • The Disappearance of Childhood by NEIL POSTMAN
  • Conscientious Objections by NEIL POSTMAN

Learning & Creativity

  • The Psychology of the Child by JEAN PIAGET
  • To Understand is to Invent by JEAN PIAGET
  • Thought and Language by LEV VYGOTSKY
  • Mind in Society by LEV VYGOTSKY
  • The Psychology of Art by LEV VYGOTSKY
  • Towards a Theory of Instruction by JEROME BRUNER
  • The Relevance of Education by JEROME BRUNER
  • Instead of Education by JOHN HOLT
  • Teach Your Own by JOHN HOLT
  • Essays into Literacy by FRANK SMITH
  • Lateral Thinking by EDWARD de BONO
  • Six Thinking Hats by EDWARD de BONO
  • The Inner Game of Tennis by TIM GALLWEY
  • Nurtured by Love by SHINICHI SUZUKI
  • The Secret of Childhood by MARIA MONTESSORI
  • School and Society by JOHN DEWEY
  • Freedom and Culture by JOHN DEWEY
  • Act of Creation by ARTHUR KOESTLER
  • The Ghost in the Machine by ARTHUR KOESTLER
  • Mindstorms by SEYMOUR PAPERT
  • The Childrens' Machine by SEYMOUR PAPERT

Anthropology & Psychology

  • Myths to Live By by JOSEPH CAMPBELL
  • The Masks of God by JOSEPH CAMPBELL
  • Language and Species by DEREK BICKERTON
  • The Psychology of Literacy by SILVIA SCRIBNER & MIKE COLE
  • The Origin of Consciousness in the Breakdown of the Bicameral Mind by JULIAN JAYNES
  • The Interpretation of Cultures by CLIFFORD GEERTZ
  • Beyond Boredom and Anxiety by MIHALY CSIKSZENTMIHALY
  • Flow by MIHALY CSIKSZENTMIHALYI
  • New World, New Mind by ROBERT ORNSTEIN & PAUL ERLICH
  • Maps of the Mind by CHARLES HAMPTON-TURNER
  • Man and his Symbols by CARL JUNG
  • Modern Woman in Search of a Soul by CARL JUNG
  • Society of Mind by MARVIN MINSKY
  • Archetypes by ANTHONY STEVENS

Philosophy

  • Timeaus by PLATO
  • Republic by PLATO
  • History of Western Philosophy by BERTRAND RUSSELL
  • Human Knowledge, Its Scope and Limits by BERTRAND RUSSELL
  • Sceptical Essays by BERTRAND RUSSELL
  • The Passion of the Western Mind by RICHARD TARNAS
  • Ascent of Man by JACOB BRONOWSKI
  • Wisdom, Information & Wonder by MARY MIDGLEY
  • Science as Salvation by MARY MIDGLEY
  • The Human Condition by HANNAH ARENDT
  • Science and Sanity by COUNT KORZYBSKI
  • Science is not Enough by VANNEVAR BUSH
  • What I Believe by MARK BOOTH (Ed)
  • Te-Tao Ching by LAO-TZU
  • Zen Mind, Beginners' Mind by SHUNRYU SUZUKI

Art & Perception

  • Civilisation by KENNETH CLARK
  • What is a Masterpiece by KENNETH CLARK
  • Art and Illusion by ERNST GOMBRICH
  • Eye and Brain by RICHARD GREGORY
  • Visual Thinking by RUDOLF ARNHEIM

Design

  • Notes on a Synthesis of Form by CHRISTOPHER ALEXANDER
  • Gossamer Odyssey by MORTON GROSSER
  • Vehicles by VALENTINO BRAITENBERG
  • The Living Brain by W. GRAY WALTER
  • The Visual Display of Quantitative Information by EDWARD TUFTE
  • Envisioning Information by EDWARD TUFTE

Science & Mathematics

  • The Machinery of Life by DAVID GOODSELL
  • The Ring of Truth by PHILIP MORRISON
  • The Animal in Its World by NIKO TINBERGEN
  • Relativity Visualized by L.C. EPSTEIN
  • Engines of Creation by ERIC DREXLER
  • The Blind Watchmaker by RICHARD DAWKINS
  • The Selfish Gene by RICHARD DAWKINS
  • Dragons of Eden by CARL SAGAN
  • Broca's Brain by CARL SAGAN
  • Neuroethology by EWERT
  • The Character of Physical Law by RICHARD FEYNMAN
  • QED by RICHARD FEYNMAN
  • The God Particle by LEON LEDERMAN
  • From Quarks to Cosmos by LEON LEDERMAN
  • The Double Helix by JAMES WATSON
  • Fractal Geometry by BENOIT MANDELBROT

Politics & Economy

  • An American Primer by DANIEL BOORSTIN
  • The Americans by DANIEL BOORSTIN
  • The Federalist Papers by MADISON, et al
  • The Anti-Federalist Papers by RALPH KETCHAM (Ed)
  • Common Sense by TOM PAINE
  • The Rights of Man by TOM PAINE
  • The Age of Reason by TOM PAINE
  • An Aristocracy of Everyone by BENJAMIN BARBER
  • The Zero Sum Society by LESTER THUROW
  • Economics Explained by LESTER THUROW
  • Head to Head by LESTER THUROW
  • Made in America by MIKE DERTUOZOS (Ed)

Computers

  • Building Large Knowledge-Based Systems by DOUG LENAT
  • LISP 1.5 Manual (MIT Press) by JOHN McCARTHY
  • Computation: Finite and Infinite Machines by MARVIN MINSKY
  • The Architecture Machine by NICHOLAS NEGROPONTE
  • Soft Architecture Machines by NICHOLAS NEGROPONT

Friday, May 27, 2016

Case for Moon Has Some Good Points

If you're interested in space colonization, this is a must read/listen:

Case For Moon

Also, that beard is scary cool.

Thursday, May 12, 2016

GBoard Review: Too Much Mistyping for Me

I downloaded the initial version of GBoard today for iOS and was looking forward to using it. Unfortunately, I had to stop after a minute because it kept misregistering characters I was typing, and I don't have that problem with the iOS built-in keyboard.

At first I thought this was due to the layout being different, but it isn't. Here's a screenshot to compare GBoard with the iOS keyboard:


(Difference provided by Resemble.js.)

My thought now is that GBoard must not register keys in the same way that iOS's keyboard does, leading to a lot of mistyped characters for me, and this might be due to having a different text size setting in iOS.