[31562] in Perl-Users-Digest
Perl-Users Digest, Issue: 2821 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 17 09:09:25 2010
Date: Wed, 17 Feb 2010 06:09:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 17 Feb 2010 Volume: 11 Number: 2821
Today's topics:
Re: a defense of ad hoc software development dan@telent.net
Re: a defense of ad hoc software development <dr.mtarver@ukonline.co.uk>
Re: a defense of ad hoc software development <dr.mtarver@ukonline.co.uk>
Re: a defense of ad hoc software development <rNOSPAMon@flownet.com>
Re: a defense of ad hoc software development <m@rtij.nl.invlalid>
Re: a defense of ad hoc software development <alessiostalla@gmail.com>
Re: a defense of ad hoc software development <timx@nospam.dev.null>
Re: Anyone willing to modify 3rd party perl code? <RedGrittyBrick@spamweary.invalid>
Re: saving old versions of file <hhr-m@web.de>
Re: saving old versions of file <devnull4711@web.de>
Re: Substitution with parameters and variable don't wor sln@netherlands.com
Substitution with parameters and variable don't work s <latiniadb@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 16 Feb 2010 22:00:39 +0000
From: dan@telent.net
Subject: Re: a defense of ad hoc software development
Message-Id: <87iq9wyh6g.fsf@lsip.4a.telent.net>
Mark Tarver <dr.mtarver@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, but it's of no help at all
in creating an algorithm for how to get it.
-dan
------------------------------
Date: Tue, 16 Feb 2010 14:13:45 -0800 (PST)
From: Mark Tarver <dr.mtarver@ukonline.co.uk>
Subject: Re: a defense of ad hoc software development
Message-Id: <9b84aab6-3fc9-4431-a320-cc4fd50bd048@b7g2000yqd.googlegroups.com>
On 16 Feb, 22:00, d...@telent.net wrote:
> Mark Tarver <dr.mtar...@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, but it's of no help at all
> in creating an algorithm for how to get it.
>
> -dan
Actually, and coincidentally, that's the very example which is used in
Constable's book of 25 years ago to introduce CTT via Nuprl. And the
specification looks almost exactly like yours. And the program is
derived without hacking any code.
The book is
Implementing Mathematics with the Nuprl Proof Development System.
Prentice-Hall, Engelwood Cliffs, NJ, 1986 (with PRL Group).
ftp://ftp.cs.cornell.edu/pub/nuprl/doc/book.ps.gz
might deliver it up.
Mark
------------------------------
Date: Tue, 16 Feb 2010 14:44:17 -0800 (PST)
From: Mark Tarver <dr.mtarver@ukonline.co.uk>
Subject: Re: a defense of ad hoc software development
Message-Id: <6e87e99b-d916-4062-9e83-1a5e0394dcc6@v25g2000yqk.googlegroups.com>
On 16 Feb, 22:13, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> On 16 Feb, 22:00, d...@telent.net wrote:
>
>
>
>
>
> > Mark Tarver <dr.mtar...@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=3D52
>
> > That specification says exactly what I want, but it's of no help at all
> > in creating an algorithm for how to get it.
>
> > -dan
>
> Actually, and coincidentally, that's the very example which is used in
> Constable's book of 25 years ago to introduce CTT via Nuprl. =A0And the
> specification looks almost exactly like yours. =A0And the program is
> derived without hacking any code.
> The book is
>
> Implementing Mathematics with the Nuprl Proof Development System.
> Prentice-Hall, Engelwood Cliffs, NJ, 1986 (with PRL Group).
>
> ftp://ftp.cs.cornell.edu/pub/nuprl/doc/book.ps.gz
>
> might deliver it up.
>
> Mark- Hide quoted text -
>
> - Show quoted text -
However that said, Graham is 90% right. You just have to reformulate
what he says a little from
You can't write specifications that say exactly what you want. If the
specification were that precise, then they would be the program.
to
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.
And that's about right. But there is not a lot of point in
specifications that are as long as the program because then there is
as much chance of making an error in the specification as in the
program. Hence the specification brings no actual security.
Ideally specifications should be
1. Totally determinant of the correctess of the program.
2. Short and dazzingly clear.
However these two requirements are generally at odds with one
another. If you buy into 'short and dazzingly clear' then your
specification will likely underspecify. If you buy into 'totally
determinant' then your specification is likely to approach the length
of the program.
In the case of CTT, when you count in the axioms and rules needed to
synthesise a program, the length actually exceeds the length of the
program by a wide margin. For instance in my short intro to CTT in
Qi, I formally specify and synthesise a program that adds two numbers
together - with the aid of 24 pages of math'l logic.
http://www.lambdassociates.org/Lib/Logic/Martin-Lof/martin-lof.pdf
The lesson to be learned is that though, with great effort, you can
reduce programming to a math'l activity but it may not gain in clarity
or accuracy from so doing.
Mark
------------------------------
Date: Tue, 16 Feb 2010 23:21:02 -0800
From: Ron Garret <rNOSPAMon@flownet.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <rNOSPAMon-26B9C4.23203216022010@news.albasani.net>
In article
<2f580d01-8f4c-4c08-a6a6-8fc84dd4658e@15g2000yqa.googlegroups.com>,
Mark Tarver <dr.mtarver@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.
rg
------------------------------
Date: Wed, 17 Feb 2010 08:34:44 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: a defense of ad hoc software development
Message-Id: <kpis47-nil.ln1@news.rtij.nl>
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
------------------------------
Date: Wed, 17 Feb 2010 02:16:22 -0800 (PST)
From: Alessio Stalla <alessiostalla@gmail.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <b0ab1308-1e6f-4a16-82b4-41a96399fa23@m37g2000yqf.googlegroups.com>
On Feb 17, 8:21=A0am, Ron Garret <rNOSPA...@flownet.com> wrote:
> In article
> <2f580d01-8f4c-4c08-a6a6-8fc84dd46...@15g2000yqa.googlegroups.com>,
> =A0Mark Tarver <dr.mtar...@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. =A0But 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). =A0That's not th=
e
> > 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. =A0There are many
> precise specifications that are nonetheless very hard or impossible to
> render into code, the classic example being F(X,Y)=3DTRUE if and only if =
X
> is the encoding of a program that halts when run on input Y. =A0Imprecise
> specifications are only one of many potential challenges to producing
> code that does what you want. =A0Inverting SHA1, factoring RSA1024, and
> decrypting AES256 are all specifications that can be rendered with
> absolute precision. =A0But 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
------------------------------
Date: Wed, 17 Feb 2010 23:31:43 +1100
From: Tim X <timx@nospam.dev.null>
Subject: Re: a defense of ad hoc software development
Message-Id: <87pr4459hs.fsf@lion.rapttech.com.au>
Alessio Stalla <alessiostalla@gmail.com> writes:
> On Feb 17, 8:21Â am, Ron Garret <rNOSPA...@flownet.com> wrote:
>> In article
>> <2f580d01-8f4c-4c08-a6a6-8fc84dd46...@15g2000yqa.googlegroups.com>,
>> Â Mark Tarver <dr.mtar...@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
------------------------------
Date: Wed, 17 Feb 2010 10:42:24 +0000
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: Anyone willing to modify 3rd party perl code?
Message-Id: <4b7bc811$0$2525$da0feed9@news.zen.co.uk>
On 16/02/2010 20:20, buck wrote:
> I have a perl script written by Christian Mock obtained from
> http://www.tahina.priv.at/~cm/spam/ . The purpose of this code is to
> ask SMTP servers not already whitelisted in greylist,sqlite DB to wait a
> while and then retry sending to my Postfix SMTP server (selective SPAM
> control). The script does not work as I'd like, so I'd like for it to
> be thoroughly commented and modified so that it does what I want.
Sounds like what ESR characterizes as an open-ended time-sink.
> I am not capable of doing that.
Have you considered expanding your capabilities?
> If anyone is willing to comment and/or modify the code, it can be
> downloaded from ftp://andthatsjazz.org/pub/meta-greylist and uploaded to
> ftp://andthatsjazz.org/incoming.
>
> Alternatively, if anyone knows of an existing script that is better, a
> link to it would be welcome.
You didn't say how much you are willing to pay someone to do this work
for you. I assume zero.
I sense that you need to research a bit more about what motivates people
to dedicate time and effort to a project for free. I don't feel you're
hitting the right buttons.
http://www.catb.org/~esr/faqs/smart-questions.html#explicit
http://catb.org/~esr/writings/
------------------------------
Date: Tue, 16 Feb 2010 22:40:37 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: Re: saving old versions of file
Message-Id: <Pine.LNX.4.64.1002162235150.9683@lxhri01.lrz.lrz-muenchen.de>
On Tue, 16 Feb 2010, Frank Seitz wrote:
> Helmut Richter wrote:
> > On Tue, 16 Feb 2010, Frank Seitz wrote:
>
> >>> ln -s foobar.log foobar[whateverthenewdayis]
> >>
> >> A symlink is obviously not a solution, because the file
> >> gets overwritten with every run.
> >
> > The other way would work:
> >
> > Every night:
> > rm foobar.log
> > ln -s foobar[whateverthenewdayis] foobar.log
>
> No, but a hardlink (ln without -s) or cp would do it.
The softlink works: when the program tries to open foobar.log, it opens
the linked-to file instead.
The hardlink does not work because one cannot create a hardlink to a
non-existent file. If hardlink, the sequence would have to be:
touch foobar[whateverthenewdayis]
rm foobar.log
ln foobar[whateverthenewdayis] foobar.log
--
Helmut Richter
------------------------------
Date: Wed, 17 Feb 2010 10:38:47 +0100
From: Frank Seitz <devnull4711@web.de>
Subject: Re: saving old versions of file
Message-Id: <7u1rp7FrbpU3@mid.individual.net>
Helmut Richter wrote:
> On Tue, 16 Feb 2010, Frank Seitz wrote:
>> Helmut Richter wrote:
>>> On Tue, 16 Feb 2010, Frank Seitz wrote:
>>>>> ln -s foobar.log foobar[whateverthenewdayis]
>>>> A symlink is obviously not a solution, because the file
>>>> gets overwritten with every run.
>>> The other way would work:
>>>
>>> Every night:
>>> rm foobar.log
>>> ln -s foobar[whateverthenewdayis] foobar.log
>> No, but a hardlink (ln without -s) or cp would do it.
>
> The softlink works: when the program tries to open foobar.log, it opens
> the linked-to file instead.
You are right.
> The hardlink does not work because one cannot create a hardlink to a
> non-existent file. If hardlink, the sequence would have to be:
>
> touch foobar[whateverthenewdayis]
> rm foobar.log
> ln foobar[whateverthenewdayis] foobar.log
Yes. Maybe a mv would suffice.
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Blog: http://www.fseitz.de/blog
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
------------------------------
Date: Wed, 17 Feb 2010 04:01:20 -0800
From: sln@netherlands.com
Subject: Re: Substitution with parameters and variable don't work s/$search/$replace/i
Message-Id: <ggmnn512sc95k8a3drmu8d16ftqe6il0q1@4ax.com>
On Wed, 17 Feb 2010 01:26:35 -0800 (PST), Joan Interactive Bussiness <latiniadb@gmail.com> wrote:
># line to translate
>$line = 'var varchar2(10)';
>
># I hope to answer: var number(10)
>
># With replace Variable, not OK
>$find = 'varchar2\((.+)\)';
$replace = '"number($1)"';
$line =~ s/$find/$replace/ee;
Here we go again..
-sln
------------------------------
Date: Wed, 17 Feb 2010 01:26:35 -0800 (PST)
From: Joan Interactive Bussiness <latiniadb@gmail.com>
Subject: Substitution with parameters and variable don't work s/$search/$replace/i
Message-Id: <6d217fa2-2e0a-46ac-bdd9-ee8f57fd62a0@b2g2000yqi.googlegroups.com>
Very easy sample:
# line to translate
$line = 'var varchar2(10)';
# I hope to answer: var number(10)
# With replace Variable, not OK
$find = 'varchar2\((.+)\)';
$replace = 'number($1)';
$line =~ s/$find/$replace/;
print $line."\n";
# result >>>>>> var number($1)
# Without replace Variable, it's OK
$line2 = 'var varchar2(10)';
$line2 =~ s/varchar2\((.+)\)/number($1)/;
print $line2."\n";
# result >>>>>> var number(10)
# ----------------------------------------
P:\DB\WORK\perl>perl test.pl
var number($1)
var number(10)
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2821
***************************************
