Programming is just like writing

http://plpatterns.blogspot.com/2007/09/programming-is-writing.html

by saurabh • 15 years ago

23 27 15 years ago

plpatterns.blogspot.com

hsmyers• 15 years ago

As someone who was trained to write by the editors of the Chicago Sun-Times and the Tribune long before I learned to program, I initially found the title of this a bit confusing. My chain of thought went something like; a. writing is (now) easy so, b. programming (if just like writing) must be easy. And while I'll admit that that is true now it wasn't always and won't be if I change to another language. Other than that 'huh' moment enjoyed the article and pretty much agree with it...

rauljara2• 15 years ago

Interesting idea, and indeed there are a lot of parallels between writing arguments and writing programs. But the title gives me pause, because the acts feel so very different. A gigantic difference is that, in an essay, your idea can still be communicated even if it is expressed ungrammatically, even if you skip certain steps. Your audience can often correct your grammar, and fill in your gaps. A computer is far more dumb, and simply will not be able to run your program if you use illegal syntax or forget to actually write a function.

The absolute demand for precision makes the two acts feel very different. Rigor is enforced in programming. Rigor is the responsibility of the writer when it comes to presenting an argument. And I don't even know if it would be desirable for a writer of words to exercise as much rigor as a writer of programs.

Not that I'm necessarily disagreeing with the author. Just thinking out loud.

skermes• 15 years ago

A lot of people bring up the idea of rigor when I compare prose and code, and I think it's really overemphasized. Just think of English as a language with a really flexible type system that lets you duck type the hell out of everything. In Python, I can write a method that expects a file object, and (at least the last time I used urlopen, which was a while ago) you can pass it something you open from across a network, and a lot of it will still work. Accidentally using a network resource instead of a local resource isn't particularly rigorous, but Python makes it work. English is that, but more so.

The key line for me is "... it's hard to use metaphors in writing. It's simply more abstract." I have this working theory that abstraction in programming language is more or less equivalent to metaphor in person language. The core idea behind metaphors is to create a convenient lie that helps expose some aspect of what you're talking about by comparing it to some other domain. Consider my last paragraph. English has no type system. Telling you that it's duck typed is a lie, in the sense that it isn't true. But as a metaphor, it's convenient because lets me unify two ideas (programming languages and regular languages) under one aspect (things that have degrees of rigor). Similarly, having an abstraction over local files and network files lets me take two things that are accessed very differently, and let me pretend they're the same. It's a lie, but it works.

I'm not really sure how the abstraction==metaphor relation holds under closer scrutiny. I'm also not certain that it's particularly useful in terms of helping me make better programs, but I like it.

rauljara2• 15 years ago

I don't think English as a duck typed system works either. You can make a logical leap in an argument and nothing crashes. Many people have made very successful careers based on logical leaps, in fact.

But you can't make leaps with computers. If you forget to tell the computer which file to load, it either crashes, or nothing happens.

yew• 15 years ago

On the other hand, it's definitely possible for a language's interpreting infrastructure to deal with ambiguity in code. The difference between "natural language vs type inference" and "type inference vs assume it's an int" strikes me as quantitative rather than qualitative. You'd need a monstrously complicated system of logic to make it work, though. I'm not sure whether that thought's interesting or frightening...

sedachv• 15 years ago

There's been a lot of "programming is a creative pursuit" analogies (I'm guilty of blogging about it as well: http://carcaddar.blogspot.com/2011/04/programming-is-creativ...).

The motivational factors and work styles are similar, but I think the arguments for it being like painting or like writing are unconvincing. I've come to the conclusion that what programming is really most like is analytic philosophy.

The key insight that lead to this is thinking about ontologies - basically, naming things, but it also goes deeper to deciding how to map the problem onto data structures/design the class hierarchy. This is the same basic idea Evans had for Domain-Driven Design, although I don't know if he made the connection to the philosophy concept of ontology back then (I don't know if he is interested in philosophy, but I do know someone that worked with him who knew about this stuff).

In short, if you can't think or name what it is you're trying to write about, your writing will not come out clear.

yolesaber• 15 years ago

"Whereof one cannot speak, thereof one must be silent." ~ Ludwig Wittgenstein

It has been a while since I read it, but I had always imagined the "Tractatus Logico-Philosophicus" as a large function in which you input syntactically-correct sentences and it returns the truth-value, which can then be used to determine the clarity of the "picture" (http://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus#...). Truly fascinating. I should re-read it sometime. I feel like it has some parallels with the work I am doing in my "Design of Programming Languages" course.

If you have a background in analytic philosophy, you may find this of interest: http://www.hxa.name/notes/note-hxa7241-20110219T1113Z.html [Wittgenstein for Programmers]

edit: well I'll be, hxa7241 himself just posted the link. Great minds think alike perhaps? ;)

hxa72413• 15 years ago

As for philosophy, the pedigree is certainly there. Philosophy gave rise to, and helped develop, logic, and logic, in the early 20th century did rather give rise to programming. You could easily make an unbroken line of thought. So there certainly is something significant in common. But software is essentially about practical application.

Programmers seem to have difficulty in simply saying that programming is most like engineering design. It is probably because most people are unfamiliar with what engineering design is -- they perhaps think it only about material, or about absolute control. Engineering is at root logical and creative -- in a particular kind of combination, and for practical purpose. That is just like software.

hxa72413• 15 years ago

No, it is not really. To adapt a related note http://www.hxa.name/notes/note-hxa7241-20101218T2158Z.html from a while ago:

What makes writing writing is what it is used for. Writing is used for communicating between humans. It only works the way it does because of what is on the other end of it -- another person.

And that is why software must be different. Software is different from writing because its (ultimate, essential) purpose is different (and particular): it is not communication, it is (engineering) design. It works the way it does because it is for constructing an artifact.

When you look at software, what you see is not language, it is a machine.

To represent a machine requires a particular kind of structure. A machine has a particular form, and a description or notation that captures it must reflect that form. That form seems to be a recursive, hierarchical regularity -- a nestable scaffolding. And a machine has a core of objective logical rigidity.

Writing lacks this hierarchical logical structure. It communicates illogically, by allusion, impression, etc. Its use meant it never evolved any other way.

Instead, software must have this logical structure. The term 'programming language' is perhaps a source of the confusion, now unfortunately established. Software does not communicate to a machine, it embodies the machine.

nessus42• 15 years ago

Ableson and Sussman might beg to differ. From SICP:

  First, we want to establish the idea that a computer language is not just a way of getting a
  computer to perform operations but rather that it is a novel formal medium for expressing
  ideas about methodology. Thus, programs must be written for people to read, and only
  incidentally for machines to execute.

hxa72413• 15 years ago

They want to emphasise a point. But think of what is indispensible. If the program was unreadable -- maybe the source is lost -- you still have a running, useful, device. But if you do not have execution, you do not really have software anymore.

Software as function -- for execution -- and software as representation -- for humans -- must be pretty much equally important, in the end. But surely the key constraint, the definitive matter is what software does, what it is as an artifact. We can communicate about anything, but software is software because it performs some action.

St-Clock2• 15 years ago

It's funny this came from SICP's authors because I always found that Lisp was harder to read/write than languages like Python which look like English.

I'm not saying one is better or that one is easier to maintain than the other, just that Python is really close to the pseudo-code, design notes, and specifications in English that I write. Not just logically, but syntactically.

In Java, I used to write some pseudo code in comments before attacking a particularly difficult method. I rarely do this in Python now.

Still Lisp can be closer to English than some Perl one liners :-)

AlexandrB• 15 years ago

After reading this and thinking about the blog post a bit more, there is another difference. Only essays that are very technical in nature are purely explanatory. Usually an essay must persuade the reader as well. When was the last time you had to persuade a computer?

onemoreact• 15 years ago

The essay seems to miss the point.

While programs have little in common with the written word the act of programming is similar to the act of writing in that someone will read your code. It's not that hard to write something that people can decode, but it usually takes a fair amount of revision to remove the craft and add clarity. That’s not to say everything must be a masterpiece, but just as a great speech can inspire a nation some code just plain runs things.

PS: The most interesting program I ever read fit into 4kilobytes of ram. At the low level it employed plenty of twisted logic to fit into a limited environment, but the overall structure was plenty elegant to call it poetic. Just think cooperative multithreading, networking, and the ability to deal with quite a bit of memory errors in 16kbyte of source code and yet you could still understand what's going on.

gruseom• 15 years ago

Source code is written for people as well as machines.

reemrevnivek• 15 years ago

> I and other programmers sometimes alienate people when we speak because we either have to clarify intuitively obvious ambiguity or explain things by decomposing them into such detail that the explanation becomes incomprehensible to others.

Good to know that others struggle with this. However, I wouldn't go so far as to blame it on my programming/engineering background. I should be able to explain concepts without taking unnecessary time to clarify intuitively obvious ambiguity and I should be able to perceive my audiences' level of understanding and avoid oversimplifying things. Programming skills without ability to communicate are severely limiting.

GiraffeNecktie• 15 years ago

Programming is not "just like writing" it IS writing (i.e. communication via the written word) but it belongs to a similar genre as technical writing, in that it involves structured instructions for how to make things happen. Rather than telling a person what to do, you're telling a computer what to do. Those instructions are simply written using a language and syntax that the computer understands (along with explanatory comments for the humans). Yes it's "writing" - communication of ideas through the written word - but it's not like writing an essay, poem, short story or screen play.

username3• 15 years ago

Where's the compiler and git?

nandemo• 15 years ago

> The other day, someone asked Kyle if the hat he was wearing was new. He replied by asking what the person meant by "new".

Tip: don't do this. Just by refraining to ask such obnoxious questions, you'll become a better conversationalist.

(of course there are situations when such questions can spark interesting discussion, but most of the time it just annoys the other person)

> From an intuitive perspective — the perspective of the person asking the question — Kyle should have answered simply "yes" or "no".

Eliezer• 15 years ago

This strikes me as written by someone who knows a lot more about programming than about writing. The title would be a lot less objectionable, by the way, if it said, "What programming has in common with writing."

They're really not much alike. At all.

A program is a modular structure, usually hierarchically organized, that sets up highly structured, deterministic processes in a CPU, which in the course of execution develops a run-time flow that is nothing like the original program, and entirely under the programmer's control in principle, creating a tiny but complete causal universe from scratch.

Writing is a linear sequence that provokes reactions in a human brain with an entirely different and far more sophisticated instruction set, creating a realtime flow that closely matches the linearity of the original writing while being far more sophisticated and a whole lot less controllable than you thought it was. Most of the complexity is in the brain, rather than the writing - the writing just pulls levers on a far more complex machine.

Bicycle riding is a linear sequence of realtime reactive motor outputs that both powers and steers a mechanical aid to travel.

On the level where writing and programming are similar to each other, they're about equally similar to bicycle riding.

akkartik• 15 years ago

It serves a rhetorical purpose similar to other factually-incorrect statements like, "Programs are meant first for people to read, and only secondarily for computers to execute."

Peaker3• 15 years ago

I don't think that is necessarily factually incorrect.

asbadarto• 15 years ago

How about:

code - comments == specification of algorithm for computer; code + comments == explanation of algorithm for humans

Peaker3• 15 years ago

Comments aren't the only for-humans documentation in the program.

The names you give (pretty much everything), the structure, indentation (when optional), and various other things are all meant for humans.

Programming is just like writing

Related Stories