a defense of ad hoc software development
in [Lisp]
|
Prev: Some help with sort
Next: SBCL optimization
From: Martijn Lievaart on 17 Feb 2010 02:34 On Tue, 16 Feb 2010 14:44:17 -0800, Mark Tarver wrote: > You can't write specifications that say exactly what you want. If the > specification were that precise, then they would be the program or as > long as the program. There is a difference. The specifications should be readable for domain experts and the programmers. I've seen plenty of cases where the specifications were actually a fair bit longer than the program itself. M4
From: Alessio Stalla on 17 Feb 2010 05:16 On Feb 17, 8:21 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: > In article > <2f580d01-8f4c-4c08-a6a6-8fc84dd46...(a)15g2000yqa.googlegroups.com>, > Mark Tarver <dr.mtar...(a)ukonline.co.uk> wrote: > > > QUOTE > > You can't write specifications that say exactly what you want. If the > > specification were that precise, then they would be the program. > > UNQUOTE > > > That's a very clever and profound observation from Paul Graham. > > It is also demonstrably false. > > > The formal methods people might disagree though. > > The formal methods people are also wrong, but for different reasons. > > > I think the obvious counterexample comes from constructive type > > theory, where the specification is a type designed to determine the > > program. But the specification is nevertheless not itself a program. > > The program emerges as a byproduct of an attempt to prove that the > > specification can be met (that the type is inhabited). That's not the > > end of the argument; its just pawn to e4, pawn to e5 in this debate. > > You don't have to get anywhere near that esoteric. There are many > precise specifications that are nonetheless very hard or impossible to > render into code, the classic example being F(X,Y)=TRUE if and only if X > is the encoding of a program that halts when run on input Y. Imprecise > specifications are only one of many potential challenges to producing > code that does what you want. Inverting SHA1, factoring RSA1024, and > decrypting AES256 are all specifications that can be rendered with > absolute precision. But that will not help you at all when it comes > time to code them up. Those are all *requirements* specifications, i.e. *what* the program should do. Like the OP, I don't think PG is talking about requirements, but rather about design specifications (e.g. UML diagrams and the like) - that is, about a high-level description of *how* the program should work. With that in mind, I agree 100% with Paul Graham. That said, high-level descriptions of a program can still have a useful role for documentation purposes, that is, if they are synthesized from the program (and not vice-versa as software engineering adepts believe). Alessio Stalla
From: Tim X on 17 Feb 2010 07:31 Alessio Stalla <alessiostalla(a)gmail.com> writes: > On Feb 17, 8:21 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: >> In article >> <2f580d01-8f4c-4c08-a6a6-8fc84dd46...(a)15g2000yqa.googlegroups.com>, >> Mark Tarver <dr.mtar...(a)ukonline.co.uk> wrote: >> >> > QUOTE >> > You can't write specifications that say exactly what you want. If the >> > specification were that precise, then they would be the program. >> > UNQUOTE >> >> > That's a very clever and profound observation from Paul Graham. >> >> It is also demonstrably false. >> >> > The formal methods people might disagree though. >> >> The formal methods people are also wrong, but for different reasons. >> >> > I think the obvious counterexample comes from constructive type >> > theory, where the specification is a type designed to determine the >> > program. But the specification is nevertheless not itself a program. >> > The program emerges as a byproduct of an attempt to prove that the >> > specification can be met (that the type is inhabited). That's not the >> > end of the argument; its just pawn to e4, pawn to e5 in this debate. >> >> You don't have to get anywhere near that esoteric. There are many >> precise specifications that are nonetheless very hard or impossible to >> render into code, the classic example being F(X,Y)=TRUE if and only if X >> is the encoding of a program that halts when run on input Y. Imprecise >> specifications are only one of many potential challenges to producing >> code that does what you want. Inverting SHA1, factoring RSA1024, and >> decrypting AES256 are all specifications that can be rendered with >> absolute precision. But that will not help you at all when it comes >> time to code them up. > > Those are all *requirements* specifications, i.e. *what* the program > should do. Like the OP, I don't think PG is talking about > requirements, but rather about design specifications (e.g. UML > diagrams and the like) - that is, about a high-level description of > *how* the program should work. With that in mind, I agree 100% with > Paul Graham. > That said, high-level descriptions of a program can still have a > useful role for documentation purposes, that is, if they are > synthesized from the program (and not vice-versa as software > engineering adepts believe). > I agree with your interpretation of what PG was referring to. I also think your other points are correct and concisely expressed. I have seen specifications that go down to the detail of specifying the function names, arguments the functions will accept and the return values - all of which being defined before any code has been written (remember the Z notation/specification). I believe this is a mistake. Note that this is different from specifying something like a protocol and is even different to specifying a high level API interface. Specifications of this form can be useful and sometimes need to be there. Such specifications are OK provided the programmer is not limited to only defining those artifacts. I don't mind a specification that says I must provide specific function calls with specific signatures provided I'm also free to create other functions of varying signatures during the development of the software. These 'other' functions will change and develop as I explore the problem and will become more refined as I understand both the problem area and the solution better. In such a situation, I would not be surprised to find limitations or short comings in the original protocol/api spec, but thats what revisions and updated standards are for. I also think one of the things PG was warning against was the type of analysis paralysis you often encounter with things like UML and other formal specificaiton processes. All too often, you end up with a laundry list of specification requirements, much of which are only of theoretical use and are never actually used. To a large extent, this is what much of the agile philosophy attempts to avoid. All too often, you will see, particularly in OO specs, classes with getters/setters for absolutely everything, many of which never actually get used. The agile approach would argue that you don't actually define a method until you actually need it - you don't define it because you think you may need it someday. For me, the key part is that I don't believe you can really understand all the detailed intricacies of a problem until you actually sit down and start trying to solve it. Its similar to trying to learn a programming language. Its not enough to just read about it and look at examples. You ahve to actually sit down and start using the language before you really get to know and understand it. Ultimately, its the actual coding that transforms our abstract understanding to more concrete real understanding. Both processes are important and we should avoid any process that artificially limits one or the other. Too often, formal specifications limit our ability to explore and gain increased insight into the problem, limiting our ability to find the best solution. Unfortunately, management doesn't like exploration and experimentation because there are no guarantees of success and you can't easily estimate completion time. such things make them nervous because they have hard limits wrt resources and deadlines. Tim -- tcross (at) rapttech dot com dot au
From: Ron Garret on 17 Feb 2010 11:52 In article <b0ab1308-1e6f-4a16-82b4-41a96399fa23(a)m37g2000yqf.googlegroups.com>, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Feb 17, 8:21 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: > > In article > > <2f580d01-8f4c-4c08-a6a6-8fc84dd46...(a)15g2000yqa.googlegroups.com>, > > Mark Tarver <dr.mtar...(a)ukonline.co.uk> wrote: > > > > > QUOTE > > > You can't write specifications that say exactly what you want. If the > > > specification were that precise, then they would be the program. > > > UNQUOTE > > > > > That's a very clever and profound observation from Paul Graham. > > > > It is also demonstrably false. > > > > > The formal methods people might disagree though. > > > > The formal methods people are also wrong, but for different reasons. > > > > > I think the obvious counterexample comes from constructive type > > > theory, where the specification is a type designed to determine the > > > program. But the specification is nevertheless not itself a program. > > > The program emerges as a byproduct of an attempt to prove that the > > > specification can be met (that the type is inhabited). That's not the > > > end of the argument; its just pawn to e4, pawn to e5 in this debate. > > > > You don't have to get anywhere near that esoteric. There are many > > precise specifications that are nonetheless very hard or impossible to > > render into code, the classic example being F(X,Y)=TRUE if and only if X > > is the encoding of a program that halts when run on input Y. Imprecise > > specifications are only one of many potential challenges to producing > > code that does what you want. Inverting SHA1, factoring RSA1024, and > > decrypting AES256 are all specifications that can be rendered with > > absolute precision. But that will not help you at all when it comes > > time to code them up. > > Those are all *requirements* specifications, i.e. *what* the program > should do. Like the OP, I don't think PG is talking about > requirements, but rather about design specifications (e.g. UML > diagrams and the like) - that is, about a high-level description of > *how* the program should work. With that in mind, I agree 100% with > Paul Graham. Ah. Yes, going back and looking at the context it seems you're right. The phrase "what you want" is a bit misleading out of context. > That said, high-level descriptions of a program can still have a > useful role for documentation purposes, that is, if they are > synthesized from the program (and not vice-versa as software > engineering adepts believe). No, I don't think so. My point was that there's an unbridgeable gulf between "what" and "how". You can't go back and forth between them automatically in either direction (except in trivial ways like extracting function signatures). rg
From: Peter J. Holzer on 17 Feb 2010 12:17
On 2010-02-16 22:00, dan(a)telent.net <dan(a)telent.net> wrote: > Mark Tarver <dr.mtarver(a)ukonline.co.uk> writes: > >> QUOTE >> You can't write specifications that say exactly what you want. If the >> specification were that precise, then they would be the program. >> UNQUOTE >> >> That's a very clever and profound observation from Paul Graham. The >> formal methods people might disagree though. > > So would I. > > I would like a program that calculates the number x for which x*x=52 > > That specification says exactly what I want, No. Most importantly it doen't say what the output should look like. Mathematically, the result is 2*sqrt(13). But most likely you don't want a symbolic result, but a floating point number with some number of (binary or decimal) digits. > but it's of no help at all in creating an algorithm for how to get it. It is if your programming language includes a primitive or library function for solving quadratic equations. I would like to change one word in PG's quip: You can't write specifications that say exactly what you want. If the specification were that precise, then they would be *a* program. If the specification doesn't say how to solve a small, well-understood subproblem, that's not very much different from calling a library function in a program. As a different example, consider sorting: The specification may specify the intended sort order but not the sorting algorithm. In a similar way, many programming languages provide a sort function. The programmer using this function typically doesn't care whether that sort function implements a quickersort, heapsort or mergesort, or some hybrid scheme. He just specifies an order (often in the form of a comparison function) and leaves the details to the implementation. The more I think about this the more I think PG has stumbled upon a truth here: A specification really is a program. But the "programming language" in which it is written is almost always declarative and not imperative. There usually isn't any interpreter for the language except the brains of the audience (although parts of the specification/program may be written in a formal language). hp |