Programming is just like writing
plpatterns.blogspot.com
plpatterns.blogspot.com
They're really not much alike. At all.
A program is a modular structure, usually hierarchically organized, that sets up highly structured, deterministic processes in a CPU, which in the course of execution develops a run-time flow that is nothing like the original program, and entirely under the programmer's control in principle, creating a tiny but complete causal universe from scratch.
Writing is a linear sequence that provokes reactions in a human brain with an entirely different and far more sophisticated instruction set, creating a realtime flow that closely matches the linearity of the original writing while being far more sophisticated and a whole lot less controllable than you thought it was. Most of the complexity is in the brain, rather than the writing - the writing just pulls levers on a far more complex machine.
Bicycle riding is a linear sequence of realtime reactive motor outputs that both powers and steers a mechanical aid to travel.
On the level where writing and programming are similar to each other, they're about equally similar to bicycle riding.
What makes writing writing is what it is used for. Writing is used for communicating between humans. It only works the way it does because of what is on the other end of it -- another person.
And that is why software must be different. Software is different from writing because its (ultimate, essential) purpose is different (and particular): it is not communication, it is (engineering) design. It works the way it does because it is for constructing an artifact.
When you look at software, what you see is not language, it is a machine.
To represent a machine requires a particular kind of structure. A machine has a particular form, and a description or notation that captures it must reflect that form. That form seems to be a recursive, hierarchical regularity -- a nestable scaffolding. And a machine has a core of objective logical rigidity.
Writing lacks this hierarchical logical structure. It communicates illogically, by allusion, impression, etc. Its use meant it never evolved any other way.
Instead, software must have this logical structure. The term 'programming language' is perhaps a source of the confusion, now unfortunately established. Software does not communicate to a machine, it embodies the machine.
First, we want to establish the idea that a computer language is not just a way of getting a
computer to perform operations but rather that it is a novel formal medium for expressing
ideas about methodology. Thus, programs must be written for people to read, and only
incidentally for machines to execute.I'm not saying one is better or that one is easier to maintain than the other, just that Python is really close to the pseudo-code, design notes, and specifications in English that I write. Not just logically, but syntactically.
In Java, I used to write some pseudo code in comments before attacking a particularly difficult method. I rarely do this in Python now.
Still Lisp can be closer to English than some Perl one liners :-)
I write my pseudo-code in a Haskell these days.
Also, closeness to English does not help readability of programs. Programs are pretty close to abstract maths, so closeness to maths actually helps readability of a lot of the expressed concepts (e.g: Even Python uses mathematical notation for its arithmetic).
For you and many people, yes. For me and many other people, no. I sometimes write math when I program, but more often, I manage. I assign roles and responsibilities. I orchestrate communications. I try to keep conflicts to a minimum. I often automate the way I think and I rarely think mathematically (that's how I wrote my Master's thesis and this is how I'm writing my Ph.D. thesis. I mean, the programs behind the theses).
"because the tools you use shape the way you think."
Yes... When you are starting to program or when you haven't been seriously exposed to other programming languages and paradigms, you are right. But I think I've been exposed to enough of these and made a conscious decision. For example, to me, prolog was immediately natural during my bachelor degree, but haskell felt more constrained.
Still, if I was primarily writing code in Lisp or haskell, I hope my pseudocode would be different. Otherwise, it would be quite a waste of time translating imperative programming to functional programming.
Software as function -- for execution -- and software as representation -- for humans -- must be pretty much equally important, in the end. But surely the key constraint, the definitive matter is what software does, what it is as an artifact. We can communicate about anything, but software is software because it performs some action.
While programs have little in common with the written word the act of programming is similar to the act of writing in that someone will read your code. It's not that hard to write something that people can decode, but it usually takes a fair amount of revision to remove the craft and add clarity. That’s not to say everything must be a masterpiece, but just as a great speech can inspire a nation some code just plain runs things.
PS: The most interesting program I ever read fit into 4kilobytes of ram. At the low level it employed plenty of twisted logic to fit into a limited environment, but the overall structure was plenty elegant to call it poetic. Just think cooperative multithreading, networking, and the ability to deal with quite a bit of memory errors in 16kbyte of source code and yet you could still understand what's going on.
The motivational factors and work styles are similar, but I think the arguments for it being like painting or like writing are unconvincing. I've come to the conclusion that what programming is really most like is analytic philosophy.
The key insight that lead to this is thinking about ontologies - basically, naming things, but it also goes deeper to deciding how to map the problem onto data structures/design the class hierarchy. This is the same basic idea Evans had for Domain-Driven Design, although I don't know if he made the connection to the philosophy concept of ontology back then (I don't know if he is interested in philosophy, but I do know someone that worked with him who knew about this stuff).
In short, if you can't think or name what it is you're trying to write about, your writing will not come out clear.
It has been a while since I read it, but I had always imagined the "Tractatus Logico-Philosophicus" as a large function in which you input syntactically-correct sentences and it returns the truth-value, which can then be used to determine the clarity of the "picture" (http://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus#...). Truly fascinating. I should re-read it sometime. I feel like it has some parallels with the work I am doing in my "Design of Programming Languages" course.
If you have a background in analytic philosophy, you may find this of interest: http://www.hxa.name/notes/note-hxa7241-20110219T1113Z.html [Wittgenstein for Programmers]
edit: well I'll be, hxa7241 himself just posted the link. Great minds think alike perhaps? ;)
Programmers seem to have difficulty in simply saying that programming is most like engineering design. It is probably because most people are unfamiliar with what engineering design is -- they perhaps think it only about material, or about absolute control. Engineering is at root logical and creative -- in a particular kind of combination, and for practical purpose. That is just like software.
The absolute demand for precision makes the two acts feel very different. Rigor is enforced in programming. Rigor is the responsibility of the writer when it comes to presenting an argument. And I don't even know if it would be desirable for a writer of words to exercise as much rigor as a writer of programs.
Not that I'm necessarily disagreeing with the author. Just thinking out loud.
The key line for me is "... it's hard to use metaphors in writing. It's simply more abstract." I have this working theory that abstraction in programming language is more or less equivalent to metaphor in person language. The core idea behind metaphors is to create a convenient lie that helps expose some aspect of what you're talking about by comparing it to some other domain. Consider my last paragraph. English has no type system. Telling you that it's duck typed is a lie, in the sense that it isn't true. But as a metaphor, it's convenient because lets me unify two ideas (programming languages and regular languages) under one aspect (things that have degrees of rigor). Similarly, having an abstraction over local files and network files lets me take two things that are accessed very differently, and let me pretend they're the same. It's a lie, but it works.
I'm not really sure how the abstraction==metaphor relation holds under closer scrutiny. I'm also not certain that it's particularly useful in terms of helping me make better programs, but I like it.
But you can't make leaps with computers. If you forget to tell the computer which file to load, it either crashes, or nothing happens.
Tip: don't do this. Just by refraining to ask such obnoxious questions, you'll become a better conversationalist.
(of course there are situations when such questions can spark interesting discussion, but most of the time it just annoys the other person)
> From an intuitive perspective — the perspective of the person asking the question — Kyle should have answered simply "yes" or "no".
Good to know that others struggle with this. However, I wouldn't go so far as to blame it on my programming/engineering background. I should be able to explain concepts without taking unnecessary time to clarify intuitively obvious ambiguity and I should be able to perceive my audiences' level of understanding and avoid oversimplifying things. Programming skills without ability to communicate are severely limiting.
code - comments == specification of algorithm for computer; code + comments == explanation of algorithm for humans
The names you give (pretty much everything), the structure, indentation (when optional), and various other things are all meant for humans.