
"My current theory is that programming is quite literally writing." - damncabbage
http://ask.slashdot.org/comments.pl?sid=2198700&cid=36293622
======
edw519
_Most code sucks because we have the fluency equivalent of 3 year olds trying
to write a novel._

Let's get a little more specific...

Most code sucks because the programmer:

    
    
      - didn't name his variables what the really were
      - didn't understand variable state
      - didn't understand variable scope
      - didn't understand the basic concepts of iteration
      - didn't understand any of the algorithms he needed
      - wrote the same lines of code multiple times
      - didn't know enough about the language to find a better construct
      - didn't understand concurrency
      - didn't understand fundamental data base concepts
      - refused to follow well worn standards
      - didn't have any well worn standards to follow
      - built code on top of hopelessly designed data structures
      - didn't understand deeply enough what was going on under the hood
      - built to requirements that changed too dramatically to recover from
      - didn't even consider the concerns of the "next" programmer
    

But most of all:

    
    
      - was just good enough to get "something" (no matter how bad) deployed on time

~~~
SMrF
I think you can check off everything on this list and still write inscrutable
code. The worst code I've seen is code that was written so that only one
person understands what's happening -- the author. Typically the code has too
many branches and ridiculous call stacks. The writing analog is a run-on
sentence.

This usually happens when the programmer at fault is really smart but still
hasn't learned that at some point in the future, someone needs to come along
and understand the code he/she wrote.

Maybe we need editors?

~~~
murkt
What you think code reviewing is for?

~~~
gruseom
No, traditional code reviewing is just spot checking. That is analogous to
having an editor only look at a few passages of a novel. An editor needs to
work with the whole text. This is the trouble with formal code reviews. Pair
programming attempts to solve this by making all code get reviewed as it gets
written. Like it or hate it, that at least tries to solve the core problem.

~~~
mkjones
I suppose we're not "traditional" in this sense, but at Facebook we do
somewhat more in-depth code reviews than just spot checking. Generally if
you're modifying an existing system, you get one or two people who're familiar
with that system (and thus know the big picture of code design, layout, etc)
to review your diff.

If you're writing something totally new, you usually throw ideas and mocks
(either UI or code-structure) until you decide on a solution that works.

I've found this to be pretty good at helping newer engineers write good (and
idiomatic) code without hindering development speed much.

------
larrik
I think he's right.

In college, my CS 2 class was taught by a professor very different than the
rest of the teachers there. He wanted all of your programming assignments on
paper[1]. Then, you'd get it back with every possible bug marked in your
program, and he very rarely missed any[2].

That was the first time in college I thought "I really need to learn how to do
that!"

I went to a state school, so maybe all you guys with your degrees from fancy
schools wouldn't be that impressed, but the difference between this professor
and the rest there was gigantic. (He retired that year in a round of state-
wide budget cuts, so that's the last class I had him.)

[1] A lot of the other teachers wanted you to hand in binaries so they can see
it run. Sometimes with the code, sometimes not.

[2] I actually don't know of any case where he did, but I'm not saying
"never."

~~~
klbarry
From what I've heard, professors in prestigious schools aren't any better at
teaching. They're hired for their prestige and research ability.

~~~
timtadh
All true facts unfortunately. To get better teachers you have to attend a
"teaching" college/university. This name is detrimental, as most students
would probably be happier at such a place. The "research" university really
isn't for everyone but they get the most prestige and people think, oh I
should go there learn from the "brightest mind in the field".

~~~
alexgartrell
The value of Stanford, MIT, CMU, etc. isn't that the professors are so good at
teaching; it's that they are smart student aggregators. Nothing motivates you
like not being the smart one anymore.

~~~
BrandonM
That might be true of some people. For someone coming from a small town where
everyone told him that he would go on to do amazing, wonderful things, it can
be very depressing for him to learn that he is nothing special.

~~~
alexgartrell
That's more of a feature than a bug.

The opposite can be true too, I expected to get tanked at CMU and did pretty
well (3.65 gpa, senior thesis, going to Facebook). If I'd gone to Ohio State
like the majority of my peers from High School (Hilliard Darby High School has
sent a whopping two people to top tier engineering schools (CMU and MIT) and
none to Harvard) and even gotten a 4.0, I never would have believed I was more
than a "talented state school kid."

At the end of the day, it's on you to put yourself in the most challenging
situation you can possibly survive so that you can learn the most. Sheltering
one's fragile ego never did much for anyone in the long run.

------
pfedor
When you've learned two subjects with some depth, you start seeing some
analogies. Paul Graham thinks that hacking is very much like painting, and
this guy thinks that writing code is like writing English, and at one point in
my life I believed that coding in Perl has a lot in common with calculating
cross sections.

That doesn't really mean that these things are any more similar than two
random areas of human activity. Our brains are just good at finding analogies,
finding analogies is like spotting patterns, we see them even when there
aren't any and when there actually are some their appeal is difficult to
overcome. And if you know two subjects well you have more material to
cherrypick analogous things from.

------
RyanMcGreal
> Japan is somewhat famous for churning out students who know a lot _about_
> English, but can't order a drink at Mac Donald's.

An old friend of mine had a master's degree in French literature. She used to
live in Ottawa, Ontario and was fond of a pizza place just across the river in
Hull, Quebec. One day she called to order a pizza, and when it came time to
ask for it to be delivered she realized she didn't know how. She asked if the
pizza place could put the pizza into a car and drive to her house with it.

The order taker replied, "Oui, delivery. Nous pouvons le faire."

~~~
glhaynes
Translation?

~~~
RyanMcGreal
"Yes, delivery. We can do it."

 _Edit:_ \- I should point out that the French word for delivery is
_livraison_ ; but like most languages, day-to-day Quebecois French is porous
enough to borrow words from other languages where expedience warrants. Hence
_le week-end_ (not _le fin-de-semaine_ ), _frencher_ (to French kiss), etc.

As a further digression, I should point out that it seems less common (i.e.
less acceptable) to drop anglicisms into informal Quebec French than in
Europe, where native French speakers do not feel threatened by a dominant
continental Anglo culture. I was amused on a recent trip to France to learn
that the French word for wifi is "wifi" (pronounced _wee-fee_ ). Since wifi is
short for "wireless fidelity", a more canonical French term would be something
like _fidélité sans fil_.

~~~
ubernostrum
Of course, the French Academy tries to crack down on this; I remember cases
like trying to push out "email" in favor of the native "courrier électronique"
(literally: "electronic mail").

~~~
RyanMcGreal
AFAIK in Quebec the preferred term is "courriel", which is a portmanteau of
"courrier électronique" in the same manner that "email" is a portmanteau of
"electronic mail". (Funny that we're talking about Anglicisms in French, given
the vast number of English words of French origin - like "portmanteau".)

~~~
phugoid
I remember reading that the word courriel is in fact a Quebecois invention.

------
ctdonath
He is exactly right.

As a beginning-programming instructor, my students have little difficulty
understanding language syntax and operation - much like the "language lawyers"
mentioned. Their recurring problem is not correct syntax, it's internalizing
the process of expressing a solution to a problem using that syntax. They have
few unto no examples of what a program - a real, functioning, well written
program - looks like.

Indeed, programming is writing: it's expressing the solution to a problem
using a formalized language. Understanding how the program works is one thing
(and yes, all too often this is a problem); a good program also expresses why.

A 3 year old writing a novel won't succeed because, despite the ability to
speak, he does not comprehend the process of concocting and presenting the
story; all he knows is the minimum needed to just read one. He's not going to
write good novels until he reads lots of good novels, and groks the literary
structure and process of having and expressing an idea. Ditto programming:
students may know the syntax, but they don't grasp the notion of "writing"
because they haven't seen any decent examples.

Rosettacode.org may be a good starting place.

Thanks for the article, I may finally have identified the gap in my teaching.
Now to find concise examples to fill it with, as the curriculum does not
allocate copious time for reading lots of coding examples. Anyone have links
to good examples for beginners regarding fundamental concepts? I don't mean
syntax (I teach that well enough), I mean elegant uses akin to poetry or short
stories. IOCCC (a moment of reverent silence for greatness ended) has
wonderful examples of cool things in minimal code, but commands obfuscation.
Anything akin to IOCCC for good readable nifty code?

~~~
simplify
How long have you been teaching programming, and how did you get into it? I'm
very interesting in teaching beginner programming for a while now, as I'm
completely unsatisfied with my "top 10 in CS" university's shallow approach.
If you could drop me an email (in my profile), that'd be great.

------
ansy
I actually subscribe to the theory put forth in Structure and Interpretation
of Computer Programs by Abelson and Sussman

[http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-9.html#...](http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-9.html#%_chap_1)

Essentially, "computer science" is a myopic name for what is really "process
studies." It just so happens that defining processes to run on computers is
forwarding the field more than any other. But in the distant future we will
all understand the field to be about abstractly defining processes i.e. a
series of repeatable steps to accomplish a task. Which would be independent of
the mechanism used to execute the process.

Therefore programming is the act of defining a process. And programming
languages are what we use to define them.

It is covered fairly intuitively in the first few minutes of the SICP video
lectures as well:

<http://video.google.com/videoplay?docid=5546836985338782440>

~~~
kenjackson
_Essentially, "computer science" is a myopic name for what is really "process
studies."_

Actually the name isn't myopic at all. Computers are basically entities that
follow instructions. There was a time when the definition for the word
computer was a person who did computation processes.

~~~
vdm
James Gleick's The Information has a good description of those people, and is
a great read otherwise as well.

[http://www.amazon.com/Information-History-Theory-
Flood/dp/03...](http://www.amazon.com/Information-History-Theory-
Flood/dp/0375423729)

------
VMG
I'm a little suspect if this analogy goes beyond "theoretical understanding
without practical experience is worthless". You could draw a similar analogy
between architects who know everything about architecture but don't know how
to design proper buildings because they have no experience. Or painter who
knows everything about technique but can't paint a horse and so on.

It is easy to find differences between good writing and good code: Uniformity
in code is good, while uniformity in prose is bad. In writing, a large
vocabulary is an advantage, it's difficult to see if that is the case in
language. In programming, proper abstractions are essential while I can't
really see the equivalent of that in writing.

As far as analogies go, I can't see how this one is much better than others.

~~~
regularfry
Uniformity in code is bad - it tells you that there's a common concern or
pattern which should be factored out. Uniformity in code _style_ is essential,
the same way it is for prose.

~~~
VMG
Is it? In prose you say "first he rushed to the exit door, then he leaped down
the stairs, finally he ran to get the train" while in programming it is better
to write

    
    
        socket.close(); window.close(); file.close()

~~~
vorg
Better prose is:

"He rushed to the exit, leaped down the stairs, and ran for the train."

Better programming is to factor out the action:

    
    
        [socket, window, file]*.close()

~~~
SlyShy
Just curious, is that taken from an actual language? Because I've wanted a
feature like that for ages.

~~~
scythe
It exists in Ruby:

    
    
        [socket, window, file].each{|item| item.close()}
    

<http://codepad.org/GqNp94Iw>

It sort-of exists in Lisp-inspired languages (anything from Arc to Lua to Io)
with appropriate boilerplate, for example:

    
    
        function apply(tbl, func)
           for key, val in ipairs(tbl) do func(val) end
        end
    
        apply({socket, window, file}, function (item) item.close() end)
    

<http://codepad.org/SNWO1Y6K>

~~~
gliese1337
It'll work in JavaScript, too:

    
    
       [socket,window,file].forEach(function(o){o['close']();});

~~~
michaelhoney
And all of these ways are longer and less clear than the original. Better to
write code like Hemingway than like Proust.

------
Watchmannen
Actually the article is missing one thing. Yes, you need to be able to express
yourself in the (programming) language.

But, and here is the thing, the hard part is not learning the words and the
grammar, nor actually writing in the language using the said words and
grammar.

No the hard problem is figuring out WHAT to say and HOW say it to make others
(humans or computers, depending if it is a natural or programming language).

In terms if human language it is about formulating a narrative story that
presents the problem and the solution to the reader.

In terms of programming language it is about describing the data structures,
data transformations and transactions/communications needed to perform the
task.

This is the hard part and that is what separates good writers and good
programmers from their lousy counterparts.

BTW: I hope this was parseable.

~~~
dchest
I don't think this is missing from the article, it's actually what the author
said. If you only learn the words and the grammar, without seeing how they are
used to express things (and without trying to express things), you won't learn
foreign language/programming.

------
vbtemp
Oh come on. Programming is not writing. When you're reading a novel you don't
have to worry about concurrent access to a resource, threads, asynchronous
events, or even much less conditional branching. With all due respect, I think
this is just an inane post. That said, I can't blame the guy for dropping
software development and moving to Japan to teach ESL. I often entertain
similar fantasies all the time - programming is a great way to have the zest
for life sucked straight out of you

Edit: Would someone have the courtesy to mention why they are downvoting?

~~~
tjogin
And in programming you don't have to worry about capturing the audience, the
development of the characters, the story arch, being clear but not being
obvious, etc.

Both in programming and writing, the actual _writing_ part is the easiest
part. And while bad programmers can make a program work, and bad writers can
tell a story, it takes good ones to do it coherently, efficiently and
enjoyably.

It's not the exact same thing, which I don't think anyone is saying, but there
are some similarities there, especially the aspect of writing _readable_ code.

~~~
kenjackson
They're not nearly the same thing. The scope of modern literature has hardly
moved in hundreds of years. Compare Updike, Roth, or Mitchell to Dante or
Shakespeare -- they'd seem like near contemporaries in programming.

In contrast, in the past, programs to do Newtons method or compute trig tables
were often the full scope of a program. You certainly never had a Halo 3,
Windows 7, Google Search, or WordLens application written even 50 years ago.

Good _literature_ isn't about automating increasingly sophisticated processes.
Programming is all about that. This leads to increasing complexity of
programs, where the goal of software engineering is to abstract/hide as much
of the complexity as possible.

The only things they really share in common is that they're both written in
text. If programs were written by soldering wires no one would make such odd
acquisitions (do EE relate circuit design to writing literature?).

I think we give this slashdot author far too much credit.

~~~
tjogin
They have one more thing in common; the text is _read by other people_. And
the better written, the more _effortless_ it is to understand.

I think this aspect of it is what the slashdot author is mostly talking about,
suggesting that if you write code as if you were writing to the _next
programmer_ , rather than to just the computer, your code will be better for
it.

Clearly, programming and writing isn't the same thing. Nobody is claiming that
and, _guaranteed_ , nobody here thinks that. It's a metaphor and like any
other metaphor it breaks if you bend it enough.

~~~
kenjackson
Unfortunately, this metaphor breaks at the onset. Programs aren't primarily
written to be read by people. They're primarily meant to enable functionality.
Readability of code is important, but not the ultimate ends -- it is part of
the means.

But the important part of my post was that programming is about automation.
It's not about weaving a story, even for the next programmer. It's about
building abstractions for automation. And yes, its important for other
programmers to build on top or service it, but given a choice between the
right user experience and dev experience, user experience should usually win
(although there will be some exceptions).

~~~
tjogin
The author argues that _good_ code _should_ be written for people. The
metaphor doesn't break just because you disagree with the author's point.

IMHO, any dolt can produce code that _only_ works. All too often I have to
sift through _horrible_ code that works, and I think the author is right in
that if the programmer who wrote that (sometimes that's me, sometimes it's
someone else) had had the next programmer in mind when he/she wrote it, it'd
be much less of a pain.

~~~
kenjackson
_The author argues that good code should be written for people._

If good code were written only for people there'd be no quicksort. No fast
implementations of FFT. Probably no fast versions of memcpy. The reason is
that coding is not primarily about writing for other people. Look at Donald
Knuth's code. Extremely well-written, yet certainly doesn't stand on its own.
And there are certainly design decisions that optimize for both asymptotic
complexity and small constant factors.

My point is that analogizing this to books does no one any favors at all.
We're having a conversation on the merits, w/o having to allude to neither
haikus nor novels, nor gerands, nor foreshadowing.

Programming is difficult, even for code that "only works" (you'd be a
billionaire if you could find a way to quickly produce code that "only
works"). It has little more in common with writing than tarot cards -- which
also are made to be read by humans.

~~~
tjogin
The author never claimed the code should be written _only_ for people, then it
wouldn't work, would it? You're either trolling or mistaking the rest of us
for complete morons.

~~~
kenjackson
_My current theory is that programming is quite literally writing._

That's what the author wrote.

Lets take another (stupid) quote from the author: _Most code sucks because we
have the fluency equivalent of 3 year olds trying to write a novel._

There's no absolute nature regarding the state of ability for any given task.
There is no way to map fluency in English to fluency in any other domain. It
just doesn't make sense.

This is just all around lazy thinking. It's buying into a metaphor because you
either don't have the ability or desire to actual think about the real issues.
edw earlier in this thread actually took a little time to think about the
issue. This slashdotter made no effort, had no substance, no data, just a
cheap metaphor that fell apart upon first glance.

 _or mistaking the rest of us for complete morons_

How's this for lazy thinking -- I use duck typing.

------
misuse-permit
This is a decent analogy, but still I cringe whenever I hear someone comparing
computer languages to spoken ones.

They are nothing alike, and I would be honestly surprised if we even used the
same part of our brain for processing the grammars of human languages as we do
for the rigid, formal computer ones.

If this were true, how come not all great programmers are great writers? Why
don't more great programmers become fluent in other spoken languages?

~~~
parfe
>If this were true, how come not all great programmers are great writers? Why
don't more great programmers become fluent in other spoken languages?

Why doesn't Mark Twain have any novels written in French? Why would you hold
computer programmers to a greater standard than any of the great authors?

------
david927
It's a nice theory but I disagree. Programming languages are really just a
poor effort towards a mathematical notation.

There are those adept in theory that can't practice well, but that's because
to practice the art means dealing with a plethora of hacks, exceptions and
miscellaneous trivia completely unrelated to the core problem at hand.

Personally, I don't think the answer is becoming 'fluent' in handling the
exceptions and idiosyncrasies of the chosen language, framework and platform.
Rather we need to work on building a notation that provides better abstraction
mechanisms.

~~~
windsurfer
How is mathematical notation different from a written language like English?
It conveys meaning using glyphs, uses nouns and verbs (and even adjectives).
It expresses all sorts of ideas. One might even say that math's notation is a
poor effort towards English.

~~~
david927
Language can be expressive in ambiguous ways, with multiple valid ways to
express the same emotion. Notation should be definable, unambiguous, and
precise. The fewer ways to express something, the better.

~~~
vorg
> The fewer ways to express something, the better.

Your last sentence could be rewritten "It is better to express things in as
few ways as possible", or "Having fewer ways to express something is better".
English, however, allows you to omit the main verb for the causation in a
parallel construction, you were able to write it shorter, and with a
3-syllable climax after a pause at the end for effect.

Shouldn't programming languages also provide many different ways to express
things?

~~~
william42
No, because that makes it harder to understand what it's doing. Remember that
programming languages are not learned at a very young age and continuously
trained for decades the way natural languages are.

~~~
chromatic
_No, because that makes it harder to understand what it's doing._

Without looking at an example of working code, how is it possible to say that
one particular phrasing is so obviously better than any other that it and it
alone should be allowed to exist?

I appreciate in Perl very much the postfix conditional expression syntax
because it exploits the end weight linguistic property and allows me to
emphasize the most important part of the statement when the situation
warrants. I believe that makes my code clearer _because_ it looks different
from the Algol-standard conditional syntax.

~~~
vorg
> Perl ... allows me to emphasize the most important part of the statement
> when the situation warrants.

Yes. The ordering of elements in a sentence is its "thematic" structure, just
as important in communicating as the "transitive" structure of sentences, i.e
the relationship between nouns, verbs, etc. Most programming languages copy
the transitive structure of natural languages, but not many allow the
programmer to freely choose the thematic structure.

------
wccrawford
Programming isn't about writing. It's about logic. It's a series of
instructions for a computer to follow.

The old 'write down how to tie shoes' or 'write down how to make a peanut
butter and jelly sandwich' projects show just how hard it can be to pin down
exactly what needs to be done to do seemingly simple tasks.

The writing is merely how to you transmit the logic.

~~~
mcantor
I disagree _so_ hard. Computer programs should be written primarily for humans
to read, and only incidentally to be executed by computers. The connection
between writing and programming is vital: they are both the practice of
_expressing structured ideas_. It has nothing to do with the computer. It has
nothing to do with the English language, or Vim, or Word. It's about starting
with an idea and hacking away at it, removing ambiguities and possibilities,
until only something unique remains.

~~~
jamesbritt
_I disagree so hard. Computer programs should be written primarily for humans
to read, and only incidentally to be executed by computers._

The funny this is that the same is also true for mathematics.

Mathematicians writing proofs and theorems are communicating with other
people, not (usually) with machines.

Mathematical notation is s means of human-to-human communication. Yet anything
but the most trivial math soon becomes inscrutable to the untrained. As far as
I can tell, mathematicians are mostly happy with this. The language used
allows for precise, compact expression of complex (i.e structured) ideas. That
understanding requires training and rigor is not considered inherently bad.

For whatever reasons the same terseness and concision is derided by many
programmers who seem to believe that ease of understanding by the moderately
skilled is highly important.

------
tytso
His theory might be true if you were only talking about writing a program from
scratch. But programming is a lot more than that, because except for the
smallest, most trivial exercises, programming is a team sport. Which means you
need to be able to understand somebody else's code, and you also need to be
able to modify it in a way that makes sense.

You can have a program which is beautifully structured, and factored in an
extremely clean way. But what happens when you have to modify it in response
to a change in requirements? And what if you have external code that depends
on the existing interfaces? At that point, the skills needed to be a good
programmer are quite different from that of a writer.

~~~
dchest
Ask a novelist about the pains they have when the extremely clean, excellent
plot fails due to some small point, and they have to adjust it.

~~~
tytso
I can think of a number of novels where it's obvious some scenes got moved
around for plot reasons, and their were continuity errors or other ways in
which the seams showed.

But novelists only have to deal with that for maybe a year or so; programmers
have to deal with this problem for potentially decades, and at that point it's
a completely different problem just because the scale is different.

~~~
cubicle67
I'm working my way through Stephen Donaldson's latest Thomas Convenant novel
(book 9), a series he started writing in the 70's (first book published in
'77). He expects to have the final book (book 10) completed by Fall 2013

------
gte910h
I disagree.

Programming definitely requires writing skills (expressiveness and concision
most importantly)

However it's about structurally combining that writing into maintainable code,
using idioms of the past to build upon to gain error free use. It's about
mentally modeling what parts of the machine are doing, and correctly
understanding those interactions. It's about risk assessment, experimentation,
knowing when to call something quits. It's about going back over old world to
do it a better way. It's about decomposing a complex process into many simpler
steps. It's about reading, reading lots in fact, usually reading to find out
details of the bits of your mental models.

Programming really isn't anything other than programming. It's not any field
like it or near to it that knowing a nearby field plays well into it
(electrical engineers can make horrible programmers but brilliant electronics
guys same goes for web designers), but lots of other skills parlay well into
getting you partway into the panoply of skills that get you past the finish
line.

People make bad programs code when they only have part of those skills (or
when they do not put out the effort to use the skills they have, due to time
or willpower restraints).

Another reason some programs suck: they picked the wrong problem to code.

------
Cyranix
"Besides a mathematical inclination, an exceptionally good mastery of one's
native tongue is the most vital asset of a competent programmer." -- Edsger
Dijkstra

As a programmer coming from a linguistics background, this sentiment has
always resonated with me. As much as math is a part of my job, recognizing the
transferrable skills from human language use has probably been the primary
reason that I've been able to land programming jobs and write fairly
successful code.

------
dpapathanasiou
That reminded of this quote (I forget who said it):

" _Programs are written for humans to read, not for machines to execute_ "

~~~
tree_of_item
That was at the beginning of SICP.

------
mparr4
To have good taste is one thing (the ability to recognize good from bad) but
to be able to produce good work is another. As many good writers (and the
author of this post) suggest, the best way to get better at writing is to read
good writing and to write more. This method (of observing masters at work and
practicing the craft yourself) works for many disciplines. Should it be
surprising that it applies to hacking as well?

The post reminded me of an Ira Glass interview where he comments on having
good "taste" (5 min) <http://www.youtube.com/watch?v=BI23U7U2aUY> which in
turn reminds me of PGs essay "Great Hackers"
<http://www.paulgraham.com/gh.html> Good stuff!!

------
6ren
So what's good example code?

Sadly (and tellingly) it's not necessarily the most successful code (success
comes from meeting user needs, not from good code), but how else can you judge
it, apart from reading it. This is made worse because it's hard to tell if
code is _necessarily_ complex without understanding the problem it solves,
which may be complex. Further, if you don't yet know what good code is, how
can you recognize it? Of course, if you are intelligent and reflective and try
ideas out, you can learn from both code and bad - it's all raw material, grist
for the mill.

IMHO the hard part of programming is understanding the problem to be solved.
The solving is easy.

~~~
dchest
_Sadly (and tellingly) it's not necessarily the most successful code (success
comes from meeting user needs, not from good code), but how else can you judge
it, apart from reading it._

Schools have suggested reading lists. Do they have the same for _code
reading_?

Fortunately, on the Internet, we have experienced people to help us:
[http://www.hnsearch.com/search#request/all&q=%22good+cod...](http://www.hnsearch.com/search#request/all&q=%22good+code+to+read%22&start=0)

~~~
6ren
> [suggested _code reading_ lists]

That's a good idea, but I haven't heard of one. I think the best thing is just
to read a lot of code, good and bad.

BTW did you check the result of that search?

~~~
dchest
_BTW did you check the result of that search?_

Haha, just skimmed through it, sorry. I remember threads on this topic, but it
seems like HN search for this request failed to find them.

------
raghava
Isn't this the same thing Bruce Eckel wrote a couple of years ago?
<http://www.artima.com/weblogs/viewpost.jsp?thread=255898>

------
hxa7241
Saying programming is writing is like saying building something is 'speaking
to materials'.

When you look at software, what you see is not a language, it is a _machine_.
A machine that is presented in humanly understandable and communicable form,
but nonetheless, something with a particular kind of underlying determinate
structure.

Yes, the main part of the conclusion is the same: you have to learn by doing.
But because software is _design_ \-- rational manipulation of objective
'material' -- knowledge _about_ how it works is also an intrinsic part of
doing it well.

Design means creating something through clear knowledge: we go with particular
design ideas because we can predict their outcome and effect. This is the
knowledge _about_ that the article underestimates. We choose quicksort not
simply because we have immersed ourselves in social norms, but significantly
because it has been proven asymptotically fastest.

That kind of determinate knowledge that programming by nature can have is
important. It is missing something to lump it in as just being like spoken
language learning.

------
johnnyjustice
He is right. Good writing is sussicint, concise, and says a lot with a little.
Good programming is clear and does a lot with a little.

~~~
corin_
In some cases good writing says a lot with a little, but by no means is that
always a requirement for good writing.

------
saraid216
I agree with him. As kylematthews points out, it's not about the substance of
the thing--capturing an audience, I/O calls, or anything like that. It's about
communication.

Communication is about translating something conceptual inside your own head
to become understandable by something (usually a person) outside of it. The
way we do this is by language. A programming language is merely the way we
communicate with a computer. To do it right, you need to understand the parts
of the computer that you want to change.

It's not a mistake that we used to call impressive coding "wizardry" or "deep
magic". It was about casting spells... except that if you actually step to the
side and look at what "spell" means, it's simply a story.

A good program tells a good story. You might not appreciate the characters or
the plot, but the computer sure does.

------
mironathetin
I don't think that I can agree with the op on slashdot.

Programming is not about knowing lots of words or grammar. It is about getting
the thoughts clearly structured and understanding quickly what a problem is
really about.

THIS is quite the same problem as writing text. But, IMHO, the author
approached this as someone who does not know how to write text, too. Its not
about ingenuous choice of words and correct application of grammar. It is
about clarity of understanding the problem and then find a solution how to get
to the point clearly and quickly.

If a solution is in the mind, 70% of the way is gone. Then it is important not
to give up unless this idea is on paper in the same shape as it was in the
head before. So I think the analogy is a good one, but the op has not
necessarily found the reasons why.

------
kylemathews
I spent two years living in a foreign country learning a new language (my
first foreign language) immediately before I started learning to program and
it's always struck me how similar the two experiences are.

All good communication comes first from good thinking. Whether or not we can
communicate in a certain medium (speaking a language, writing, painting,
music, programming) depends entirely on how fluently we can translate our
thoughts into that medium.

So good thinking + good understanding of programming concepts = good code.

------
pasbesoin
This makes me think of people who would try to "memorize" for e.g. science
tests. They were ok as long as they could plug and chug, but they couldn't
derive anything on the spot.

I'm wary of tickling my ego, but I recall not entirely seldom forgetting a
formula, and so simply starting with other stuff and deriving it in the margin
or on scratch paper. I think many of the instructors liked that, as well, as
it showed a more conceptual grasp.

------
moioci
This discussion brings to mind Robert Lefkowitz's Pycon keynote from 2007 on
Programming Literacy, very similar to this video from Stanford:
<http://www.youtube.com/watch?v=Own-89vxYF8>. He is definitely an advocate of
literate programming and basically says we will all be able to read programs
when they can be written in English and not in code.

~~~
hxa7241
> we will all be able to read programs when they can be written in English and
> not in code.

Anyone thinking along those lines needs to read Dijkstra:
[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html)
(and maybe tack this on too: <http://www.hxa.name/notes/note-
hxa7241-20101218T2158Z.html> ).

------
nikils
Literate Programing <http://en.wikipedia.org/wiki/Literate_programming> ?

~~~
sunstone
Everything old is new again. :)

------
cschep
I like the author's premise. It's hard to find good writing that hasn't been
rewritten.. a lot. That seems true to me about code as well. Perhaps we're
seeing a lot of "rough draft" code being pushed to production. Novels never
get published like that (hopefully!).

------
DasIch
I find it fascinating that Python seems to be the only language which created
a word to describe idiomatic code: pythonic.

Having learned Python as a first programming language I always try to gain an
idiomatic understanding of the language which allows myself to think in
Python.

~~~
regularfry
Rubyish, perlesque, lispy are all words I've come across.

~~~
RodgerTheGreat
I've also heard 'Forthy'.

------
dennyferra
The only problem I see with this is when Bob, David, Mike and Steve have their
own ideas about writing a story and take your love story then turn it into a
science fiction novel about aliens, cowboys, race cars and heavy metal.

------
7952
No, its a kind of data. It has more in common with a spreadsheet than a novel.
And like a spreadsheet you can get yourself into lots of trouble if you don't
format the data in a way that suits the tool you are using.

------
aznwhtey
>We should be immersing students in good code. We should be burying them in
idiom after idiom after idiom, allowing them to acquire the ability to program
without explanation.

Does anyone have suggestions of some good code to read?

~~~
dunstad
You'll probably have the best luck dissecting a program you're interested in.

------
yuhong
That is particularly important in connection to management techniques.
Programmers are not dumb automata.

------
ryanisinallofus
Exactly! Writing. Copyrightable but not patentable. :)

------
delinquentme
"We should be immersing students in good code. We should be burying them in
idiom after idiom after idiom, allowing them to acquire the ability to program
without explanation."

^ bingo.

------
Create
... and "code should read like prose".

this is an old idea.

------
stevenj
I think good writing is conversational in nature.

I don't think writing code works that way.

~~~
chriserin
Way to take this conversational thread out of the analogy! Its an analogy that
is instructional but clearly not applicable for all writing. I hope to never
see code that looks like a Faulkner novel, for example.

------
Zeus-TheTrueGod
I've read the article. I am sure that when a new child is born he has, say, a
5% chance to have an ability to be a programmer. After the lucky one grown up
he will get all required information and experience just because he has the
ability and finally, say in 10 years, will be a good programmer. Other 95% may
do everything they want, they can learn how to program, read a lot of books,
do all their homework and hobby project, but they will grow up only to the
certain level.

I want to believe in what I've just wrote cause that guarantee that I will not
have a lot of competitors and I'll always have a job when I want

------
ignifero
Programming is a compressed form of serial semantic thinking. It requires the
same brain structures as math and language, so it's similar to writing, except
it's more specialized and more restrictive. It's also very effective

------
NY_USA_Hacker
Of COURSE. Why would anyone think anything else?

For more, let's start with source code. Suppose we have source code line

    
    
         a = b*c
    

Reading this line, we want to know what it does and check that it's correct.
So, we need to know what the line 'means'.

But, we conclude that

    
    
         a = b*c
    

doesn't really mean anything.

Of course if we saw

    
    
         F = m*a
    

we might guess that the variable names were mnemonic and guess Newton's second
law that force equals mass times acceleration. Okay, now we know what the line
means and can check if it's correct.

Okay, we are beginning to see:

A line of code such as

    
    
         a = b*c
    

doesn't mean anything. So, we have nothing to read and no way to check. So, we
don't have anything.

We could write

    
    
         F = m*a
    

and begin to guess what this means. But we are still in trouble: We still have
no good way to communicate meaning to permit understanding or checking.

So, we have to ask,

    
    
         F = m*a
    

came from physics books, and what did those books do? Well, they wrote in a
natural language, say, English. Always, an equation such as

    
    
         F = m*a
    

was just an abbreviation of what was said in English. And, in particular, from
the English there was no question about the meaning of each of the variables.

Net, math, and science with math, are written in complete sentences in a
natural language. The variables are all clearly defined, discussed, explained,
etc. At no time is an algebraic expression of such variables regarded as a
substitute for the natural language. Take a physics book, throwout the English
and leave just the equations, and will have nothing.

Physics and math understand; so far computing does not.

So computing tries to write

    
    
         force = mass*acceleration
    

or some such and omit the English. For simple things, can get by this way.
Otherwise, this approach is hopeless, at best presents the reader a puzzle
problem of guessing.

The matter of using mnemonic variable names as parts of speech in English is a
grand mistake but common in writing in computer science. Bummer.

Bluntly computing has not figured out that there is so far just one way to
communicate meaning: Use complete sentences in a natural language. Period.
That's all we've got. But computing has fooled itself into believing that
algebraic expressions with mnemonic variable names form a 'new language' that,
in computer source code, can provide the needed meaning without a natural
language. Wrong.

For

    
    
         F = m*a
    

the situation is simple. But significant source code has much more complicated
cases of 'meaning' to communicate. Again, computing tries to get by, say,
using a big library of software classes, relying the mnemonic spelling of the
classes and members and the documentation of the classes. In simple cases, can
get by this way. But fundamentally, for some complicated code, the meaning,
workings, etc. just must be explained, and there's only one way to do this:
Complete sentences.

So, writing these complete sentences to communicate meaning effectively is
'writing'.

Done!

------
voxmatt
Wait, SlashDot is still around?

