[31512] in Perl-Users-Digest
Perl-Users Digest, Issue: 2771 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 15 21:09:46 2010
Date: Fri, 15 Jan 2010 18:09:11 -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 Fri, 15 Jan 2010 Volume: 11 Number: 2771
Today's topics:
Re: a defense of ad hoc software development <cartercc@gmail.com>
Re: a defense of ad hoc software development <tfb@tfeb.org>
Re: a defense of ad hoc software development <markhaniford@gmail.com>
Re: a defense of ad hoc software development <timx@nospam.dev.null>
Re: a defense of ad hoc software development <markhaniford@gmail.com>
Re: Conrol structure query ... <tzz@lifelogs.com>
Re: Conrol structure query ... <tzz@lifelogs.com>
Re: control structure query ... <jurgenex@hotmail.com>
Re: converting from 'use' to 'require' (Seymour J.)
Re: FAQ 9.16 How do I decode a CGI form? <paduille.4061.mumia.w+nospam@earthlink.net>
Re: some perl programs I wrote <ralph.malph@altavista.com>
Re: some perl programs I wrote sln@netherlands.com
Re: some perl programs I wrote <ralph.malph@altavista.com>
Re: some perl programs I wrote <jurgenex@hotmail.com>
Re: sprintf '%.5s', 123456789 <doom@kzsu.stanford.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 15 Jan 2010 07:30:49 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <4d35733d-2097-44c5-a61e-a6f1bfbd88ad@a32g2000yqm.googlegroups.com>
On Jan 14, 5:29=A0pm, fortunatus <daniel.elia...@excite.com> wrote:
> Nobody expects non-programmers to be able to generate programmers's
> requirements.
I don't know the difference between 'requirements' and 'specification'
but I assume that the requirements state what the software will do,
and the specification states how the software will do it.
People like to poke fun at UML use cases and use case diagrams, me
included. However, use cases can describe in the language of the
problem domain the functional requirements (if not the non-functional
requirements as well), e.g.
- customer presents the goods to the cashier
- cashier determines the price of the goods
- cashier calculates the total price including tax
- cashier informs customer of the total price
- customer tenders the price in cash, check, or plastic
- cashier accepts customer's tender
- cashier gives customer a receipt for the goods.
> Programmers generate requirements for themselves based on less formal
> Q&A with the customer.
It may be more accurate to say that the programmer generates the
design based on (1) functional requirements furnished by the client,
and (2) an explicit or tacit specification based on those
requirements.
> requirements might be in the programmer's head, and they might be
> developed by evolutionary process throughout the code writing, but
> they exist.
I've been taken to task (on c.l.p.m.) for saying that many times I
just start writing code without doing any analysis or design.
Obviously, for a larger project, analysis and design is essential. I
think that Graham's point is that analysis, design, and implementation
can be integrated with more efficiency and less work. Obviously, you
can't build a sizable application this way, but just as obviously any
sizable application necessarily contains problems that can only be
solved by experimentation.
CC.
------------------------------
Date: Fri, 15 Jan 2010 23:28:32 +0000
From: Tim Bradshaw <tfb@tfeb.org>
Subject: Re: a defense of ad hoc software development
Message-Id: <2010011523283216807-tfb@tfeborg>
On 2010-01-15 02:44:15 +0000, Barry Margolin <barmar@alum.mit.edu> said:
> Writing specifications precise enough to be validated
> mechanically *is* programming.
I was going to say "and there are these programs called compilers which
turn them into executable programs" but that's not quite right. A
specification could just give a way of testing whether something meets
it, without giving a way for that thing to be constructed, while a
program has to give a way to construct that thing. So perhaps a
specification is not programming: it's just something which is as hard
as programming.
------------------------------
Date: Fri, 15 Jan 2010 15:46:30 -0800 (PST)
From: "MarkHaniford@gmail.com" <markhaniford@gmail.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <b7af2880-5aff-47d3-958b-78e9dfc46b83@h9g2000yqa.googlegroups.com>
On Jan 14, 8:44=A0pm, Barry Margolin <bar...@alum.mit.edu> wrote:
>
> That may be true, but what he says in this particular article is
> correct. =A0Read the book "Coders at Work", and you'll learn that most of
> the great programmers think similarly. =A0Programming simply cannot be
> mechanized. =A0Writing specifications precise enough to be validated
> mechanically *is* programming.
>
Programming is already mechanized. The problem is with having
"business analysts" spending 10x as much time "writing out the specs"
to be mechanized than a "normal" programmer. Or on another note, your
CFO could spend hours a day cleaning toilets at the office too.
------------------------------
Date: Sat, 16 Jan 2010 11:11:05 +1100
From: Tim X <timx@nospam.dev.null>
Subject: Re: a defense of ad hoc software development
Message-Id: <87vdf2c3ja.fsf@lion.rapttech.com.au>
ccc31807 <cartercc@gmail.com> writes:
>
> I've been taken to task (on c.l.p.m.) for saying that many times I
> just start writing code without doing any analysis or design.
> Obviously, for a larger project, analysis and design is essential. I
> think that Graham's point is that analysis, design, and implementation
> can be integrated with more efficiency and less work. Obviously, you
> can't build a sizable application this way, but just as obviously any
> sizable application necessarily contains problems that can only be
> solved by experimentation.
>
Analysis is critical because that is how, you as the programmer, get to
understand the domain problem you will be working in. Design is also
important, but it should not be carved in stone.
I think PGs main point is that it is often during the implementation
that you gain that deeper understanding of the problem that provides the
insight for better solutions and you want to avoid any specification
that is so detailed that you cannot adopt those better solutions because
they would not fit with the specification.
I've worked on projects in the past where the specification was so
detailed, it included all the names of procedures/functions, the
arguments they would accept and the values they would return. As a
developer on that project, all you were expected to do was write those
functions and procedures and at the end, it would all fall together. It
was an uninspiring, horrible boring project and it was pretty much a
failure.
I think what PG is talking about is close to what the Agile (God I hate
that term - bloody weasel word. Lets face it, who the hell doesn't want
to be 'agile'!) camp has been proposing. Use user stories to get an
understanding of what is required and then use test driven development
to not only verify the code and protect against regressions after
refactoring, but also to verify you as the programmer understand the
customer/owner's requirements. This is why tests should be developed in
conjunction with the product owner or representatitve/expert from the
client side.
Requirements and specifications are all about communication. They are
there to ensure that everyone knows what the widget is and what the
widget needs to be able to do. The old waterfall methodology tried to
make it like dam and bridge building - eveyrthing would be specified
down to the last bolt and nail. Management would know exactly how much
it would cost and exactly how long it would take to build (at least,
they felt reassured they did). This approach
essentially failed. It failed because it was unable to take into account
that programming isn't like dam and bridge building. We don't have the
hundreds of years experience or the relatively well understood laws,
such as the laws of physics, that engineering in the physical world has.
Programming has more art than science. The solution often comes with
understanding and imagination, which is acquired as you attempt to solve
the problem and will seldom become obvious through analysis alone.
A major point that PG was trying to make is that your development
environment can assist in this process by making it easier to experiment
and explore the problem domain. He argues that lisp is one of the best
languages for doing this and it is why he believes a single lisp
developer can be more productive than, lets say, a developer using C.
This theme is also carried through in his other writings. For example,
he argues that the success of viaweb was because it used lisp and they
were able to add features faster than their competition. In fact, he
says that their competition often thought he had spies in their team
because they would release a new feature and viaweb would have
incorporated it by the end of that day.
Tim
--
tcross (at) rapttech dot com dot au
------------------------------
Date: Fri, 15 Jan 2010 17:58:12 -0800 (PST)
From: "MarkHaniford@gmail.com" <markhaniford@gmail.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <cf5195c0-bd40-4cc7-9de1-4348ba68f513@m3g2000yqf.googlegroups.com>
On Jan 15, 6:11=A0pm, Tim X <t...@nospam.dev.null> wrote:
> ccc31807 <carte...@gmail.com> writes:
>
> > I've been taken to task (on c.l.p.m.) for saying that many times I
> > just start writing code without doing any analysis or design.
> > Obviously, for a larger project, analysis and design is essential. I
> > think that Graham's point is that analysis, design, and implementation
> > can be integrated with more efficiency and less work. Obviously, you
> > can't build a sizable application this way, but just as obviously any
> > sizable application necessarily contains problems that can only be
> > solved by experimentation.
>
> Analysis is critical because that is how, you as the programmer, get to
> understand the domain problem you will be working in. Design is also
> important, but it should not be carved in stone.
>
> I think PGs main point is that it is often during the implementation
> that you gain that deeper understanding of the problem that provides the
> insight for better solutions and you want to avoid any specification
> that is so detailed that you cannot adopt those better solutions because
> they would not fit with the specification.
>
> I've worked on projects in the past where the specification was so
> detailed, it included all the names of procedures/functions, the
> arguments they would accept and the values they would return. As a
> developer on that project, all you were expected to do was write those
> functions and procedures and at the end, it would all fall together. It
> was an uninspiring, horrible boring project and it was pretty much a
> failure.
>
> I think what PG is talking about is close to what the Agile (God I hate
> that term - bloody weasel word. Lets face it, who the hell doesn't want
> to be 'agile'!) camp has been proposing. Use user stories to get an
> understanding of what is required and then use test driven development
> to not only verify the code and protect against regressions after
> refactoring, but also to verify you as the programmer understand the
> customer/owner's requirements. This is why tests should be developed in
> conjunction with the product owner or representatitve/expert from the
> client side.
>
> Requirements and specifications are all about communication. They are
> there to ensure that everyone knows what the widget is and what the
> widget needs to be able to do. The old waterfall methodology tried to
> make it like dam and bridge building - eveyrthing would be specified
> down to the last bolt and nail. Management would know exactly how much
> it would cost and exactly how long it would take to build (at least,
> they felt reassured they did). This approach
> essentially failed. It failed because it was unable to take into account
> that programming isn't like dam and bridge building. We don't have the
> hundreds of years experience or the relatively well understood laws,
> such as the laws of physics, that engineering in the physical world has.
> Programming has more art than science. The solution often comes with
> understanding and imagination, which is acquired as you attempt to solve
> the problem and will seldom become obvious through analysis alone.
>
> A major point that PG was trying to make is that your development
> environment can assist in this process by making it easier to experiment
> and explore the problem domain. He argues that lisp is one of the best
> languages for doing this and it is why he believes a single lisp
> developer can be more productive than, lets say, a developer using C.
> This theme is also carried through in his other writings. For example,
> he argues that the success of viaweb was because it used lisp and they
> were able to add features faster than their competition. In fact, he
> says that their competition often thought he had spies in their team
> because they would release a new feature and viaweb would have
> incorporated it by the end of that day.
>
> Tim
>
> --
> tcross (at) rapttech dot com dot au
Tim, I might reply to your response in detail later on, but I think
you made some good points. "Agile" has become a religion of its own,
and the whole mission of sitting down with your "customers" and
rapidly banging out mockups has been lost. It's the rapid-feedback
that gave death to waterfall (communication).
Not responding to you Tim, but on another note, nobody in their right
mind would hire anybody that writes Paul Graham type code. It's the
classic, "what happens when Billy gets hit by a bus".
------------------------------
Date: Fri, 15 Jan 2010 08:56:06 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Conrol structure query ...
Message-Id: <87ska7pgc9.fsf@lifelogs.com>
On Fri, 15 Jan 2010 10:41:25 GMT Russell Potter <russ.potter@bigpond.com> wrote:
RP> I was hoping someone could tell me, and also give me an example of
RP> the syntax of, a loop control structure sable to (at least reason-
RP> ably elegantly) transform a list such as, say, "(a, b, c)" into a
RP> string consisting of the concatenated contents of each list element,
RP> and each element separated by a hyphen (in our example: "a-b-c").
Are you looking for the join() function? It's hard to interpret your
input specification since you say it's a list but show it as a string
that can't be a Perl list as it stands.
Ted
------------------------------
Date: Fri, 15 Jan 2010 08:57:18 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Conrol structure query ...
Message-Id: <87ockvpga9.fsf@lifelogs.com>
On Fri, 15 Jan 2010 08:56:06 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote:
TZ> On Fri, 15 Jan 2010 10:41:25 GMT Russell Potter <russ.potter@bigpond.com> wrote:
RP> I was hoping someone could tell me, and also give me an example of
RP> the syntax of, a loop control structure sable to (at least reason-
RP> ably elegantly) transform a list such as, say, "(a, b, c)" into a
RP> string consisting of the concatenated contents of each list element,
RP> and each element separated by a hyphen (in our example: "a-b-c").
TZ> Are you looking for the join() function? It's hard to interpret your
TZ> input specification since you say it's a list but show it as a string
TZ> that can't be a Perl list as it stands.
I didn't see the other followups because the thread had a different
title (lowercase "control") there. Sorry for the noise--I see it's been
answered already.
Ted
------------------------------
Date: Fri, 15 Jan 2010 07:04:22 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: control structure query ...
Message-Id: <vi01l51d729ie87d5ji26ka4jpv2r62q3i@4ax.com>
Russell Potter <russ.potter@bigpond.com> wrote:
>
>> I have a very(!) hard time reading your text. What of that are typos and
>> what do you actually mean? What e.g. is a "tiring insisting onsisting"?
>> Or a "structure sable"?
>
>Sorry about all that mess: I lost around half my eyesight due
>to a major stroke about eight years ago (which also resulted
>in in my losing the use of my left arm and lots of trouble
>walking: but I'm not complaining since at least I'm alive
>abd recovering enough to try dabbling in PERL ... :-) so, no
>matter how hard I try, some (or, in thus case, lots of :-)
>stuff ecapes my checking :-(
Thank you very much for this explanation, it is much appreciated.
Unfortunately there are way to many jerks out there who just throw
undecipherable gibberish at the world or even deliberately use
misspellings to confuse people.
Thanks again for reminding me that there are some people with legitimate
spelling problems, too.
jue
------------------------------
Date: Thu, 14 Jan 2010 18:02:30 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: converting from 'use' to 'require'
Message-Id: <4b4fa286$19$fuzhry+tra$mr2ice@news.patriot.net>
In <op.u6jephrjmk9oye@frodo>, on 01/14/2010
at 08:21 PM, "Jochen Lehmeier" <OJZGSRPBZVCX@spammotel.com> said:
>You do not need an eval with require to make it conditional. require is
>not executed at compile time.
Thanks; I was looking at some code in bwWhois and misread the intent; the
eval is actually there to trap errors, not to avoid compile-time
processing.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 15 Jan 2010 13:28:33 -0600
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: FAQ 9.16 How do I decode a CGI form?
Message-Id: <W5ednb2kPurKXs3WnZ2dnUVZ_uadnZ2d@earthlink.com>
On 01/15/2010 07:13 AM, Helmut Richter wrote:
> On Fri, 15 Jan 2010, Helmut Richter wrote:
>
>> I think I made a mistake when testing. The CGI.pm module does *not* work
>> with forms in UTF-8, and the "-utf8" pragma has no effect, but at least no
>> detrimental effect on uploaded files. If you are not using a language with
>> restricted character set, you have to know what CGI.pm does (finding the
>> bytes representing the parameters in the filled-out forms) and what it
>> does not (interpreting them as characters).
>
> I should add an example script:
>
> #! /usr/local/bin/perl
>
> # The script asks for a file and a "location" and repeats the question until
> # "München" is given as location. The file should be interpreted as binary;
> # the test uses a .jpg file
> [...]
I think you're trying to demonstrate a bug in CGI.pm, and you're doing
that quite well, but here are my thoughts about your program:
First, you can't post to an HTML file:
http://www.lrz-muenchen.de/cgi/richter/test-utf.html . I changed that
when I ran your program.
Second, mutipart/form-data is supposed to be for binary files, and as
such is not suitable for utf8 data /unless/ you wish to handle the
convertion to/from utf8 yourself. I don't think that CGI.pm is
misbehaving too badly.
FWIW, I placed your program with my changes here:
http://home.earthlink.net/~mumia.w.18.spam/docs/test-binary.txt
Despite appearances in the browser window, the file is utf8.
------------------------------
Date: Fri, 15 Jan 2010 12:47:32 -0500
From: Ralph Malph <ralph.malph@altavista.com>
Subject: Re: some perl programs I wrote
Message-Id: <hiq9nn$c9s$1@speranza.aioe.org>
Jens Thoms Toerring wrote:
> Robin <robin1@cnsp.com> wrote:
>> check out some of my perl programs,
>> http://offlame.memebot.com
>> let me know if you like them.... :-)
>
> I unfortunately have to agree with others here that didn't
> like your code - but I only looked at the program for gene-
> rating prime numbers and the "text editor" yet. And both are
> not winners... Here's the one for generating prime numbers:
>
> 1 #!/usr/bin/perl
> 2 use strict;
> 3 my $npflag = 0;
> 4 my $n;
> 5 my @z;
> 6 print "Prime number generator starting at 3 and going up....\n";
> 7
> 8 foreach my $q (4 .. 10000) {
> 9 $npflag = 0;
> 10 foreach my $m (1 .. $q) {
> 11 next if $m == 1;
> 12 next if $m == $q;
> 13 $_ = "$q" / "$m";
> 14 if ($_ !~ /\./) {
> 15 $npflag = 1;
> 16 }
> 17 }
> 18
> 19 if (! $npflag) {
> 20 print "We have found prime : $q\n";
> 21 sleep 1;
> 22 }
> 23 }
>
> Lets forget about the unused variables and that kind of stuff.
>
> a) What you print out in line 6 isn't correct, you start with 4,
> and not with 3 as you claim.
> b) Including even numbers in checks for primes is a strange idea,
> they are simple to avoid and are never prime (except 2;-)
> c) Starting with $m set to 1 in line 10 and then checking in
> line 11 that $m is not 1 is very strange, to say the least.
> d) The same holds for going up to $q and then checking that $m
> isn't $q.
> e) Going up to $q instead of it's square root shows that you
> should do a bit more research on prime numbers before you
> atart writing programs to find primes.
> f) The double quotes in line 13 indicate that you don't well
> understand really what they are used for in Perl.
> g) Using '$_' as a variable looks to me as bad as you can get.
> h) Using a regex to check if a number can be divided by another
> one is, to say the least, strange ("inefficent" doesn't cover
> it appropriately).
>
> And then, even if you remove the call to sleep(), it's slow as
> molasses. Take the following program, that does logically more
> or less the same as yours (using the same rather uneducated al-
> gorithm):
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> print "Prime number generator starting at 3 and going up....\n";
>
> NOT_A_PRIME:
> for ( my $q = 3; $q <= 10000; $q += 2 ) {
> for ( my $m = 3; $m <= sqrt( $q ); $m += 2 ) {
> next NOT_A_PRIME unless $q % $m;
> }
>
> print "We have found prime : $q\n";
> }
Why didn't you do this
for ( my $q = 3; $q <= 10000; $q += 2 ) {
my $limit = sqrt($q);
for ( my $m = 3; $m <= $limit; $m += 2 ) {
next NOT_A_PRIME unless $q % $m;
}
and you save 52187 unnecessary calls to sqrt in
this example alone!
Why haven't the group regulars derided you
for "horrible" coding practices?
The truth is the writing code is hard.
Falsely claiming yourself as an expert
is easy.
------------------------------
Date: Fri, 15 Jan 2010 10:11:15 -0800
From: sln@netherlands.com
Subject: Re: some perl programs I wrote
Message-Id: <ifb1l5hbka9bh8de0otv39iutttfbmgsku@4ax.com>
On Fri, 15 Jan 2010 12:47:32 -0500, Ralph Malph <ralph.malph@altavista.com> wrote:
>Jens Thoms Toerring wrote:
>> Robin <robin1@cnsp.com> wrote:
>>> check out some of my perl programs,
>>> http://offlame.memebot.com
>>> let me know if you like them.... :-)
>>
>> I unfortunately have to agree with others here that didn't
>> like your code - but I only looked at the program for gene-
>> rating prime numbers and the "text editor" yet. And both are
>> not winners... Here's the one for generating prime numbers:
>>
[snip]
>> Lets forget about the unused variables and that kind of stuff.
>>
[snip]
>> And then, even if you remove the call to sleep(), it's slow as
>> molasses. Take the following program, that does logically more
>> or less the same as yours (using the same rather uneducated al-
>> gorithm):
>>
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>>
>> print "Prime number generator starting at 3 and going up....\n";
>>
>> NOT_A_PRIME:
>> for ( my $q = 3; $q <= 10000; $q += 2 ) {
>> for ( my $m = 3; $m <= sqrt( $q ); $m += 2 ) {
>> next NOT_A_PRIME unless $q % $m;
>> }
>>
>> print "We have found prime : $q\n";
>> }
>Why didn't you do this
>
>for ( my $q = 3; $q <= 10000; $q += 2 ) {
> my $limit = sqrt($q);
> for ( my $m = 3; $m <= $limit; $m += 2 ) {
> next NOT_A_PRIME unless $q % $m;
> }
>
>and you save 52187 unnecessary calls to sqrt in
>this example alone!
[snip]
my ($q, $m,$limit);
for ( $q = 3; $q <= 10000; $q += 2 ) {
$limit = sqrt($q);
for ( $m = 3; $m <= $limit; $m += 2 ) {
next NOT_A_PRIME unless $q % $m;
}
and 52187 + 5000 unnecessary initializations.
-sln
------------------------------
Date: Fri, 15 Jan 2010 13:23:49 -0500
From: Ralph Malph <ralph.malph@altavista.com>
Subject: Re: some perl programs I wrote
Message-Id: <dbfcf$4b50b2b7$c650990a$30831@news.eurofeeds.com>
sln@netherlands.com wrote:
> my ($q, $m,$limit);
> for ( $q = 3; $q <= 10000; $q += 2 ) {
> $limit = sqrt($q);
> for ( $m = 3; $m <= $limit; $m += 2 ) {
> next NOT_A_PRIME unless $q % $m;
> }
>
> and 52187 + 5000 unnecessary initializations.
ha! nice catch.
------------------------------
Date: Fri, 15 Jan 2010 11:08:56 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: some perl programs I wrote
Message-Id: <8ve1l5tiedo8oa96ot7si2a94fep2rrske@4ax.com>
Ralph Malph <ralph.malph@altavista.com> wrote:
>Uri Guttman wrote:
>>>>>>> "R" == Robin <robin1@cnsp.com> writes:
>>
>> R> check out some of my perl programs,
>> R> http://offlame.memebot.com
>>
>> you have a lot of perl and programming to learn still.
>No, the OP needs to stop making some silly mistakes
>but he is clearly a quite capable programmer.
Sorry, but explicitly converting numbers into strings only to
immediately applying a numerical operation on those strings thus
converting them back into numbers is not a silly mistake but a very
major lack of understanding of basic fundamentals.
There would only one way to make it even worse: using this misguided
technique on floating point numbers.
jue
------------------------------
Date: Fri, 15 Jan 2010 13:46:33 -0800
From: Joseph Brenner <doom@kzsu.stanford.edu>
Subject: Re: sprintf '%.5s', 123456789
Message-Id: <87vdf3ca86.fsf@kzsu.stanford.edu>
Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
> On 2009-09-11, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>>>>> perl -wle "printf '%.5s', 123456789"
>>>>> 1.2e9
>
>>>> Since %s says to treat it like a string, how can it legitimately insert
>>>> irrelevant period and 'e' characters?
>
>>> "1.2e9" is "a string". So is "123456789". As far as "treating as a
>>> string" goes, what do you think is the EXACT MESSAGE of this phrase?
>>>
>>> [I trust that some C/POSIX standard would explicitly mention that
>>> %.[WIDTH]s shortens by "truncation on the right". I would be very
>>> much surprised if Perl docs mention the exact semantic of shortening,
>>> and/or relation to C or POSIX...]
>
>> Wow. Semantic truncation! Will you also do:
>
>> perl -wle "printf '%.3s', 'enormous'"
>> big
>
> Wow! I did not think of this! And, in fact, I like it very much...
>
> The only problem I envision is that of documentation.
The documentation would just be a couple of lines, including a reference
to the thesaurus db used to select synonyms.
I'm skeptical of the need to implement this in core, but if so I'd
suggest finding another formatting code besides "%s" to abuse.
I guess the other way to go would be to implement a pragma that changes
printf's behavior.
use smart_but_stupid_printf;
------------------------------
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 2771
***************************************
