a defense of ad hoc software development
in [Lisp]
|
Prev: Some help with sort
Next: SBCL optimization
From: ccc31807 on 14 Jan 2010 09:46 On page 229 of Paul Graham's 'ANSI Common Lisp' he writes: <quote> If programming were an entirely mechanical process -- a matter of simply translating specifications into code -- it would be reasonable to do everything in a single step. But programming is never like that. No matter how precise the specifications, programming always involves a certain amount of exploration -- usually a lot more than anyone had anticipated. It might seem that if the specifications wee good, programming would simply be a matter of translating them into code. This is a widespread misconception. Programming necessarily involves exploration, because specifications are necessarily vague. If they weren't vague, they wouldn't be specifications. In other fields, it may be desirable for specifications to be as precise as possible. If you're asking for a piece of metal to be cut into a certain shape, it's probably best to say exactly what you want. But this rule does not extend to software, because programs and specifications are made out of the same thing: text. You can't write specifications that say exactly what you want. If the specification were that precise, then they would be the program. </quote> In a footnote, Graham writes: <quote> The difference between specifications and programs is a difference in degree, not a difference in kind. Once we realize this, it seems strange to require that one write specifications for a program before beginning to implement it. If the program has to be written in a low-level language, then it would be reasonable to require that it be described in high-level terms first. But as the programming language becomes more abstract, the need for specifications begins to evaporate. Or rather, the implementation and the specifications can become the same thing. If the high-level language is going to be re-implemented in a lower-level language, it starts to look even more like specifications. What Section 13l.7 is saying, in other words, is that the specifications for C programs could be written in Lisp. </quote> In my SwE classes, we spent a lot of time looking at process and processes, including MIL STD 498 and IEEE Std 830-1984, etc. My professors were both ex-military, one who spent his career in the USAF developing software and writing Ada, and both were firmly in the 'heavy' camp (as opposed to the lightweight/agile camp). In my own job, which requires writing software for lay users, all I ever get is abbreviated English language requests, and I have learned better than to ask users for their requirements because they have no idea what requirements are. (As a joke, I have sent a couple a copy of IEEE Std 830-1984 and told them that I needed something like that, but the joke went over like a lead balloon -- not funny at all.) Of necessity I have learned to expect to write a number of versions of the same script before the user accepts it. I understand that Graham isn't talking about requirements, and to many people specifications and requirements amount to the same thing. I also understand the necessity for planning. However, the Graham quote seems to me a reasonable articulation for ad hoc development. (It's something I wanted to say to jue in particular but couldn't find the words.) Comments? CC
From: Pascal Costanza on 14 Jan 2010 10:45 On 14/01/2010 15:46, ccc31807 wrote: > On page 229 of Paul Graham's 'ANSI Common Lisp' he writes: > > <quote> > If programming were an entirely mechanical process -- a matter of > simply translating specifications into code -- it would be reasonable > to do everything in a single step. But programming is never like that. > No matter how precise the specifications, programming always involves > a certain amount of exploration -- usually a lot more than anyone had > anticipated. > It might seem that if the specifications wee good, programming > would simply be a matter of translating them into code. This is a > widespread misconception. Programming necessarily involves > exploration, because specifications are necessarily vague. If they > weren't vague, they wouldn't be specifications. > In other fields, it may be desirable for specifications to be as > precise as possible. If you're asking for a piece of metal to be cut > into a certain shape, it's probably best to say exactly what you want. > But this rule does not extend to software, because programs and > specifications are made out of the same thing: text. You can't write > specifications that say exactly what you want. If the specification > were that precise, then they would be the program. > </quote> > > In a footnote, Graham writes: > > <quote> > The difference between specifications and programs is a > difference in degree, not a difference in kind. Once we realize this, > it seems strange to require that one write specifications for a > program before beginning to implement it. If the program has to be > written in a low-level language, then it would be reasonable to > require that it be described in high-level terms first. But as the > programming language becomes more abstract, the need for > specifications begins to evaporate. Or rather, the implementation and > the specifications can become the same thing. > If the high-level language is going to be re-implemented in a > lower-level language, it starts to look even more like specifications. > What Section 13l.7 is saying, in other words, is that the > specifications for C programs could be written in Lisp. > </quote> > > In my SwE classes, we spent a lot of time looking at process and > processes, including MIL STD 498 and IEEE Std 830-1984, etc. My > professors were both ex-military, one who spent his career in the USAF > developing software and writing Ada, and both were firmly in the > 'heavy' camp (as opposed to the lightweight/agile camp). > > In my own job, which requires writing software for lay users, all I > ever get is abbreviated English language requests, and I have learned > better than to ask users for their requirements because they have no > idea what requirements are. (As a joke, I have sent a couple a copy of > IEEE Std 830-1984 and told them that I needed something like that, but > the joke went over like a lead balloon -- not funny at all.) Of > necessity I have learned to expect to write a number of versions of > the same script before the user accepts it. > > I understand that Graham isn't talking about requirements, and to many > people specifications and requirements amount to the same thing. I > also understand the necessity for planning. However, the Graham quote > seems to me a reasonable articulation for ad hoc development. (It's > something I wanted to say to jue in particular but couldn't find the > words.) > > Comments? Putting oneself in a situation where one passively waits for requirements from customers is a very lazy way of approaching one's job. People hire programmers for being creative, and this includes coming up with solutions that _surprise_ customers and helps to solve their problems in ways that are _better_ than they expected. If users could write requirements precisely enough for you to implement them, they could implement them themselves. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Marc Girod on 14 Jan 2010 12:54 On Jan 14, 2:46 pm, ccc31807 <carte...(a)gmail.com> wrote: > Comments? Paul Graham is a genious. He speaks Gold. I loved his book /On LISP/. Planning is useful, but plans are worthless. Marc
From: fortunatus on 14 Jan 2010 17:29 On Jan 14, 9:46 am, ccc31807 <carte...(a)gmail.com> wrote: > In my own job, which requires writing software for lay users, all I > ever get is abbreviated English language requests, and I have learned > better than to ask users for their requirements because they have no > idea what requirements are. Nobody expects non-programmers to be able to generate programmers's requirements. Programmers generate requirements for themselves based on less formal Q&A with the customer. No matter what, a programmer works to specific requirements that are supposed to match the user's expectations and/or needs. The requirements might be in the programmer's head, and they might be developed by evolutionary process throughout the code writing, but they exist. If there is more than one programmer on a team then there is a need to codify requirements into documents to some degree. I think it is not feasible to say that requriements can be so detailed as to be directly executable. In teamwork it is useful to communicate when there remains a large degree of ambiguity, and allow team members to contribute to resolutions. So you can use Lisp to capture/express requirements, but it won't be a complete solution to the problem before you break the work up among team members. Yet at that stage it would normally be named a requirements document. My point is that the work needs to be broken up and distributed among team members before ambiguity is resolved. At that point there should be some requirements written down for team members to start working from. Therefore the requirements, at that stage, even if captured in Lisp or other executable format, /must/ have too many holes to really solve the whole problem, or else the team is not dividing the workload effectively.
From: Pascal J. Bourguignon on 15 Jan 2010 01:26
ccc31807 <cartercc(a)gmail.com> writes: > On page 229 of Paul Graham's 'ANSI Common Lisp' he writes: > > <quote> > [...] > Comments? Indeed. See also: http://www.developerdotstar.com/mag/articles/reeves_design_main.html http://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf -- __Pascal Bourguignon__ http://www.informatimago.com/ |