"My current theory is that programming is quite literally writing."

http://ask.slashdot.org/comments.pl?sid=2198700&cid=36293622

by damncabbage • 15 years ago

513 190 15 years ago

ask.slashdot.org

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.

dchest6• 15 years ago

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.

DasIch2• 15 years ago

I'm pretty sure that's what he meant.

larrik• 15 years ago

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• 15 years ago

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• 15 years ago

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

gaius• 15 years ago

More accurately, their grant-winning ability, which is a function of prestige etc sure, but it's not why they're hired.

3pt14159• 15 years ago

Generally true, although the Engineering department at my university (Waterloo) had a focus on making sure the teachers met a high "you must be this good at teaching bar" so the professors I had were routinely good.

jorgeortiz85• 15 years ago

Stanford's CS department hires lecturers (not professors) to teach many undergraduate classes, especially the introductory ones. Lecturers aren't expected to do research, and are hired based on their teaching ability. The ones I had were all incredible teachers.

w1ntermute• 15 years ago

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

If he missed it, chances are, pretty much any student would have as well.

darkxanthos• 15 years ago

I agree as well. I've noticed that in ALL problems, once I establish a solid consistent language around the feature I'm building, the programming part is easy. This is true even on complex problems. Its very rare to have a problem I can talk about in detail that is not easily solvable.

I've also noticed that peers struggling with implementing solutions usually have an inconsistent language.

icefox• 15 years ago

One thing I picked up (luckily) early on was that when you are learning something the fastest way to actually learn it was try to help other people learn the same thing. For programming this meant helping out on assignments in the labs, reviewing code etc. Very quickly you find yourself seeing a wide variety of bad practices and can recognize common mistakes and good practices. As a bonus you have to actually know the answers to the questions, but it is ok because if you don't know at the start you will soon enough.

tl;dr Pretending to be an expert until you actually are seems to be one of the fastest way to learn something.

saranagati• 15 years ago

this is very true. at my current company the last person who worked with the huge part of the code i write left about a month after i started. this left me constantly scrambling to figure out how to fix bugs that would come up in parts of the code i never even knew existed. I was managing ok but when we hired new developers, me having to teach them the little bit i knew caused me to understand the code way better than i had before.

I've decided my new method of training employees will have the most recently hired employee train the new hire.

gte910h3• 15 years ago

At Georgia Tech up until 2000 or so.

In the class it was often referred to as psudocode, but unlike psudocode in examples in random books/specs, it had a real syntax and you had to put everything you would in a real language or you'd get points off.

It was a great way to learn programming (and teach it too).

*(To disambiguate for the left cost people, GT isn't like ITT, it's of quality closer to Caltech, but much cheaper. Best salary for the tuition school in the nation apparently today)

mjs2• 15 years ago

As in, you didn't get to execute code on a computer at all?? That seems kinda odd--I think a large part of the pleasure of programming, for most people, is seeing your code actually do something. I think Logo was captivating because made this aspect especially prominent.

mattmiller• 15 years ago

I transferred to an under funded state school from a well funded community college. The CC has computer labs that CS classes were taught in. The state school taught CS with chalk boards. I learned much more with chalk boards.

mvalle• 15 years ago

When I first started university, I didn't realise how important pen and paper is. In my course, we use pen and paper more than we do computers.

ams6110• 15 years ago

First job out of school was Andersen Consulting. Went to their programming boot camp which was two or three weeks of 14-hour days learning their methodology and (sigh) COBOL. One of the final assignments was to write the code for a particular set of requirements. Then desk check it (i.e. on paper) until you were certain it was correct. Then you saved it and submitted the file. You got one chance, it had to compile cleanly and pass their suite of tests.

Most people passed; it was not a "gotcha" problem, you just had to be able to read carefully and pay attention to detail. Andersen hired a lot of liberal arts majors who had done a lot of writing, I was one of only a few in that group who had done a C.S. curriculum.

Jach• 15 years ago

Do you mean handwritten, or just a printed hardcopy? If it was handwritten, cue loading up my handwriting as a font and typing it anyway. ;)

A couple of my programming instructors use a build system that compiles your code with three different compilers, and runs it with various tests and diffs the output with a master copy (or sometimes stress-testing and tracking memory/time/probe counts). One of them also ran valgrind on submissions. So you'd get your "accuracy score" on the same day or so as the programs were due, then the teacher/TAs would grade the source and dock points for bugs not found in the test, supreme ugliness, etc.

johnnyjustice• 15 years ago

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_• 15 years ago

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

6ren2• 15 years ago

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.

dchest6• 15 years ago

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

6ren2• 15 years ago

> [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?

cturner• 15 years ago

Interesting. You could teach blocks of code in a similar manner to the way poetry is taught.

"Why did the author do this?"

"What effect do you get when reading this block?"

lurker142• 15 years ago

Beautiful Code: http://oreilly.com/catalog/9780596510046

silentbicycle• 15 years ago

I usually recommend the source to Lua, SQLite, and the BSD userland utilities (grep, awk, etc.). For C, at least.

VMG3• 15 years ago

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.

regularfry3• 15 years ago

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.

VMG3• 15 years ago

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()

wccrawford2• 15 years ago

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.

damncabbage• 15 years ago

  The writing is merely how to you transmit the logic.

The author of the post seems to me to be saying that, given that logic of a great number of programs can be pretty simple, the way you express the logic becomes more of a concern.

Take the following:

  @post.comments

Compare it to:

  $this->post->findDependentRowset('Comment');

Both mean the same thing, but the latter seems like the programming equivalent of purple prose by comparison.

MediaBehavior• 15 years ago

And is not (good) writing also about logic - even though sometimes it's fuzzy or the (twisted) logic of human psychology?

Writing requires "logicking out" the likely responses of the reader - and the pseudologic of parsing by the human brain (see Dan Ariely's "Predictably Irrational: The Hidden Forces that Shape Our Decisions").

ignifero2• 15 years ago

Are you not contradicting yourself here?

sp332• 15 years ago

Unless you're designing your own ICs and then programming them in machine code, there's some amount of logic and knowledge built-in already. I don't have to explain to the computer how to add two numbers together, or how to take a square root, or sort a list. It is necessary to understand the vocabulary that the computer already has. That's what OP meant by learning idioms: I can either painstakingly describe how to make a sandwich, or I can just say "make a PB&J" and you know what I mean.

mckoss• 15 years ago

I think the point that OP is trying to make is about skill acquisition. He argues you can't learn to program well merely by learning programming concepts. Rather, you must immerse yourself in reading and writing real programs.

wccrawford2• 15 years ago

I thought that was going to be the point, too, but I read it and I couldn't find anywhere that he stated anything like that.

And I agree with that. The best way to get better at something is to do it. Other things can help you along and accelerate your improvement, but they don't work on their own. You have to do it.

mcantor• 15 years ago

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.

jamesbritt2• 15 years ago

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.

vbtemp2• 15 years ago

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?

tjogin4• 15 years ago

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.

kenjackson6• 15 years ago

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.

dchest6• 15 years ago

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.

When you're writing a novel, you do.

ryanklee• 15 years ago

I would like to add this that when you are actually doing the non-lazy work of interpreting a novel, you do as well.

msg• 15 years ago

Never read Chronicle of a Death Foretold?

In programming, do you have to worry about phonology, slang, or number agreement?

The guy's deeper point is that programming is a language acquisition task and we would do well to take the rich set of lessons from ESL and foreign language learning and apply them to CS learning. Will all of it stick? No. But there is fertile green field to plow here.

saturn• 15 years ago

> programming is a great way to have the zest for life sucked straight out of you

If that's what you really think then maybe you should go become an ESL teacher in Japan, or at least try a new position that may fit you better. I find good programming roles to be highly enjoyable, challenging, and rewarding jobs. Sounds like you might need a change - shake things up a bit, re-examine assumptions and that sort of thing. It's very bad in the long run to hate your job.

schleyfox• 15 years ago

When I'm programming, I like to call race conditions "dramatic irony."

singular2• 15 years ago

> programming is a great way to have the zest for life sucked straight out of you

Sounds like you're in the wrong field. Just because you find the thing a drudge doesn't mean others feel the same way, and personally I find the cynical 'well real-world programming is ultimately crap' specious and poisonous - to you it is, to me it is not. Why are you still doing it? And why are you stating it like it's some immutable fact we are all avoiding somehow?

Personally, I find programming a wonderful, amazing thing even when working on the most incredibly dreary software, and of course considerably more so when working on the more interesting stuff.

This kind of stuff is unfortunately common and applicable any + all professions + activities out there. If everybody listened to the nay-sayers, nobody would have tried doing anything.

tl; dr: haters gonna hate.

vbtemp2• 15 years ago

Point taken. I wish I were you!

dpapathanasiou• 15 years ago

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• 15 years ago

That was at the beginning of SICP.

david9273• 15 years ago

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.

windsurfer4• 15 years ago

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.

david9273• 15 years ago

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.

hxa72413• 15 years ago

It is not the superficial appearance, it is the way it is used. Mathematics specifies a particular, limited, well-defined set of actions and relations. It is that character of those 'game rules' that make it mathematical, compared to general language.

edw519• 15 years ago

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

michael_dorfman3• 15 years ago

All of those are absolutely true, and many of them reduce to one thing

    - didn't have a frickin' clue what the code was supposed to do

I remember reading the old cartoon (and it was already old when I saw it 25 years ago) of the manager saying "You guys start writing code, I'll go find out what they want", and swearing I would never be that kind of manager only to find, all those years later, that many of my programmers had already internalized the notion and routinely sat down to write code without having a clear idea of what the block of code was supposed to accomplish.

jodrellblank• 15 years ago

You say that on a site where the ethos is "start building a company and product now, we'll figure out what it should do later" - because that's a way that works.

dustingetz2• 15 years ago

meh. i work at a small shop. most of the code i see that sucks was written by competent programmers under high schedule pressure. the code is clearly not well understood anymore, but if you trace the history you can see it's due to a few years of tacking on features as quickly as possible. the technical debt surely slows us down sometimes, but hey that was a business decision, maybe even a correct one! core business functionality is rock solid, its mostly UI code that sucks.

I wonder what the average startup codebase looks like?

david9273• 15 years ago

I get tired of the "blame the shitty programmers" line of thought. We're all shitty programmers. Yet we all "understand variable scope" and "what the code was supposed to do." Some of us have such a large ego that we think it's others. No, Sancho. It's you.

Code gets complex as hell very quickly. If it was building a house, it would be built in a week and architected on the fly. The person mixing the concrete, who has to know the concrete grade and drying time, also has to know that the upstairs has just shifted and now the load is too much on the center beam.

The reality is that, unless your dealing with tiny apps, that "bad programmer"? It's you.

dspeyer• 15 years ago

The worst code I've seen is from programmers who had no mental model of what they were doing, just changed things at random until tests passed.

The worst writing I've seen:

* is ungrammatical to the point of incoherency

* loses its train of thought mid-sentence and talks about something unrelated

* is full of irrelevant details

* simply ignores everything above the sentence level, producing mere text, no argument, story or whatever it was supposed to be

Not really the same failure modes.

michael_dorfman3• 15 years ago

Not really the same failure modes.

Really? Because except for the first one (which we have compilers to thank for), your three remaining points apply equally well to a lot of code I've seen.

SMrF• 15 years ago

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• 15 years ago

What you think code reviewing is for?

chriserin2• 15 years ago

Titling people editors, the ones that are senior in an organization and might be titled as architects or senior engineers, now, would be incredible. With their current titles they are involved much more at the beginning of the process than at the end, when 'editor' implies the opposite.

It would be nice to have the senior folk guide the developer as opposed to handing off a blueprint and getting out of the way. (Not that its like that everywhere, just some places I've been)

yxhuvud2• 15 years ago

No, it is a run on paragraph. The equivalent of a run on sentence is a method that is way too long.

Also, we practice code review at our work. That is definitely a way of fulfilling the role of being editors.

abecedarius• 15 years ago

I've taken the editor role in a couple of recent contract jobs. While the clients were both complimentary, I think I didn't do too well for one of them, where I came in to an existing codebase with a shortage of domain knowledge -- and this is going to be a general problem for a specialist editor, more so than with prose. I was more like a copyeditor. (For the other client I'd written the code they started with.)

mironathetin2• 15 years ago

This problem is hard to solve.

It is not in the interest of the programmer to allow others to understand his code. That would make him easily replaceable. I know quite a few consultants who write like that on purpose and secure their jobs this way.

Programmers are also not rewarded for clean code. They are rewarded for quickly delivered code. Beautiful code that is delivered two weeks too late is usually a bad idea. This is business logic.

It is easy to measure, how long it takes a programmer to develop code. It is much harder to measure, how much time is wasted to maintain badly written code.

Much speaks against writing clean code, little is in favour. The only persons interested in this are later maintainers and academics.

Lets face it: whats wrong with code that is a bit messy but does its job correct and quick? If the author himself has to edit it and does not understand it anymore, then he/she will refactor. If there is no need to touch this code because it does its job, who cares? If the original author is already gone and there was no time to make someone else familiar with his code and style, think about how people are treated in your company and refactor management instead of code.

pnathan• 15 years ago

The only tickybox that matters is the last one: if that is ticked, there's no hope for it but to put up Dilbert around your work space and sing sad songs while you work.

rimantas• 15 years ago

I think that the point of original post is precisely that many do know and understand all the things you listed, but for some reason fail to apply them on the job.

tytso2• 15 years ago

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.

dchest6• 15 years ago

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.

tytso2• 15 years ago

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.

mparr4• 15 years ago

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!!

misuse-permit• 15 years ago

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• 15 years ago

>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?

skidooer• 15 years ago

> how come not all great programmers are great writers?

I imagine most programmers are great writers from a structural point of view. The rest is emotion. Programmers know how to appeal to machines, but often are not able to connect with people in the same way; something that extends beyond writing, if stereotypes are any indication.

DasIch2• 15 years ago

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.

regularfry3• 15 years ago

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

RodgerTheGreat• 15 years ago

I've also heard 'Forthy'.

dchest6• 15 years ago

Other languages call such code... idiomatic :-)

ignifero2• 15 years ago

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

moioci• 15 years ago

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.

hxa72413• 15 years ago

> 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... (and maybe tack this on too: http://www.hxa.name/notes/note-hxa7241-20101218T2158Z.html ).

ansy• 15 years ago

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

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

kenjackson6• 15 years ago

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• 15 years ago

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

equark• 15 years ago

Emergency manuals for airplanes read like computer programs but are executed by humans.

mattdeboard• 15 years ago

processes == algorithms, right? Doesn't seem very mind-blowing to me.

redthrowaway• 15 years ago

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

That's how CS started. Long before we had anything recognizable as computers, we had the likes of Turing providing formal mathematical formulations of abstractions that would be realized later.

ctdonath• 15 years ago

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• 15 years ago

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.

enjalot• 15 years ago

I don't think this is what you are looking for, but when you said poetry it came to mind http://webcache.googleusercontent.com/search?q=cache:M1SJtT_...

(the original seems to be down)

RyanMcGreal3• 15 years ago

> 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• 15 years ago

Translation?

RyanMcGreal3• 15 years ago

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

Djehngo• 15 years ago

"Yes, Delivery, We can do that"

Or at-least I think that is what it means.

mjs2• 15 years ago

I guess this is also illustrates the difference between studying French at university, and studying it at Alliance française--or studying computer science at university, versus programming at a trade/vocational school.

hxa72413• 15 years ago

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.

stevenj• 15 years ago

I think good writing is conversational in nature.

I don't think writing code works that way.

chriserin2• 15 years ago

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.

Cyranix• 15 years ago

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

kylemathews• 15 years ago

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.

dennyferra• 15 years ago

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.

raghava• 15 years ago

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

Zeus-TheTrueGod• 15 years ago

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

Create• 15 years ago

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

this is an old idea.

pasbesoin• 15 years ago

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.

nikils• 15 years ago

Literate Programing http://en.wikipedia.org/wiki/Literate_programming ?

sunstone• 15 years ago

Everything old is new again. :)

pfedor• 15 years ago

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.

cschep• 15 years ago

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!).

gte910h3• 15 years ago

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.

saraid216• 15 years ago

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.

yuhong• 15 years ago

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

voxmatt• 15 years ago

Wait, SlashDot is still around?

delinquentme• 15 years ago

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

aznwhtey• 15 years ago

>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• 15 years ago

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

7952• 15 years ago

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.

ryanisinallofus• 15 years ago

Exactly! Writing. Copyrightable but not patentable. :)

mironathetin2• 15 years ago

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.

NY_USA_Hacker• 15 years ago

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!

"My current theory is that programming is quite literally writing."

Related Stories