Newsgroups: bofh.jobfh.misc Message-ID: <5fE*S1c9t@news.chiark.greenend.org.uk> References: <867gvw7phi.fsf@ant.boggle.org> <871um46os0.fsf@latakia.domain.actdsltmp> NNTP-Posting-Host: chiark.greenend.org.uk Xref: news.chiark.greenend.org.uk bofh.jobfh.misc:28362 From: Ian Jackson Subject: Re: lack of planning on your part.... Date: 07 Jun 2012 15:07:45 +0100 (BST) In article , [someone] wrote: >Except that what is "can program"? I think the key thing is that programming, done properly, is more like maths. It's almost entirely abstract. So the key aptitude required is abstract reasoning. And, for development in non-toy projects involving teams, version control, bug systems, etc., that reasoning needs to be communicable to others - so a programmer needs abstract verbal reasoning. A lot of people have been focussing in this thread on knowledge of various kinds. For example, knowledge of algorithmic complexity; knowledge of standard solution patterns; knowledge of programming languages; knowledge of standard programming language constructs; knowledge of the underlying machinery behind various abstractions in computers. Now all of those kinds of things are useful to a programmer; they can make a big difference to the time it takes to solve a problem, and the elegance and performance of the result. But ultimately a programmer who was missing that knowledge, but has good abstract reasoning skills, can learn, can muddle through using other approaches, and can reinvent standard techniques. They can still write correct code. For an outsider this vast array of arcane knowledge seems intimidating. But a programmer knows that they are ignorant about almost everything - but has the confidence to know that they can go and find out about it if they need to. And abstract verbal reasoning is a very difficult skill to teach. This is the fundamental reason why software used by programmers is so much better than software used by nonprogrammers in their day jobs. (Software written by programmers for use in their hobbies is often very good if a bit idiosyncratic.) Take anyone numerate and try to teach them accountancy? That may sound hard because most of the subject of accountancy is taken up with a morass of detailed rules about special cases. But the basics are easy to learn and the detailed rules can be looked up when needed. So it's very easy to [learn] enough accountancy to be a club treasurer or run a small business. Take anyone non-dyspraxic and teach them blacksmithing? Straightforward and can be done in a weekend. The student will only have a repertoire of basic techniques, and their work won't be up to the quality of an expert. But it won't be fundamentally flawed and the student will have the basis for future learning. But take anyone who can't prove a theorem and teach them to program ? No, thanks. Because proving theorems is a special skill which requires thinking differently to the way all people think most of the time and many people think all of the time. Most thinking is done by analogy. X looks like Y, Y would do A, so X does A. Thinking this way has the great benefit of being very fast and producing answers which are right enough, enough of the time, to be able to live most or all of our lives that way. But in abstract mathematics (which IMO includes programming) this is a sure way into confusion and error. The other way of thinking - abstract reasoning - is foreign to many people because they never have to do it. Even things that look like reasoning (eg most political discourse) are mostly comprehensible using only analogy-based thinking. And what is a program ? Well, a program is an unproved conjecture: `here is some code which does what is required'. And often one where the exact terms of the conjecture are not clearly stated, just to make it more difficult. Counterexamples to the conjecture, or errors in understanding which conjecture ought to have been considered, are what are called `bugs'. The best way to remove bugs from a program is to not write them in the first place: and that involves clearheaded abstract reasoning - ie, proving, in one's mind, that the program is correct. Programs are too complex and too long to write out a formal proof for most of them. But when a programmer is writing code they have to have in their mind at least what a mathematician would call a proof sketch. And when challenged they need to be able to explain their proof to other people, and see if it is flawed. (As an aside, this is why testing is of such limited use. Ultimately it amounts to an attempt to search for a counterexample to the conjecture that is the program. But programs are very hard to analyse and what with the conjecture's conclusion (ie the program's intended behaviour) not being formally stated, this is inherently a time-consuming and fallible approach. Testing is useful because it can reveal gross but simple errors fairly cheaply.) All of this is of course talking about actual programming rather than copy-and-hack `this seems to work for me right now'. That latter depends only on analogistic thinking. It yields programs which may have worked this time but won't necessarily work tomorrow with different input. [...] -- Ian Jackson personal email: These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/ PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657