Do It On Paper First

See also PersonalAnalogDevice

I think the gist of this page is valid. It can be summerised as per Eric Steven Raymond's book The Art of Unix Programming (ISBN 0131429019 ):

One subtle but powerful way to promote compactness in a design is to organize it around a strong core algorithm addressing a clear formal definition of the problem, avoiding heuristics and fudging. Many of its most effective tools are thin wrappers around a direct translation of some single powerful algorithm.

The key: simulate the execution of a program on paper as an insighful wikizen writes below

This is certainly a principle that has never existed or if it did it was long forgotten: [only] if you can do it on paper you can do it on the computer.

The "only" part is false. Most people who use computers to do things have no idea how to do them on paper. Almost all programmers who implement software also could not do the same thing on paper, because they are computer specialists, not generalists; large parts of the process they would not know how to do on paper.
Furthermore, the extremely wide use of machine learning and search space algorithms means that computers these days quite frequently do things that no human knows how to do.
As I previously said below, "real time" software inherently cannot be done on paper.
So although you have a small point (most accurately phrased "if some human can consistently perform an activity on paper, then most of the time some programmer, but not all programmers, will be able to figure out how to do the same thing in software"), there is no further generalization of that point that is generally true. -- DougMerritt

A lot of people think a computer is a miracle tool and computers can perform miracles. Untrue! Computers can only do what the human mind can do (usually mechanical tasks) but it does it a lot faster.

Most of the software is simply an adaptation on the computer of an existing mechanical or paper system:

Software accounting programs are emulations of double accounting entries, Accounts Receivable, Accounts payable, Inventory lists lists.
Spreadsheets are emulations of ... the original paper spreadsheets, which were computed by hand.
Word processors are emulations of work produced by a typewriter (to witness the language used: font, margins, tabs, etc.)
PIMs are emulations of appointment books and to do lists
Wikis are basically emulations of index cards. They are electronic index cards. Albeit index cards that can be viewed and edited by anyone in the world. This is what makes Internet collective tools so revolutionary!
Databases are emulations of paper tables. You remember those tables we'd make with columns...
Your turn...

one must realize the computer does not create new work. Computers and software programs are there to improve existing work and work processes. It should not be a surprise that everything currently done by computer was previously done manually.

I think there may be a slight disconnect here. Is this page discussing whether computers automate tasks that were once done on paper, or is it discussing whether one should create a design on paper prior to writing the code? The discussion presented seems to differ from what I would expect from the title.

Are NeuralNetworks a counter example?

In this case you don't know the algorithm needed for a computer to perform a specific task. (All you know is the algorithm that will enable a computer to learn how to do the task.)

How does one tell whether the task is done correctly? Just because one does not know how to write an algorithm to describe something does not mean it is a brand new operation that has never been done.

It's an example of a computer doing a task that we need not know the algorithm for. The computer is performing the task in a manner that has no paper equivalence.

The closest thing to this principle is:

GarbageInGarbageOut. If your entries are not well done chances are your program will work poorly. No kidding!

The principle applied to compulinguistics

Perhaps the biggest reproach we can make to all the private investors, companies and governments who have invested millions of dollars in translation by computer since 1946 is the fact that they forgot this very simple principle: if it can be done on paper it can be done on the computer.

Does a system on paper exist? No. OK simple. Can't be done.

Or no wait. It can be done if you find a paper system.

But is it also true that it can be done iff you find a paper system?

Note that "iff" means "if and only if"

Definitely not; many things are done on computers that cannot be done on paper. The easy examples are things that require real time control; paper is too slow. Non-real-time applications would be solvable in principle on paper, but these days, typically not in a useful way. -- DougMerritt
It's important to realize that real time software is unlike every other kind of computer application, because by definition, if real time software gets an otherwise-correct answer too slowly, then it is incorrect. Since that is part of the definition, it follows that real time software cannot be done on paper. With other kinds of things, it's merely that no one in their right mind would try it, but it wouldn't be impossible by definition.

Of course, if you can do it on the computer, you can do it on paper as well, because you can always simulate the execution of a program on paper. But that would be pointless, this insight doesn't help to write the program in the first place.

Instructions are commands you give the Martian. Instead of giving them live, you use some code so that the Martian can execute these instructions. The code is called a programming language.

But you could ask a human being to do it. They are humanly instructions given to a Martian with no brain. So obviously the human brain can do it, they come from a human brain. They are all within the realms of a human brain!

So no matter what, whichever way you put it, if your instructions work for the Martian they work for the human being.

I spent 4 months looking for an algorithm for my program (on paper). I could not do a task and reduce it to simple instructions. I went through 200 roughs. Finally I was able to do it. The programmer was in town and he programmed it in two days.

After that statement, a whole lot of air has been let out of this topic. Crafting an algorithm and implementing an algorithm are two sides of a coin that cannot be separated. The first is a perfect Platonic world, and the latter is where all the mistakes are made... hence where all the learning takes place. One of the fantastic aspects of programming is that it so greatly accelerates human learning.

There are a whole host of applications that aren't possible on paper that are on a computer, simply because those things have no real meaning if you apply them to a non-computer domain:

Device control
Audio editing
Teleconferencing
Video compression

Some of the individual tasks that make up each of these applications might be doable on paper, but they're meaningless in a paper scenario, unless you're talking about just simulating them.

This is more than just a nit or a semantic quibble: the original suggestion was that unless you have a paper method for doing these things, it's difficult or impossible to do them in software. Some programming activities don't lend themselves well the design pattern of "do it by hand, then automate".

Doesn't this page simply restate the ChurchTuringThesis? That is, all universal computers are equivalent, and so any algorithm computable by one is (in principle) computable by all? (And does that mean that a NeuralNetwork is not a universal computer by the Church-Turing definition?)-- KatherineDerbyshire

Somewhat off the direction of this page, but I have found that I often can't get a computation quite right working with an editor. Then I finally get out the pad of paper and write the algorithm on paper (and it might just be a few lines), and suddenly it works! This has lead me to believe TheKeyboardIsTheWorstPlaceToDesign.

Could you provide any insight as to why you believe this to be the case?

Code is an expression of implementation. Algorithms are an expression of design. One has to have a design in place before anything below that can happen. The algorithm should have been there in the first place, actually. When one gets to a point where one realizes one doesn't know what the heck one is doing then it's time to go back to the paper.

Another aspect of this is that writing it down makes one think about the processing more clearly. Sometimes one may fool one's self into believing that one knows what is going on, but when ya write it down in the clear it's obvious ya ain't got a clue. Luckily nobody else was watching to see you embarrass yersef like that.

If you can do it on paper, you can do it on the computer.

I think it depends upon one's definition of "can." If "can" means that it is possible, given unlimited resources and time, then the statement is probably true. If "can" means that it is feasible within a reasonable budget and time period, the it really depends.

I have been involved for several years with a project to move a paper based process used by multiple offices to a computer based process. Each office was able to do its job on paper using paper (or word of mouth) guidance at each office. Getting a computer based set of rules has required a lot of compromise between offices (it was not feasible to produce a customized version for each individual office). Even now, there are certain unexpected needs that pop up and an office will revert to paper to handle that need. These occurrences have diminished over the years, but I don't think they will ever go away.

Paper provides a high degree of flexibility (i.e., no rules) that can only be mimicked by a computer program, and even then a great deal of effort is often required to handle "simple" options.