[32950] in Perl-Users-Digest
Perl-Users Digest, Issue: 4226 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 30 14:09:16 2014
Date: Fri, 30 May 2014 11:09:05 -0700 (PDT)
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, 30 May 2014 Volume: 11 Number: 4226
Today's topics:
a remark on the mechanics of xenophobia <rweikusat@mobileactivedefense.com>
Re: a remark on the mechanics of xenophobia <rweikusat@mobileactivedefense.com>
Re: a remark on the mechanics of xenophobia <hjp-usenet3@hjp.at>
Re: a remark on the mechanics of xenophobia <johnblack@nospam.com>
Re: a remark on the mechanics of xenophobia <rweikusat@mobileactivedefense.com>
Re: a remark on the mechanics of xenophobia <tzz@lifelogs.com>
Re: a remark on the mechanics of xenophobia <rweikusat@mobileactivedefense.com>
Re: a remark on the mechanics of xenophobia <tzz@lifelogs.com>
Re: a remark on the mechanics of xenophobia <rweikusat@mobileactivedefense.com>
Re: a remark on the mechanics of xenophobia <tzz@lifelogs.com>
Re: a remark on the mechanics of xenophobia <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rm-dash-bau-haus@dash.futureapps.de>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: sorting file according to a unicode column <gravitalsun@hotmail.foo>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 28 May 2014 21:39:39 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: a remark on the mechanics of xenophobia
Message-Id: <871tvdd4dw.fsf@sable.mobileactivedefense.com>
I'm really using the wrong term in the subject but my greek is "not that
good" ('nonexistant' would describe more appropriately). The correct one
wouldn't be about being afraid of "stuff which seems different and
strange" (although that's a component of the other) but "reacting in a
strongly negative, emotional way to it" which precludes rational thought
and tends to end up doing objectively stupid things solely to achieve
outward conformance with what the affected persons regards as "the
proper and NORMAL way to do things".
Perl 5.20 has an experimental feature called 'function signatures'. This
means it will be possible to declare a subroutine with 'named,
positional arguments' a la
sub tote_hose($kaninchen, $fledermaus, $leberwurst)
{
}
Outwardly, this doesn't sound too bad, especially since it could help
with 'compile-time checking of subroutine calls' and thus help avoiding
run-time errors causing 'program crashes' which lurk on rarely used
codepaths, although it's not a feature to become seriously excited
about, either, since the existing system for passing arguments to
subroutines has been proven to work in practice for more than twenty
years.
This is celebrated by a web site named perltricks.com as follows:
Less ugly code
You can banish those unsightly variable assignments from your
subroutines. Say goodbye (and good riddance) to this:
sub ugly_code {
my ($arg1, $arg2, arg3) = @_;
...
}
And say hello to this:
sub fine_code ($arg1, $arg2, arg3){
...
}
The first thing to note here is that the author doesn't argue in favour
of his apparent opinion but tries to market it instead by sticking
suitable labels onto 'what he happens to like' and 'what he happens to
dislike'. And he isn't even being honest about that as he doesn't admit
that he's making purely aesthetic (and thus, totally subjective)
judgements but tries to pass them off as 'objective truths': The first
variant is not "code I consider to be ugly" but "ugly code" as if that
was a property like the colour of a car ("blue Ford"). The same is true
for the second.
An unprejudiced observer might feel inclined to wonder what all the fuss
is about: After all, what are the actual differences between the
variants labelled as 'ugly' and 'fine'
- 'fine' has a list on $-prefixed names between the subroutine
name and the opening brace
vs
- 'ugly': the same list appears one line below the name and
after the {
- further, 'ugly' has a 'my' in front of the list and a = @_
behind it
Since both forms are otherwise functionally identically, this doesn't
seem to be much of a difference.
BUT the 2nd form comes with some drawbacks: It doesn't really support
compile-time argument checking. Someone who wants this still has no
better option than using 'traditional prototypes' however, it does come
with mandatory run-time argument checking, ie, instead of doing
something productive, the first thing the second function will do is
inspect if it was passed the expected number of arguments and 'raise a
run-time exception' in case there a discrepancies. This is bad because
such checks are generally useless except in yet undebugged code: Most of
the time, a 'static call' which was compiled from the source code will
pass the correct number of arguments but this will be checked every time
despite the call will never change.
The people who came up with the 'fine/ ugly' classification also
benchmarked 'new style' and 'old style' subroutine calls and the result
was that 'function signature' calls happen with 71.43% - 63% of the
speed of traditional method. And this despite 'mandatory checking of the
number of arguments passed to the subroutine' was manually added to the
traditional call.
Conclusion: At the expense of more than a 30% speed penalty for
realistic cases, a bracketed expression containing a list of
dollar-prefixed names was moved into the location where languages with
real 'subroutine call checking' usually declare their subroutine
arguments. This also saves typing eight characters ('m', 'y', ' ', '
', '=', ' ', '@', '_') per applicable subroutine invocation but doesn't
provide anything except these two 'formatting changes' (more insanity,
like 'run-time type checking of subroutine arguments' planned for the
future.
But it looks "fine", now, that is "like other stuff I'm used to".
------------------------------
Date: Wed, 28 May 2014 21:52:25 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <87sintbp86.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[5.20 function signatures]
> Conclusion: At the expense of more than a 30% speed penalty for
> realistic cases, a bracketed expression containing a list of
> dollar-prefixed names was moved into the location where languages with
> real 'subroutine call checking' usually declare their subroutine
> arguments. This also saves typing eight characters ('m', 'y', ' ', '
> ', '=', ' ', '@', '_') per applicable subroutine invocation but doesn't
> provide anything except these two 'formatting changes' (more insanity,
> like 'run-time type checking of subroutine arguments' planned for the
> future.
>
> But it looks "fine", now, that is "like other stuff I'm used to".
Addition: Should Perl ever gain support for real 'formal parameter
list', that is, not just 'moving text around by making the runtime
system more complicated', I'd very much welcome that as the existing
facilities for validating subroutines at compilation time leave very
much to be desired.
------------------------------
Date: Thu, 29 May 2014 08:47:55 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <slrnlodm0r.e5d.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-28 20:39, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> Perl 5.20 has an experimental feature called 'function signatures'. This
> means it will be possible to declare a subroutine with 'named,
> positional arguments' a la
>
> sub tote_hose($kaninchen, $fledermaus, $leberwurst)
> {
> }
[...]
> This is celebrated by a web site named perltricks.com as follows:
>
> Less ugly code
>
> You can banish those unsightly variable assignments from your
> subroutines. Say goodbye (and good riddance) to this:
>
> sub ugly_code {
> my ($arg1, $arg2, arg3) = @_;
> ...
> }
>
> And say hello to this:
>
> sub fine_code ($arg1, $arg2, arg3){
> ...
> }
>
> The first thing to note here is that the author doesn't argue in favour
> of his apparent opinion but tries to market it instead by sticking
> suitable labels onto 'what he happens to like' and 'what he happens to
> dislike'. And he isn't even being honest about that as he doesn't admit
> that he's making purely aesthetic (and thus, totally subjective)
> judgements but tries to pass them off as 'objective truths': The first
> variant is not "code I consider to be ugly" but "ugly code" as if that
> was a property like the colour of a car ("blue Ford"). The same is true
> for the second.
Well, yes. Beauty is in the eye of the beholder[1] (color, too,
actually). Explicitely stating that the categorization of something as
"ugly" is subjective would be completely redundant. You'r building
straw man here.
> An unprejudiced observer might feel inclined to wonder what all the fuss
> is about: After all, what are the actual differences between the
> variants labelled as 'ugly' and 'fine'
>
> - 'fine' has a list on $-prefixed names between the subroutine
> name and the opening brace
>
> vs
>
> - 'ugly': the same list appears one line below the name and
> after the {
>
> - further, 'ugly' has a 'my' in front of the list and a = @_
> behind it
>
> Since both forms are otherwise functionally identically, this doesn't
> seem to be much of a difference.
You might stop to consider why the second form became an idiom. There
are alternatives:
* you could use @_ directly.
* you could use shift to assign to local variables:
my $arg1 = shift;
my $arg2 = shift;
my $arg3 = shift;
* ...
These are also in use (and PBP even recommends the shift form in some
cases), but the list assignment at the start of the sub is very common,
probably the most common form.
I think this is because it mimics the conventional form (I am sticking
to that word, whether you like it or not) of a parameter list most
closely.
I will also note that after 19 years of Perl programming my fingers
still aren't quite used to it. Every now and then I find that I've typed
something like
sub whatever {
my ($arg1, $arg2, $arg3) {
...
(I think it would actually be worthwhile to investigate what typos
programmers make. While quite a lot of work goes into preventing that
kind of errors (language design, syntax highlighting, autocompletion,
...) it all seems to be based on handwaving and anecdotal evidence.)
> BUT the 2nd form comes with some drawbacks: It doesn't really support
> compile-time argument checking. Someone who wants this still has no
> better option than using 'traditional prototypes' however, it does come
> with mandatory run-time argument checking, ie, instead of doing
> something productive, the first thing the second function will do is
> inspect if it was passed the expected number of arguments and 'raise a
> run-time exception' in case there a discrepancies. This is bad because
> such checks are generally useless except in yet undebugged code: Most of
> the time, a 'static call' which was compiled from the source code will
> pass the correct number of arguments but this will be checked every time
> despite the call will never change.
It will also be checked every time with the new function signatures. At
least that's how I understood the blog posts (haven't looked at the code
yet) and it makes sense given that you cannot generally depend on a sub
being defined when the code that calls it is compiled.
> The people who came up with the 'fine/ ugly' classification also
> benchmarked 'new style' and 'old style' subroutine calls and the result
> was that 'function signature' calls happen with 71.43% - 63% of the
> speed of traditional method. And this despite 'mandatory checking of the
> number of arguments passed to the subroutine' was manually added to the
> traditional call.
Are you referring to
http://perltricks.com/article/88/2014/5/12/Benchmarking-subroutine-signatures?
I see 73% there (and 82%, but that benchmark is flawed).
I am puzzled why it is slower. It does the same operations as the
equivalent perl code, but it does them in compiled C code, so it should
be faster.
hp
[1] When ESR for the first time saw the Karlskirche[2] in Vienna, he
exclaimed "That's one ugly mother!"
[2] http://en.wikipedia.org/wiki/Karlskirche
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 29 May 2014 10:51:09 -0500
From: John Black <johnblack@nospam.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <MPG.2df11368986934539897d1@news.eternal-september.org>
In article <871tvdd4dw.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
says...
> sub fine_code ($arg1, $arg2, arg3){
> ...
> }
I like it. Yes, for purely aesthetic reasons. I assume the old way will still be available
to those who prefer that way so what is the harm of allowing this new method that a lot of
people might prefer? I don't buy that there will be a big performance hit for this. If
there is right now, its probably because the new code is not yet optimized. I would be very
surprised if there ends up being a noticable performance difference between the two forms.
John Black
------------------------------
Date: Thu, 29 May 2014 17:04:20 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <871tvca7wb.fsf@sable.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-05-28 20:39, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> Perl 5.20 has an experimental feature called 'function signatures'. This
>> means it will be possible to declare a subroutine with 'named,
>> positional arguments' a la
>>
>> sub tote_hose($kaninchen, $fledermaus, $leberwurst)
>> {
>> }
> [...]
>> This is celebrated by a web site named perltricks.com as follows:
>>
>> Less ugly code
>>
>> You can banish those unsightly variable assignments from your
>> subroutines. Say goodbye (and good riddance) to this:
>>
>> sub ugly_code {
>> my ($arg1, $arg2, arg3) = @_;
>> ...
>> }
>>
>> And say hello to this:
>>
>> sub fine_code ($arg1, $arg2, arg3){
>> ...
>> }
>>
>> The first thing to note here is that the author doesn't argue in favour
>> of his apparent opinion but tries to market it instead by sticking
>> suitable labels onto 'what he happens to like' and 'what he happens to
>> dislike'. And he isn't even being honest about that as he doesn't admit
>> that he's making purely aesthetic (and thus, totally subjective)
>> judgements but tries to pass them off as 'objective truths': The first
>> variant is not "code I consider to be ugly" but "ugly code" as if that
>> was a property like the colour of a car ("blue Ford"). The same is true
>> for the second.
>
> Well, yes. Beauty is in the eye of the beholder[1] (color, too,
> actually).
Yes. To a degree, 'objectivity' is a disputable concept in itself
because humans have no way to learn anything about their surroundings
except via their senses and nobody can 'independently' verify that 'his'
senses actually convey accurate information, aka
1. Nothing exists.
2. Even if something existed, nothing could be known about it.
3. Even if something could be known about it, knowledge about it
couldn't be communicated to others.
http://en.wikipedia.org/wiki/Solipsism
Regardless of that, 'blue' is a discernible property with a definition
which is at least sort-of independent of the person using the term,
thus, labeling a car as 'blue' does not just try to pass off a totally
subjective assessement as objective property ...
> Explicitely stating that the categorization of something as
> "ugly" is subjective would be completely redundant. You'r building
> straw man here.
... while labeling something as 'ugly' does. This is, by the way, one of
the fundamental 'functional concepts' behind 'marketing', namely,
associate a term with an intended conotation with something unrelated
supposed to be affected by 'marketing'. Ideally, someone should take
note of the association subconsciously and then reproduce it from memory
without realizing that it wasn't an original thought of him the next
time he ecounters the 'other part' of the association, eg,
sub betonmelone {
my ($kate, $moss) = @_
}
should trigger an "This is ugly!" emotional reaction.
That's something different from stating 'I think this is an unfortunate
construct because it is easy to forget the trailing = @_ and because the
leading my ought to be redundant: It should just pass arguments "by
value" unconditionally, because thats ....' (and the argument peters out
here because 'passing everything by value' is again just one of several,
cultural conventions and specifically, NOT what Perl usually does: By
default, it passes everything by reference[*]).
[*] Coincidentally or maybe not coincidentally, 'function signatures'
seem to make Perl 'behave like Java' in this respect (pass everything by
value except objects), just in a technically inferior way, and I'm not
keen on Perl acting as 'technically inferior clone of Java' (I don't
believe the 'technically inferior' is intentional, I rather consider
that a side effect the people who are rubbed the wrong way by "different
than Java" don't really understand).
>
>> An unprejudiced observer might feel inclined to wonder what all the fuss
>> is about: After all, what are the actual differences between the
>> variants labelled as 'ugly' and 'fine'
>>
>> - 'fine' has a list on $-prefixed names between the subroutine
>> name and the opening brace
>>
>> vs
>>
>> - 'ugly': the same list appears one line below the name and
>> after the {
>>
>> - further, 'ugly' has a 'my' in front of the list and a = @_
>> behind it
>>
>> Since both forms are otherwise functionally identically, this doesn't
>> seem to be much of a difference.
>
> You might stop to consider why the second form became an idiom.
> There are alternatives:
>
> * you could use @_ directly.
> * you could use shift to assign to local variables:
> my $arg1 = shift;
> my $arg2 = shift;
> my $arg3 = shift;
> * ...
My take on that would be: Because 'Perl does not have named formal
parameters. In practice all you do is assign to a "my()" list of
these.' is said very close to the beginning of the 'perlsub' manpage. I
surely started every Perl subroutine I wrote like this for a long time
because it was closest to what I happened to be used to from other
languages I learnt earlier. This has grown less over time as I came to a
better understanding of the conventional Perl way of passing arguments
to subroutines (no matter if you like that or not, a plurality of
different approaches exists here and have co-existed for a long time and
they all have something for them and something against them --- there
isn't the one "Right Way Of Doing It"[tm] and the n 'Wrong Ways'[tm])
and the opportunities it provides.
[...]
>> BUT the 2nd form comes with some drawbacks: It doesn't really support
>> compile-time argument checking. Someone who wants this still has no
>> better option than using 'traditional prototypes' however, it does come
>> with mandatory run-time argument checking, ie, instead of doing
>> something productive, the first thing the second function will do is
>> inspect if it was passed the expected number of arguments and 'raise a
>> run-time exception' in case there a discrepancies. This is bad because
>> such checks are generally useless except in yet undebugged code: Most of
>> the time, a 'static call' which was compiled from the source code will
>> pass the correct number of arguments but this will be checked every time
>> despite the call will never change.
>
> It will also be checked every time with the new function signatures. At
> least that's how I understood the blog posts (haven't looked at the code
> yet) and it makes sense given that you cannot generally depend on a sub
> being defined when the code that calls it is compiled.
I was referring to 'new function signatures': If these came without
someone's idea of 'indispensable self-defense against the dark warts'
(aka "this is large, open-source project and the next moron who abuses
my code and points a finger at me if that doesn't work is only half a
commit away") bolted on, I'd probably consider them a welcome
addition. But code I write is supposed to run in rather controlled
circumstances with 'the program' considered a boundary of trust: Whatever
flows into a program from the outside is verified. Internal
disagreements regarding how to call subroutines are bugs which are
supposed to be fixed.
>> The people who came up with the 'fine/ ugly' classification also
>> benchmarked 'new style' and 'old style' subroutine calls and the result
>> was that 'function signature' calls happen with 71.43% - 63% of the
>> speed of traditional method. And this despite 'mandatory checking of the
>> number of arguments passed to the subroutine' was manually added to the
>> traditional call.
>
> Are you referring to
> http://perltricks.com/article/88/2014/5/12/Benchmarking-subroutine-signatures?
>
> I see 73% there (and 82%, but that benchmark is flawed).
I tried my best to come up with some 'reasonable numbers' based on the
included graphic.
[...]
> [1] When ESR for the first time saw the Karlskirche[2] in Vienna, he
> exclaimed "That's one ugly mother!"
>
> [2] http://en.wikipedia.org/wiki/Karlskirche
"Barock ist Geschmacksache" ...
------------------------------
Date: Thu, 29 May 2014 12:25:13 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <87zji0363a.fsf@lifelogs.com>
On Wed, 28 May 2014 21:39:39 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> This also saves typing eight characters ('m', 'y', ' ', ' ', '=', '
RW> ', '@', '_') per applicable subroutine invocation
I applaud your initiative to count the characters saved individually!
The developers didn't expect that level of scrutiny, did they?
Ted
------------------------------
Date: Thu, 29 May 2014 17:48:07 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <87wqd48raw.fsf@sable.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 28 May 2014 21:39:39 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> RW> This also saves typing eight characters ('m', 'y', ' ', ' ', '=', '
> RW> ', '@', '_') per applicable subroutine invocation
>
> I applaud your initiative to count the characters saved individually!
> The developers didn't expect that level of scrutiny, did they?
This is partially based on an earlier Modern Perl' blog entry which
actually referred to the 'assignment to a list of my variables' as
'manual unpacking of arguments' -- the 'bulk' of both constructs
consists of a list of variable names, that is, they're rather similar
than different, especially considering that the semantics of both are
identical:
sub lost_sausage($flour, $meat, $salt) {
}
and
sub lost_sausage {
my ($flour, $meat, $salt) = @_;
}
have most parts in common. The latter has some 'ancilliary characters'
which are required because the purely-positional, pass-by-reference
mechanism is more flexlible than the other: It can do some things the
other can't. The usual downside of that is 'using it requires more
work'.
OTOH, I completely agree that "But can't you see the emperor is still
naked!" is probably not the reaction the people who waste their (paid?)
time on inventing stuff like this (must be lucky lot) wanted to entice.
------------------------------
Date: Thu, 29 May 2014 16:15:02 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <87sins2vg9.fsf@lifelogs.com>
On Thu, 29 May 2014 17:04:20 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> thus, labeling a car as 'blue' does not just try to pass off a totally
RW> subjective assessement as objective property ...
Well, if the car *told* you it was feeling blue, that's OK by me.
Maybe its Blue Book value blew, or it had a Blue Screen of Death.
Or maybe it got a blue ribbon at the fair because it was so self-azured.
Ted
------------------------------
Date: Thu, 29 May 2014 22:20:49 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <87sins8eoe.fsf@sable.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 29 May 2014 17:04:20 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> thus, labeling a car as 'blue' does not just try to pass off a totally
> RW> subjective assessement as objective property ...
>
> Well, if the car *told* you it was feeling blue, that's OK by me.
> Maybe its Blue Book value blew, or it had a Blue Screen of Death.
>
> Or maybe it got a blue ribbon at the fair because it was so
> self-azured.
Blue is the colour of the clear sky and the deep sea.[2] On the optical
spectrum, blue is located between violet and green.[3]
[...]
Spectral coordinates
Wavelength 450¡V495 nm
Frequency ~670¡V610 THz
Hex triplet #0000FF
sRGBB(r, g, b) (0, 0, 255)
HSV(h, s, v) (240¢X, 100%, 100%)
http://en.wikipedia.org/wiki/Blue
A nagging suspicion I can't really get over is that - in discussions
like these - the quality of the 'arguments' brought forth in favour of
the subject matter or, more correctly, the nonsensicalness of the
nonsense supposed to be used to bury the discussion, has some relation
to the inherent quality of the subject matter, ie, "everyone is talking
out of his ass because he is well aware that the disputed idea is
stupid".
------------------------------
Date: Thu, 29 May 2014 19:33:44 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <87oayg2m93.fsf@lifelogs.com>
On Thu, 29 May 2014 22:20:49 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> http://en.wikipedia.org/wiki/Blue
You've clearly done your research.
RW> A nagging suspicion I can't really get over is that - in discussions
RW> like these - the quality of the 'arguments' brought forth in favour of
RW> the subject matter or, more correctly, the nonsensicalness of the
RW> nonsense supposed to be used to bury the discussion, has some relation
RW> to the inherent quality of the subject matter, ie, "everyone is talking
RW> out of his ass because he is well aware that the disputed idea is
RW> stupid".
Bastards.
Ted
------------------------------
Date: Fri, 30 May 2014 01:38:24 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: a remark on the mechanics of xenophobia
Message-Id: <874n0885j3.fsf@sable.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 29 May 2014 22:20:49 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> http://en.wikipedia.org/wiki/Blue
>
> You've clearly done your research.
Make that your research.
ATM, 'function signatures' (and this should really be subroutine
signatures) is a cosmetic change which doesn't really offer anything
that didn't already exist. But it comes with some real drawbacks. That's
a pity because it could have extended Perl in some areas where it is
actually deficient (compile-time argument checking, at least where
possible) and it could even have provided a more convenient way of
passing named arguments by value (marginal improvements are still
improvements). But not for as long as 'subroutines fighting each other'
(while we continue to accept everything coming from the network at face
value) remains the default mode of operation.
OTOH, I don't really expect to see 'Perl 5.20' anywhere within the next
decade and even if this should turn out to be wrong, the idiosyncrasies
of someone's preferred system are still just ideosyncrasied and only
wrongly referred to as features.
------------------------------
Date: Fri, 30 May 2014 18:23:17 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <5388b075$0$6613$9b4e6d93@newsspool4.arcor-online.net>
On 28.05.14 19:57, Rainer Weikusat wrote:
> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>> On 27.05.14 19:00, Rainer Weikusat wrote:
>>> beyond
>>> everything one can reasonably expect from mere humans,
>>
>> Which is another way of slipping the claim in: that some
>> expectations are reasonable. I'm trying to point out that
>> "reasonable" cannot just refer to a subjective view,
>> or to some select group of Perl savvy programmers
>> whenever software is part of the work of average programmers.
>> Solving language puzzles is above average.
>
> As a more reasoned reply: I'm sorry but I'm completely unable to find
> any coherent content in this paragraph,
OK, maybe I can help, though I doubt that an exclusive
mind is willing to take programming expressions as potentially
subordinate to the requirements of, for example, team programming,
the team consisting of lesser programmers.
> let alone coherent relevant
> content: Your subjective view is that objectively elementary features of the Perl
> programming language qualify as 'puzzles',
And again ... I'm pointing to evidence of "elementary" features
of Perl being puzzling. Not puzzling you, but others, obviously.
> whatever that is supposed to
> mean precisely,
"Puzzling" means that something is not understood even after
some thinking. A symptom is a corresponding question. If many
have the question, then IMHO this warrants qualifying a Perl
feature as puzzling.
In presence of such questions, the "elementary" features of Perl
are, then, not elementary, provided the questions are not just
asked by absolute beginners.
(elementary: "easily dealt with; straightforward and uncomplicated",
also
http://www.oxforddictionaries.com/definition/english/elementary?q=elementary
)
> and that they're thus beyond the abilities of some
> fictional group of people defined as being 'average' by virtue of surely
> becoming very puzzled in face of something you'd like to call a puzzle
> and ... then nothing.
What if a certain combination of syntactic features of Perl is
beyond the ability of a programmer .IFF. the programmer cannot
parse correctly a line exhibiting the feature, in under 60 seconds?
Now take n programmers and ask them (or observe their questions).
Would that be a starting point for actually measuring which Perl
features are and which ones aren't elementary? I think so, and
I am sure everyone working in support knows such questions.
> [...]
>
>> All very good for consulting, though.
>
> Considering the context, this is not only ridiculous but also abusive in
> a very irrational way: What you believe about other people's 'nasty
> hidden motives' communicates something about you, not about anyone else.
I don't care what the motives are. I know the feature from
taking either (economical) side. Whenever I am a "consumer" of
needlessly complex code, I still need to parse it. Sometimes that's
entertaining, but I'm not being payed for doing Perl style "recreational
math".
If we didn't have complexity, some jobs would be gone. Some complexity
is no doubt necessary, technically, while other kinds of complexity
are rarely needed, technically, such as some of the Perl statement
forms that were discussed in this thread. Personally, I find this
a little sad, because those 1-liners allow differentiating kinds
of control structure: not every decision looks like an if {}.
Another proof that complex (to parse) expressions are seen as
a good tool of doing business is the use of today's Javascript
compilers:
"Closing" the source, a *hugely* popular feature is that shortening
also makes reading still "open" source code a complex task. But the
output of these Javascript compilers looks very much like the
1-liners discussed in this thread!
------------------------------
Date: Fri, 30 May 2014 17:46:55 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87zjhzb4e8.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 28.05.14 19:57, Rainer Weikusat wrote:
>> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>>> On 27.05.14 19:00, Rainer Weikusat wrote:
>>>> beyond
>>>> everything one can reasonably expect from mere humans,
>>>
>>> Which is another way of slipping the claim in: that some
>>> expectations are reasonable. I'm trying to point out that
>>> "reasonable" cannot just refer to a subjective view,
>>> or to some select group of Perl savvy programmers
>>> whenever software is part of the work of average programmers.
>>> Solving language puzzles is above average.
>>
>> As a more reasoned reply: I'm sorry but I'm completely unable to find
>> any coherent content in this paragraph,
>
> OK, maybe I can help, though I doubt that an exclusive
> mind is willing to take programming expressions as potentially
> subordinate to the requirements of, for example, team programming,
> the team consisting of lesser programmers.
Another elementary requirement for being able to work in a team, not
only of 'programmers' but any kind of team, is to be willing to stop
throwing insults at people for the joy of doing so. And this is
something you are quite apparently totally incapable of.
------------------------------
Date: Fri, 30 May 2014 17:54:55 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87tx87b40w.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 28.05.14 19:57, Rainer Weikusat wrote:
>> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>>> On 27.05.14 19:00, Rainer Weikusat wrote:
>>>> beyond
>>>> everything one can reasonably expect from mere humans,
>>>
>>> Which is another way of slipping the claim in: that some
>>> expectations are reasonable. I'm trying to point out that
>>> "reasonable" cannot just refer to a subjective view,
>>> or to some select group of Perl savvy programmers
>>> whenever software is part of the work of average programmers.
>>> Solving language puzzles is above average.
>>
>> As a more reasoned reply: I'm sorry but I'm completely unable to find
>> any coherent content in this paragraph,
>
> OK, maybe I can help, though I doubt that an exclusive
> mind is willing to take programming expressions as potentially
> subordinate to the requirements of, for example, team programming,
> the team consisting of lesser programmers.
That's another not-so-subtle insult (Lightly worded. It could also be
regarded as covert threat).
>> let alone coherent relevant
>> content: Your subjective view is that objectively elementary features of the Perl
>> programming language qualify as 'puzzles',
>
> And again ... I'm pointing to evidence of "elementary" features
> of Perl being puzzling. Not puzzling you, but others, obviously.
That's another assertion that elementary features of Perl (regarded as
'elementary' because they're described on the first two pages of the
relevant manpage) are surely "puzzling".
>> whatever that is supposed to
>> mean precisely,
>
> "Puzzling" means that something is not understood even after
> some thinking. A symptom is a corresponding question. If many
> have the question, then IMHO this warrants qualifying a Perl
> feature as puzzling.
>
> In presence of such questions, the "elementary" features of Perl
> are, then, not elementary, provided the questions are not just
> asked by absolute beginners.
> (elementary: "easily dealt with; straightforward and uncomplicated",
> also
> http://www.oxforddictionaries.com/definition/english/elementary?q=elementary
> )
That's a pointless tangent.
>> and that they're thus beyond the abilities of some
>> fictional group of people defined as being 'average' by virtue of surely
>> becoming very puzzled in face of something you'd like to call a puzzle
>> and ... then nothing.
>
> What if a certain combination of syntactic features of Perl is
> beyond the ability of a programmer .IFF. the programmer cannot
> parse correctly a line exhibiting the feature, in under 60 seconds?
That's a rethorical question without any substance behind it.
[...]
>> [...]
>>
>>> All very good for consulting, though.
>>
>> Considering the context, this is not only ridiculous but also abusive in
>> a very irrational way: What you believe about other people's 'nasty
>> hidden motives' communicates something about you, not about anyone else.
>
> I don't care what the motives are.
Considering that you keep posting conjectures about them, this is
obviously a lie.
Since you just keep repeating yourself, this discussion is obviously
useless.
"Guten Tag".
------------------------------
Date: Wed, 28 May 2014 21:46:01 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: sorting file according to a unicode column
Message-Id: <lm5atb$1mnp$1@news.ntua.gr>
# just works
my @lines;
while (<DATA>) {chomp; push @lines, [split /\|/, $_,-1]}
foreach(sort { $a->[9] cmp $b->[9] } @lines) {print "@{$_}\n"}
__DATA__
||||||||one|γ|3
||||||||two|α|2
||||||||six|β|1
------------------------------
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 4226
***************************************
