

Programming is just like writing - saurabh
http://plpatterns.blogspot.com/2007/09/programming-is-writing.html

======
Eliezer
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
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."

~~~
Peaker
I don't think that is necessarily factually incorrect.

------
hxa7241
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
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.

~~~
St-Clock
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 :-)

~~~
Peaker
Python is close to the way you think, because the tools you use _shape_ the
way you think.

I write my pseudo-code in a Haskell these days.

Also, closeness to English does not help readability of programs. Programs are
pretty close to abstract maths, so closeness to maths actually helps
readability of a lot of the expressed concepts (e.g: Even Python uses
mathematical notation for its arithmetic).

~~~
St-Clock
"Programs are pretty close to abstract maths"

For you and many people, yes. For me and many other people, no. I sometimes
write math when I program, but more often, I manage. I assign roles and
responsibilities. I orchestrate communications. I try to keep conflicts to a
minimum. I often automate the way I think and I rarely think mathematically
(that's how I wrote my Master's thesis and this is how I'm writing my Ph.D.
thesis. I mean, the programs behind the theses).

"because the tools you use shape the way you think."

Yes... When you are starting to program or when you haven't been seriously
exposed to other programming languages and paradigms, you are right. But I
think I've been exposed to enough of these and made a conscious decision. For
example, to me, prolog was immediately natural during my bachelor degree, but
haskell felt more constrained.

Still, if I was primarily writing code in Lisp or haskell, I hope my
pseudocode would be different. Otherwise, it would be quite a waste of time
translating imperative programming to functional programming.

------
sedachv
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...](http://carcaddar.blogspot.com/2011/04/programming-is-creative-
pursuit.html)).

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
"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#...](http://en.wikipedia.org/wiki/Tractatus_Logico-
Philosophicus#The_Picture_Theory)). 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? ;)

------
rauljara
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
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.

~~~
rauljara
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.

------
nandemo
> 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".

------
reemrevnivek
> 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
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.

------
hsmyers
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...

------
asbadarto
How about:

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

~~~
Peaker
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.

------
username3
Where's the compiler and git?

