Just added to my quotesfile.

[brooksmoses]

I recently came across a copy of the papers from the 1993 History of Programming Languages (HOPL-II) Conference, and was reading Alan Kay's paper on "The Early History of Smalltalk". He described the process of how, as he did with object-oriented programming, one often sees sketches of ideas many times before the idea really fully forms. I had a moment of something like that, reading this passage:

It started to hit home in the Spring of '74 after I taught Smalltalk to 20 PARC nonprogrammer adults. They were able to get through the initial material faster than the children, but just as it looked like overwhelming success was at hand, they started to crash on problems that didn't look to me to be much harder than the ones they had just been doing well on. One of them was a project thought up by one of the adults, which was to make a little database system that could act like a card file or rolodex. They couldn't even come close to programming it. I was very surprised because I "knew" that such a project was well below the mythical "two pages" for end-users we were working within. That night I wrote it out, and the next day I showed them all how to do it by themselves. Later, I sat in the room pondering the board from my talk. Finally, I counted the number of nonobvious ideas in this little program. They came to 17. And some of them were like the concept of the arch in building design: very hard to discover, if you don't already know them.

The connection to literacy was painfully clear. It isn't enough to just learn to read and write. There is also a literature that renders ideas. Language is used to read and write about them, but at some point the organization of ideas starts to dominate mere language abilities. And it helps greatly to have some powerful ideas under one's belt to better acquire more powerful ideas.

And that's why reading a lot about other people's programming is important. I'm not sure entirely what the right way to draw the parallel is exactly, since programming and literature are structurally different. Part of the difference is that programming languages are themselves implemented as programs and embody programming design, and so the line between learning to read and write in many languages and reading "program literature" is blurry. There is also the difference that literature is fundamentally created to be read by humans; the acts of "using" the literature and of learning from it are tightly intertwined. Computer programs are considerably less so, and sitting down to read them is often difficult and unrewarding.

I don't yet know where to go with that. I think I'll sit down with my copy of Knuth's TeX: The Program and let it percolate a bit.

Comments

[kiya]

Meanwhile, for entirely unrelated reasons, I just found this humor file, and wanted to share it with you and keshwyn. I will go drop it on the Houseboat too.

[brooksmoses]

Interestingly, as I was writing this, allbery posted this little post about an update to a Perl module he's written, which overlays a stack of hash tables and returns a combined result, with a local overlay into which additions and deletions to the hashtable can be stored. Maybe that's what programming literature looks like -- descriptions of ideas.

The key idea there isn't how one implements this combined hash table (given the sketch of the specification, I expect it's fairly straightforward), but the idea that one can take a pile of hash tables and create a combined interface around them, and the handful of accompanying ideas about how to handle things like "what if the same key is in multiple tables", or "what if I want to write to this combined object?"

I do find myself wondering about large-scale programming literature, though, and what the good examples of that look like -- aside from TeX: The Program, I mean, as that's a really obvious example.

[eagle]

This is exactly why I've set it as a goal this year to start learning how to program again, rather than resting on my skills like I have been for the past five years or so. I know enough already to do a variety of things, but the intellectual challenge and excitement of learning a new way to look at something or a new way to write something has been missing for a bit. Finding the time is always the hard part, but since I'm starting with learning Java, work is springing some time for me.

My first time inside Eclipse definitely supported that feeling. Not that I'm unhappy with my programming environment now, but it's fascinating to see how differently one can create an environment, and to stretch my mind around a different framework.

[wcg.livejournal.com]

That's a really profound insight he has, about literature rendering idea. I think it's true in any field of endeavor.

[novalis.livejournal.com]

I am actually more curious about what the list of 17 ideas is. It's too bad he doesn't share that list.

[pure-agnostic.livejournal.com]

I think this quote gets to the pith of the topic: "It isn't enough to just learn to read and write. There is also a literature that renders ideas. Language is used to read and write about them, but at some point the organization of ideas starts to dominate mere language abilities."

Whether working with written/spoken language or programming skills, some people quickly grasp the technical aspects of the language and soon acquire the ability to express themselves quite succinctly. Others never move beyond merely using the language crudely. I've seen a lot of bad code written by programmers who think programming is only about coding switch statements, if-else blocks, and loops. They never understand programming on a larger scale and how to express the intent of a function, class, or library. Those who do comprehend programming on a larger scale tend to organize their code much differently - and that organization dominates over the peculiarities of any specific language.