This is the tenth edition of Code Reads, a series of discussions of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

You don’t have to read too far into Guy Steele’s “Growing a Language” to figure out what he’s up to. In this 1998 talk on the nature of programming-language design, Steele writes under a set of constraints: he may use any word of one syllable, but if he wishes to use longer words, he must define them first — using only words of one syllable.

Steele aimed to illustrate how awkward and confining it can be to try to express yourself when you don’t have access to an extensive vocabulary: “I wanted to show you want it is like to use a language that is much too small.” (By this point in the talk, he has already defined “language.”) His larger purpose is to advocate a philosophy of programming-language development that aims for neither a small nor a large language, but rather for one that is “designed to grow.”

Such growth is to be propelled not by a closed cadre of gurus but by the language’s users, who have been given an appropriate set of tools to extend the language. The shape of the language is such that these user-generated additions do not look or behave any differently from the “original” elements of the language provided by its initial creators. Nearly a decade later, this argument — which parallels similar ideas that have become popular in the open-source software community as well as in the “user-generated” enthusiasms of Web 2.0 — sounds neither arcane nor controversial.
[Read more…]

This is the ninth edition of Code Reads, a series of discussions of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

The annals of programming include a small but significant number of radical thinkers who propose total overhauls of our basic techniques for making computers perform useful tasks. One of them is the late John Backus. Backus was the central figure in the creation of FORTRAN — the archetypal first-generation “higher level” programming language — and the devising of the BNF (“Backus Naur Form” or “Backus Normal Form”), a formal method for specifying programming-language syntax.

In his 1977 Turing Award lecture, however, Backus stepped away from the world he’d helped shape and asked, “Can Programming Be Liberated from the Von Neumann Style?” It’s a question that gets at fundamentals, at breaking free of founding constraints. It’s like asking whether psychology could be liberated from Freud, or physics from Einstein.

Backus describes the prevalent Von Neumann paradigm of computing:

In its simplest form a von Neumann computer has three parts: a central processing unit (or CPU), a store, and a connecting tube that can tramsit a single word between the CPU and the store (and send an address to the store). I propose to call this tube the von Neumann bottleneck. The task of a program is to change the contents of the store in some major way; when one considers that this task must be accomplished entirely by pumping single words back and forth through the von Neumann bottleneck, the reason for its name becomes clear….

Surely there must be a less primitive way of making big changes in the store than by pushing vast numbers of words nback and forth through the von Neumann bottleneck. Not only is this tube a literal bottleneck for the data traffic of a problem, but, more importantly, it is an intellectual bottleneck that has kept us tied to word-at-a-time thinking instead of encouraging us to think in terms of the larger conceptual units of the task at hand.

(I will pause here to note the presence of that word “tube.” Perhaps Senator Ted Stevens, far from being a techno-rube, was actually a student of Backus.)
[Read more…]

This is the eighth edition of Code Reads, a series of discussions of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

The Cathedral and the Bazaar, Eric Raymond’s classic essay on open-source software development, is now 10 years old. I first read it soon after its publication. At that time the term “open source” was newly minted, and the movement was in the news chiefly because (a) it seemed to offer a threat to Microsoft, and (b) Netscape, at a late stage of its war with Microsoft, had decided to release its browser code under open-source license. I was editing Salon’s technology section in those days, and one of our central projects was Andrew Leonard’s thorough coverage of the open-source phenomenon. (He interviewed Raymond in early 1998.)

I think it’s fair to say that today CatB (as Raymond and others now call the essay) has proved its importance independent of its place in the long-concluded browser-war saga. I’ve reread it several times over the years since, and each time find something new and valuable.

[Read more…]

This is the seventh edition of Code Reads, an aspiring-to-weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

In the early 1980s, president Ronald Reagan proposed the missile-defense program known formally as the Strategic Defense Initiative (SDI) — and informally as “Star Wars.” Then the Pentagon and its contractors began trying to build the thing. They’re still at it today.

In 1985, David Lorge Parnas — a well-reputed computer scientist best known for elucidating the principle of “information hiding” that underlies modern object-oriented techniques — publicly resigned from a government computing panel that had been convened to advise the Star Wars effort. Star Wars couldn’t be built according to the government’s requirements, Parnas declared, because the software simply couldn’t be built. Unlike many who weighed in on Star Wars, Parnas didn’t express opposition on moral or political grounds; he was, he said, a longtime toiler in the field of defense software engineering, and had no “political or policy judgments” to offer. He just thought that SDI’s engineering aspirations lay impossibly far outside the bounds of real-world capabilities.

In support of this judgment Parnas composed a series of eight short essays that the American Scientist — and later the Communications of the ACM — published together under the title, “Software Aspects of Strategic Defense Systems.” It’s a magnificently forthright piece of writing — it encapsulates the best of the engineering mindset in prose. And it explains some fairly complicated notions in terms anyone can follow.

For instance, it wasn’t until I read Parnas’s paper that I fully understood why digital systems are so much harder to prove reliable than analog ones. [Read more…]

This is the sixth edition of Code Reads, an aspiring-to-weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s thefull Code Reads archive.

Mitch Kapor first presented his Software Design Manifesto at PC Forum in 1990. It got published in Dr. Dobbs’ Journal in 1991, and later appeared as the first chapter of Terry Winograd’s book Bringing Design to Software (much of the book is available in online form now). At a point roughly midway between the start of the personal-computing revolution in the mid-’70s and the present, Kapor threw down a gauntlet: Computers were too hard to work with. “Everyone I know (including me) feels the urge to throw that infuriating machine through the window at least once a week,” Kapor wrote.

The PC revolution’s promises of “personal empowerment” remained unfulfilled because the software that drove the miraculous new machines was simply not well-enough shaped. The people who made it weren’t thinking clearly enough about how their products would be used. Somebody had to do that work; Kapor argued that programmers probably weren’t the best people to take it on, and proposed the creation of a new discipline of “Software Designer” to wear this mantle.
[Read more…]

This is the fifth edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

I have felt for a long time that a talent for programming consists largely of the ability to switch readily from microscopic to macroscopic views of things, i.e., to change levels of abstraction fluently.
— Donald Knuth, “Structured Programming with go to Statements”

We’ve been looking at Edsger Dijkstra’s principles of structured programming for some time now. Today we’ll conclude that phase of this series with a look at Donald Knuth’s “Structured Programming with go to Statements” (1974). Since “Go To Statement Considered Harmful” was the most famous declaration of the structured programming ethos, Knuth’s title itself was a kind of provocative joke — like naming a paper “Judaism with Idols” or “Vegetarianism with Pork Chops.” And that combination of playfulness and attentive humor extends throughout the article, from the epigraphic references to Bob Dylan (and a laxative advertisement!) on. In the middle of a complex analysis of an algorithm in ALGOL, in which Knuth is reviewing ideas for new ways to notate a particular kind of loop, he interjects:

Readers who remember 1967 will also appreciate [this] second suggestion,
turn on begin S; when B drop out; T; end.

The levity’s a good thing, because, I confess, as a non-mathematician and only a rudimentary programmer I approached Knuth’s formula-laden text with trepidation. And there remain parts of “Structured Programming with go to Statements” that are beyond me. But for the most part, this text bears out Knuth’s reputation for brilliant clarity — it’s surprisingly accessible.

[Read more…]