Re: Current Issues with perlipc.pod - should they be fixed?
On 5 December 2010 07:54, Naveed Massjouni navee...@gmail.com wrote: This thread is really depressing. Personally, I like all of Shlomi's suggestions. I can't fathom why bareword global filehandles are still pervasive in the perl docs. But instead of the community getting to discuss the merits of the changes and then have some kind of vote, one maintainer with a big ego can just say, VETO VETO VETO ... my docs are already perfect! I think there is a difference in modifying someone elses documentation, and writing a totally new doc. I also think there is a big difference between patches to code which fix bugs or add functionality, and patches to documentation that is not actually wrong, but instead of a style no longer in fashion. To me it is a bit like suggesting that Shakespeare needs to be modernized because of the archaic English he used. However, if you, or Shlomi think you can write a better perlipc.pod from scratch, then you should do so, or any other doc. If we think it is qualitatively superior then we would probably replace the existing version. More likely we would end up with two docs. And the community would be richer for it. So I think we are right in respecting a given documents artistic rights to have their vision presented as they wished, within reason. We can always decide not to use the doc at all if we feel they are being unreasonable. I doubt you would get a consensus for such an extreme action amongst the committers though. I think we generally dont feel as strongly about these changes as you seem to. Although I respect your reasons for doing so. Is that how things work in the perl community? Sometimes yes. We have a long tradition of accepting there is a role for a benevolent dictator in our community, as without one, we all too easily descend into long tedius arguments that get us nowhere. Like this one has verged upon. (I think Abigails suggested example caveat is a productive step that means we have not /quite/ verged into the total waste of time category.) What incentive would I or Shlomi or anyone else have to spend their time to try to improve the docs if this is how things work. We all have different incentives. I would hope that you dont feel that a predicate on your contributing is the right to change anything you wish however you wish. That is not how it works. No matter how much I wish it did sometimes. I hope you stay positive about contributing to perl, and find other subjects where you can do so. We have a lot more to look into than Tom's docs. cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Current Issues with perlipc.pod - should they be fixed?
On Mon, Dec 06, 2010 at 07:34:35PM +0200, Shlomi Fish wrote: Now I think that some of my style/best-practices suggestions are an improvement and I'd like to pursue them. And I'm strongly against that sentiment. I really do think p5p, and hence the documentation, should *not* have a style preference, or have some form of best practice (nor do I believe you'll find consensus on what best practice will be). Style guides, coding standards, best practices, or whatever you want to label it only gives rise to coding police, and it's only fuel to people who only answer questions on usenet or Perlmonks with well, for starters following these as these rules, regardless whether that helps answering the question or not. Pursue all you want. Just expect feedback which may not agree with you. Abigail
Re: Current Issues with perlipc.pod - should they be fixed?
The way I see it what happened was that I wrote an email with aspects of perlipc.pod that I found lacking, and not idiomatic up to recent best practices, thcrist replying that he doesn't like any of the changes and VETOing them (without saying why the status quo was better, just by giving other irrelevant reasons), Both of those are falsely stated. First, your notion of irrelevance is mere opinion. Second, I had previously explained my reasoning in full, and so saw no need of pasting the same redundant explanation at each point as some aide-mémoire for those of short attention spans. I also think that the Perl 5 documentation *should* reflect the agreed best practices (and I don't necessarily mean Damian's PBP). You bend that word agreed into something it does not mean. When--and only when--you've worked your way down this list far enough that you've finally reached my stuff, do give me a holler. # 1 STRICT 0% success 368 runs = 0 passed + 368 failed pod/perlapi.pod # 2 Warnings 7% success 368 runs = 24 passed + 344 failed pod/perlapi.pod # 3 STRICT33% success 275 runs = 90 passed + 185 failed pod/perlfunc.pod # 4 STRICT18% success 200 runs = 37 passed + 163 failed pod/perlfaq4.pod # 5 Warnings 49% success 275 runs = 136 passed + 139 failed pod/perlfunc.pod # 6 STRICT12% success 148 runs = 18 passed + 130 failed dist/Math-BigInt/lib/Math/BigInt.pm # 7 STRICT12% success 148 runs = 18 passed + 130 failed lib/Math/BigInt.pm # 8 Warnings 36% success 200 runs = 72 passed + 128 failed pod/perlfaq4.pod # 9 STRICT29% success 150 runs = 44 passed + 106 failed cpan/CGI/lib/CGI.pm # 10 STRICT29% success 150 runs = 44 passed + 106 failed lib/CGI.pm # 11 Warnings 29% success 148 runs = 43 passed + 105 failed dist/Math-BigInt/lib/Math/BigInt.pm # 12 Warnings 29% success 148 runs = 43 passed + 105 failed lib/Math/BigInt.pm # 13 STRICT 3% success 98 runs = 3 passed + 95 failed pod/perlguts.pod # 14 Warnings 4% success 98 runs = 4 passed + 94 failed pod/perlguts.pod # 15 STRICT35% success 141 runs = 49 passed + 92 failed pod/perlretut.pod # 16 Warnings 42% success 150 runs = 63 passed + 87 failed cpan/CGI/lib/CGI.pm # 17 Warnings 42% success 150 runs = 63 passed + 87 failed lib/CGI.pm # 18 STRICT37% success 126 runs = 47 passed + 79 failed pod/perlop.pod # 19 normal79% success 368 runs = 290 passed + 78 failed pod/perlapi.pod # 20 STRICT 4% success 80 runs = 3 passed + 77 failed pod/perlxs.pod # 21 STRICT24% success 99 runs = 24 passed + 75 failed pod/perlfaq5.pod # 22 Warnings 8% success 80 runs = 6 passed + 74 failed pod/perlxs.pod # 23 STRICT 8% success 78 runs = 6 passed + 72 failed ext/POSIX/lib/POSIX.pod # 24 STRICT 8% success 78 runs = 6 passed + 72 failed lib/POSIX.pod # 25 STRICT 5% success 75 runs = 4 passed + 71 failed cpan/Test-Simple/lib/Test/Builder.pm # 26 STRICT 5% success 75 runs = 4 passed + 71 failed lib/Test/Builder.pm # 27 STRICT16% success 83 runs = 13 passed + 70 failed pod/perltrap.pod # 28 Warnings 11% success 75 runs = 8 passed + 67 failed cpan/Test-Simple/lib/Test/Builder.pm # 29 Warnings 11% success 75 runs = 8 passed + 67 failed lib/Test/Builder.pm # 30 Warnings 14% success 78 runs = 11 passed + 67 failed ext/POSIX/lib/POSIX.pod # 31 Warnings 14% success 78 runs = 11 passed + 67 failed lib/POSIX.pod # 32 STRICT 0% success 65 runs = 0 passed + 65 failed cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm # 33 STRICT 0% success 65 runs = 0 passed + 65 failed lib/ExtUtils/MM_Any.pm # 34 Warnings 2% success 65 runs = 1 passed + 64 failed cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm # 35 Warnings 2% success 65 runs = 1 passed + 64 failed lib/ExtUtils/MM_Any.pm # 36 normal21% success 80 runs = 17 passed + 63 failed pod/perlxs.pod # 37 STRICT18% success 76 runs = 14 passed + 62 failed cpan/Test-Simple/lib/Test/More.pm # 38 STRICT18% success 76 runs = 14 passed + 62 failed lib/Test/More.pm # 39 Warnings 51% success 126 runs = 64 passed + 62 failed pod/perlop.pod # 40 STRICT21% success 76 runs = 16 passed + 60 failed pod/perlpacktut.pod # 41 STRICT15% success 68 runs = 10 passed + 58 failed pod/perldiag.pod # 42 Warnings 24% success 76 runs = 18 passed + 58 failed cpan/Test-Simple/lib/Test/More.pm # 43 Warnings 24% success 76 runs = 18 passed + 58 failed lib/Test/More.pm # 44 STRICT 0% success 56 runs = 0 passed + 56 failed cpan/Test-Harness/lib/TAP/Parser.pm # 45 STRICT 0% success 56 runs = 0 passed + 56 failed lib/TAP/Parser.pm # 46 STRICT17% success 66
Re: Current Issues with perlipc.pod - should they be fixed?
Yes, I'm depressed too. I'm depressed that people are telling me that I don't talk good no more. That there is something about my language that isn't safe for the precious children to hear. That there are things one isn't supposed to do--not that they're illegal or anything, just that they're adults-only topics. Deleting things from Perl that you've decided make you wrinkle your nose has always been a a *very* popular idea historically. It's also been fairly effective at killing off interest in helping develop Perl, because every new generation find that they disapprove of the one that came before them, so they'd like to hurry them off to the grave before anybody notices. If you want to remove something from the language, then bring it up with with on the discussion list as something you want do see killed in the language. But don't try to ram your idea of moral rectitude down the rest of our throats by these stealth edits of the documentation to better align with the Holy Scriptures of the Supreme Sacred Congregation of the Roman and Universal Inquisition. Surely driving away a few people who aren't family friendly is worth the vast strides of progress you promise to lead those of us who survive into. I think it's a stupidly harmful thing to do, and I think it is contrary to the spirit of Perl. But what do I know? I'm pretty sure only wrong-thinking people think like I do, and we must be pushed aside for the brave new world you seek to bring about. Go ahead, push a little: I don't mind jumping. It'd save me a lot of grief, and save you even more. The good of the many... --tom
Re: Current Issues with perlipc.pod - should they be fixed?
On Sun, Dec 5, 2010 at 9:54 AM, Tom Christiansen tchr...@perl.com wrote: Yes, I'm depressed too. I'm depressed that people are telling me that I don't talk good no more. I don't think anyone said any such thing, I sure don't think that. I can imagine it feels like that, since this discussion is about what many perceive to be wrong about those documents, not on what is good about them. Deleting things from Perl that you've decided make you wrinkle your nose has always been a a *very* popular idea historically. It's also been fairly effective at killing off interest in helping develop Perl, because every new generation find that they disapprove of the one that came before them, so they'd like to hurry them off to the grave before anybody notices. Not deleting anything can be just as effective at killing off interest in helping develop Perl. It's all about balance. Surely driving away a few people who aren't family friendly is worth the vast strides of progress you promise to lead those of us who survive into. Maybe they are driving you away, but you're driving other people away the same way. If I may speak for myself, I find this whole discussion extremely discouraging. If anything, this discussion is far more heated and far more dominated by emotion on all sides than it should be. Leon
Re: Current Issues with perlipc.pod - should they be fixed?
On Sun, Dec 05, 2010 at 01:54:29AM -0500, Naveed Massjouni wrote: This thread is really depressing. Personally, I like all of Shlomi's suggestions. I can't fathom why bareword global filehandles are still pervasive in the perl docs. But instead of the community getting to discuss the merits of the changes and then have some kind of vote, one maintainer with a big ego can just say, VETO VETO VETO ... my docs are already perfect! Is that how things work in the perl community? What incentive would I or Shlomi or anyone else have to spend their time to try to improve the docs if this is how things work. People are saying the perlipc docs are Unix centric, which they probably are. Adding some paragraphs and examples how to do IPC on VMS and Windows is probably a much better way to improve the documentation than insisting bare file handles aren't used, or claiming 'or' is somehow better than '||'. There's a lot of the documentation that can be improved; it's badly organized [*], things are hard to find [*], incorrectly documented [*], it's missing lots of examples, and it's probably too Unix centric [+]. I think we have a long way to go before the most constructive thing that can be done with documentation is twiddling with the coding style of examples. [*] If I ever have a couple of spare months, I want to rewrite the thingserlre documentation. [+] Probably strongly influenced by the fact the majority of perl and Perl documentation authors are native Unixians. Abigail
Re: Current Issues with perlipc.pod - should they be fixed?
I was simply showing which examples from perlfunc are wrong by the high and mighty approach. It is ridiculous to insist on mying them all. That was my point. --tom
Re: Current Issues with perlipc.pod - should they be fixed?
There *are* real problems in the documenation. But the fact that something is described as sin($x)/cos($x) without a my declaration, is *not* one of them. The biggest problem is that it is too hard to find the right information where you're looking for it, because it's scattered all over the place. Wide hex char, indeed! --tom
Re: Current Issues with perlipc.pod - should they be fixed?
On Fri, Dec 03, 2010 at 05:08:42PM -0800, chromatic wrote: On Friday 03 December 2010 at 16:53, Leon Timmermans wrote: We do, honestly. I'm tired of having to explain to newbies why the official perl documentation is not strict friendly, when I tell them they should use strict. **I don't know how to explain that to them**, it simply doesn't compute. You've had the But I copied and pasted it directly from the documentation, and now my program doesn't work anymore! discussion too? The point of the documentation isn't to supply a number of code fragments, so newbies can program by just cut-and-pasting. The examples are code *FRAGMENTS*. Some assembly required. We cannot guess what the scope of the variables in the code that's cut-and-pasted anyway. But I guess the general population is dumbing down in at an alarming rate. Cookbooks need detailed instructions, including pictures, on how to peel potatoes before boiling them, and newbies can only program by cut and pasting piecemeal chunks. Abigail
Re: Current Issues with perlipc.pod - should they be fixed?
On Sat, Dec 4, 2010 at 5:13 AM, Tom Christiansen tchr...@perl.com wrote: Then they just aren't smart enough to handle programming, I guess. What would be so stupid about that question? What would you reply if someone asked you that question? I have never ever had the least problem. I've taught many thousands of students, directly. I'm active in biology/bioinformatics, not software engineering or computer science: I work with people who often had only the most elementary classes in Perl, if that at all. My colleagues are not stupid, they just try to get their work done and use whatever tools at their disposal (in this case perl and its documentation) to assist them in that. I have never taught students directly, but I have had to indirectly teach them when working with them. Maybe they wouldn't have this problem if they had been properly taught, but that's a what-if scenario to me. I don't believe you. Are you suggesting I'm lying?? Other people's experiences being different is not an excuse for discounting them. Leon
Re: Current Issues with perlipc.pod - should they be fixed?
I don't believe you. Are you suggesting I'm lying?? No. I'm saying that I find it unbelievable. Perhaps you have a selective memory. Perhaps you are forgetting things, or remembering others. But yes, I mainly teach programmers programming. I don't have a great deal of success with nonprogrammers, because it's so hard to get then to get it. --tom
Re: Current Issues with perlipc.pod - should they be fixed?
On 4 December 2010 15:18, Abigail abig...@abigail.be wrote: On Fri, Dec 03, 2010 at 05:08:42PM -0800, chromatic wrote: On Friday 03 December 2010 at 16:53, Leon Timmermans wrote: We do, honestly. I'm tired of having to explain to newbies why the official perl documentation is not strict friendly, when I tell them they should use strict. **I don't know how to explain that to them**, it simply doesn't compute. You've had the But I copied and pasted it directly from the documentation, and now my program doesn't work anymore! discussion too? The point of the documentation isn't to supply a number of code fragments, so newbies can program by just cut-and-pasting. I consider that an incorrect assertion. It would be correct if you said The point of the documentation isn't JUST to supply a number of code fragments. I would argue that one of the points of the documents is to do exactly that. The documentation has other purposes, but one of them is to help beginners learn to program. I don't think there is any debate on that as I have seen quotes from Larry basically saying the entire language was designed to make it easy for beginners to be productive. It seems to me having a usable set of code fragments is part of that. The examples are code *FRAGMENTS*. Some assembly required. We cannot guess what the scope of the variables in the code that's cut-and-pasted anyway. Well, that is not entirely correct. Some /are/ full blown programs. And IMO as such should use some of what I would consider to be the less controversial aspects of newer style. I think maybe there is some dividing line between examples which are meant to be succinct and demonstrate only one particular thing, and larger examples which while intended to demonstrate some particular issue, or whatnot, should probably also be usable by beginners as building blocks, and be a *solid* foundation for building on - and to me, that DOES I am afraid mean a different style than Tom's. I'm thinking here in particular of global filehandles, and lexical scoped variables. I respect that Tom sees things differently, but I feel on these two at least that he is wrong. And the arguments I have seen from him in regard to justifying his position on these ones isn't to me very compelling. But I guess the general population is dumbing down in at an alarming rate. Whatever. :-) If one reads various literature of the past, well, as long as humans have been writing stuff down there is always someone bemoaning the dumbing down, the loss of tradition, the loss of manners or whatnot of the previous generation. I bet there is a cuneiform tablet out there in some deseret somewhere basically saying These upstart kids have no respect and no clue :-) Cookbooks need detailed instructions, including pictures, on how to peel potatoes before boiling them, That is more an indictment of the fast-food era than a question of dumbing down. If the only potato you ever saw in your life came out of a box, or presliced from the freezer newbies can only program by cut and pasting piecemeal chunks. I don't buy that. Lots and lots and lots of programmers, including well known ones, started off by typing example programs into their computers. I remember the first programs I wrote when I was a kid were direct copies from the manuals that came with the Pet computer. They amounted to small routines that made it look like a ball was bouncing around the screen. I then learned that I could combine them in interesting ways, and eventually wrote a game. I never would have gotten there if the code didnt work as printed in the manual. Later in my career I have learned several languages by cutting and pasting code snippets that I found from places to achieve the results I needed - I bet a LOT of people learn Javascript that way, and learning by trial and error. I am convinced that of the people on this list besides maybe yourself, that each one has learned at least one language this way. Makefiles anyone? HTML Markup maybe? SQL possible? Javascript? Maybe Python? Maybe even C. I think the examples, except when very short, or where it would clearly distract from the intent, *should* be building blocks intended for beginners to reuse. Everything we can do to expand the usage and audience of Perl is good for those of us who are professional Perl programmers - it means we will have a Job for a long time coming. Even if it is just repairing crappy code. :-) So just think of it this way, you just might be arguing against something that one day will make your job a lot easier... ;-) Lets not forget that the audience for these things may well be children, they may be professionals with no real programming knowledge, they may be people whose only knowledge of programming is Visual Basic for Applications. They wont just be graduated computer science professionals. cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Current Issues with perlipc.pod - should they be fixed?
On 4 December 2010 16:29, Tom Christiansen tchr...@perl.com wrote:
Yves wrote:
Well, that is not entirely correct. Some /are/ full blown programs.
*Those* I do try to always my() or our() or state() or sometimes
even local(), which is indeed appropriate in places:
use Carp qw :DEFAULT cluck ;
if (something_or_other) {
local $SIG{__WARN__} = sub { cluck untrapped warning explanation };
local $^W = 1;
call_something_else();
}
# local()s pop once that last closing brace is done
It's the isolated snippets like the zillion I last night pointed out in
perlfunc where I feel all the declaration detracts from the point.
If you believe that every possible example in Perl needs to be fully
declared, than by all means do so. But make sure you always start every
snippet with
#!/usr/bin/env perl -CLA
use 5.010;
use utf8;
use strict;
use autodie;
use warnings qwFATAL all;
use open qwIO :utf8 :std;
END { close STDOUT }
or whatever boilerplate is currently considered
de rigeur by all those trendy mODERN pERL people.
Can you truly argue that that would *help* everything?
I think we would both agree that that is way to much. And I
automatically assume code with use utf8 in it is subtly broken until
proved otherwise anyway. :-)
In fact I suspect over a pint we would probably mostly agree about
what is too much. :-)
* If so, what?
* If not, then what is all the fuss about?
Well, we are discussing the location of the sweet spot of balance
between the competing demands on our documentation. I was reacting to
what seemed to me to be an extreme positioning of that sweet spot.
But I guess the general population is dumbing down in at an
alarming rate.
Whatever. :-)
I'm with Abigail on this. I was taught not to assume one's
audience is full of idiots. That doesn't mean to be overly
clever, just not talk to down to them.
This is no longer Convention Wisdom. Now you must assume
that nobody has an iota of a clue.
It is a better default. You can always skip over and ignore things you
know, but its hard to find out about things you have no clue about.
While this may work for certain sorts of presentations, I
believe it is at most approprate only at the initial stage
of language acquisition.
But it seems now that we are expected to treat people like
babies their whole lives long.
Well thats the thing, you seem to be suggesting that we should treat
people as adults their whole lives long, which also doesn't make
sense.
Newbies aren't hardened veterans of the digital wars like you are. The
point being there are multiple audience for our documentation, we are
unlikely to make all of them happy at once. But again, its easier for
a veteran to ignore something that they know about than it is for a
newbie to find out about something that isn't explicitly noted.
Isn't that what the argument really is here?
It may have transformed into that, but personally if I wanted a
discussion like that Id bring up politics with my dad.
I think the real argument here is about how accessible the
documentation is to beginners, and what assumptions we make about the
audience for our documentation.
I feel like there is a certain contingent that holds Perl::Critic as
some sort of holy scripture, golden^Wclay tablets full of Biblical
injunctions that we must all slavishly follow if we are to be good
little perlians and see the good programming medal bestowed upon us.
Well I can assure that PBP is one of the best ways to get a
reactionary comment from me too. But I really dont feel that the docs
should use my vars, and use lexically scoped filehandles, insofar as
this does not distract from the core point being documented is
particularly Perl::Critic/PBP related. It is easy, as I think Shlomi
did to go way to far. For instance, *I* think its a good think that
*your* examples use '||' and not 'or' for exception handling. I think
that is useful. However, I dont think any particular advantage is
served by using global vars or global filehandles.
As you see, I disbelieve. Utterly.
Disbelieve what? :-) Oh. I see, you mean the Official Party Line.
Well, that is just because you have not been assimilated yet. But you
will be assimilated. Or maybe exterminated. Depends which tv show you
prefer. ;-)
In all seriousness, I really think the whole PBP/Perl::Critic thing
got way out of hand. Instead of being a sensible tool for looking for
potentially dangerous constructs, or recommendations that increase
code re-use and like, it turned into a sort of holy war.
For instance, I have formed a style that says that assignment should
be no-whitespace-on-left. I formed this style because I often work on
code that mixes SQL and Perl together, (although an early education in
Pascal probably also contributes), and this helps me to distinguish
between an sql = and a perl =, which do not have the same meaning.
So i would do this:
my $sql=
Re: Current Issues with perlipc.pod - should they be fixed?
It's the isolated snippets like the zillion I last night pointed out in
perlfunc where I feel all the declaration detracts from the point.
If you believe that every possible example in Perl needs to be fully
declared, than by all means do so. But make sure you always start every
snippet with
#!/usr/bin/env perl -CLA
use 5.010;
use utf8;
use strict;
use autodie;
use warnings qwFATAL all;
use open qwIO :utf8 :std;
I forgot to add the obligatory:
use sigtrap qw stack-trace normal-signals error-signals ;
END { close STDOUT }
or whatever boilerplate is currently considered
de rigeur by all those trendy mODERN pERL people.
Can you truly argue that that would *help* everything?
I think we would both agree that that is way to much. And I
automatically assume code with use utf8 in it is subtly
broken until proved otherwise anyway. :-)
Oh drat! That's distressing. I some time ago reached the conclusion
that Cuse encoding was evil, but if you are now telling me that
use utf8 is just as bad, I don't know *what* I'm going to do!
One potential problem area that I can imagine is the same one you get with
XML's inline charset declaration: it has to a proper superset of ASCII,
and no non-ASCII characters may occur before the charset declaration.
Is it that you're worried people will think they will get all their strings
magically _utf8_on()d that way -- when in fact, they don't and the same
rules are followed as without the pragma?
Or do you fear it's old code that thought that was the only way to get
Unicode semantics, which is almost certainly wrong in many other ways, too?
Or are you worried about non-shortest-form UTF-8 illegalities
sneaking in unchecked?
I have a feeling that there must be something more than those, because
they're all obvious and I figure you wouldn't have mentioned it if there
weren't something more perilous and more insidious.
And *that* has got me nervous.
In fact I suspect over a pint we would probably mostly agree
about what is too much. :-)
Prolly. Colorado is the state with the most microbreweries per
capita. I don't much care for the beer in Europe apart from what
you get in the British Isles and in Belgium (maybe Benelux).
The rest of it is too easily forgotten, though now and then some
beers from Germany pleasantly surprise me; just not the rule.
Sure, no worries. :-) Hope you have a good weekend.
That will take some doing. I'm supposed to working on
the Camel's regex chapter. But I'm also supposed to
wrestling with Junit test cases whose results are due Monday morning
on an already extended deadline for an academic paper submission.
So far, I have already:
* transparently rewritten all Java regexes out from
under it so they actually work (our text is all UTF-8).
* written Perl code to write a thousand Java Junit test
cases because the framework is too stupid to behave
properly.
* taken to writing my Java with cpp frontending it so I
can have assert macros showing the real unevaluated
expression as a string, and so I can do things like:
#ifdef FIX_BUGGY_JAVA_REGEXES
import static tchrist.PatternUtils.unicode_charclass;
# define FIX(BROKEN) unicode_charclass(BROKEN)
#else
# define FIX(BROKEN)
#endif
leading to code like:
Matcher m = Pattern.compile(FIX(regex)).matcher(string);
The Java monoglots are completely appalled. One helpfully gave me almost
five pages of supernasty Java code just to get around what I did in a few
lines with cpp and token-catenation to effectively pass function pointers.
I politely declined.
Fortunately the only success metric at work is getting the job done, not
purity of soul. I *always* beat the Java people in time-to-solution, even
when I use Java, but that's because per their viewpoint, I cheat.
Whatever. (Wonder whether Rob Pike's hiring for Go? :()
So it may not be a good weekend. I'll try to take some time away
from the computer. That should help.
--tom
Re: Current Issues with perlipc.pod - should they be fixed?
On 4 December 2010 17:43, Tom Christiansen tchr...@perl.com wrote: I think we would both agree that that is way to much. And I automatically assume code with use utf8 in it is subtly broken until proved otherwise anyway. :-) Oh drat! That's distressing. I some time ago reached the conclusion that Cuse encoding was evil, but if you are now telling me that use utf8 is just as bad, I don't know *what* I'm going to do! I dont know that I would say that. On the other hand I think sticking to ASCII, or other approaches might make life simpler. One potential problem area that I can imagine is the same one you get with XML's inline charset declaration: it has to a proper superset of ASCII, and no non-ASCII characters may occur before the charset declaration. Is it that you're worried people will think they will get all their strings magically _utf8_on()d that way -- when in fact, they don't and the same rules are followed as without the pragma? Or do you fear it's old code that thought that was the only way to get Unicode semantics, which is almost certainly wrong in many other ways, too? Or are you worried about non-shortest-form UTF-8 illegalities sneaking in unchecked? I have a feeling that there must be something more than those, because they're all obvious and I figure you wouldn't have mentioned it if there weren't something more perilous and more insidious. And *that* has got me nervous. Its them all together. Ive seen too much code that used utf8 improperly to trust it. In fact I suspect over a pint we would probably mostly agree about what is too much. :-) Prolly. Colorado is the state with the most microbreweries per capita. I don't much care for the beer in Europe apart from what you get in the British Isles and in Belgium (maybe Benelux). The rest of it is too easily forgotten, though now and then some beers from Germany pleasantly surprise me; just not the rule. I generally drink Guiness. :-) [...] The Java monoglots are completely appalled. One helpfully gave me almost five pages of supernasty Java code just to get around what I did in a few lines with cpp and token-catenation to effectively pass function pointers. I politely declined. Fortunately the only success metric at work is getting the job done, not purity of soul. I *always* beat the Java people in time-to-solution, even when I use Java, but that's because per their viewpoint, I cheat. Yeah. I understand. I have had similar experiences with mixing cpp and sql code. Whatever. (Wonder whether Rob Pike's hiring for Go? :() So it may not be a good weekend. I'll try to take some time away from the computer. That should help. Indeed. Time in the big room always helps. cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Current Issues with perlipc.pod - should they be fixed?
On Fri, Dec 3, 2010 at 9:56 AM, Tom Christiansen tchr...@perl.com wrote:
after I posted my series of patches to perlipc.pod , I saw that
tchrist posted his version, which got accepted immediately. As a
downside to that, I'll have to restart my work. However, I noticed
that perlipc.pod still has many perceived issues.
Having real issues is quite distinct from having perceived issues.
In the case of perlipc, all are from the latter set.
Here is a list of things I noticed:
* «defined($Config{sig_name}) || die No sigs?; »
Shouldn't it be using or instead of || or maybe an if?
No, it should not. That conflicts with my own way of speaking
Perl, one which is self-consistent, perfectly safe, and followed
by a good number of core developers, such as Rafael Manfredi.
If you break my style, you break the document. And upon my
style, Damian has said:
And yes, they evince no lack of style.
Not my espoused style, but so many people forget that PBP was--at
its heart--a plea for code to be written in *any* consistent style,
consciously and rationally chosen to meet one's own needs. No-one,
I'm sure, would every accuse you of failing to do that.
If Damian does not condemn me, who are you to do so?
VETO
*
foreach $name (split( , $Config{sig_name})) {
$signo{$name} = $i;
$signame[$i] = $name;
$i++;
}
foreach my $name (Gotta practice what we preach). Furthermore, someone said
we should recommend using a CPAN module for that instead.
The tone and style of the Perl Documentation as set by Larry and myself is
to omit cluttering declarations from tiny snippets. They otherwise
distract from what the point of what is being illustrated. The exception
is if the point of the snippet is the declaration. Putting in declarations
for every two-bit line of code is madness. Look at perlfunc!
VETO
* unless (kill(0 = $pid) || $!{EPERM}) {
warn $pid looks dead;
}
unless and and ||? That's a bit confusing.
I'm sorry you're confused. Me, I find DeMorgan's
Law confusing and therefore avoid its application
wherever possible.
unless I killed it or else I got a permission error
it looks dead
is perfectly clear.
Let's try it your way:
if (!kill(0 = $pid) !$!{EPERM}) {
warn $pid it looks dead;
}
See what a mess you've made?
Don't be ridiculous. Making people compute boolean
algebra in their heads through a surfeit of boolean
ops is a recipe for confusion.
VETO
*
my $ALARM_EXCEPTION = alarm clock restart;
eval {
local $SIG{ALRM} = sub { die $ALARM_EXCEPTION };
alarm 10;
flock(FH, 2) # blocking write lock
|| die cannot flock: $!;
alarm 0;
};
if ($@ $@ !~ quotemeta($ALARM_EXCEPTION)) { die }
Non-lexical filehandle.
Touch noogies. This is a tiny example. $Did $you $really
$want $more $punctuation? @How %about $we *name $the function,
$too, Like::
my $throw_up_and_alarm_exception_using_die = sub {
die $ALARM_EXCEPTION;
};
Or better yet, we can name our function:
THROW_UP_AND_ALARM_EXCEPTION_USING_DIE {
die $ALARM_EXCEPTION;
};
Except now you'll likely get yourself in a snit for it not having
enough #$%^W#$$^ marks.
VETO
*
# system return val is backwards, so not ||
#
$ENV{PATH} .= :/etc:/usr/etc;
if ( system(mknod, $path, p)
system(mkfifo, $path) )
{
die mk{nod,fifo} $path failed;
}
We probably want local $ENV{PATH} here, and can't we expect the
mkfifo system call to work globally already?
No, we most certainly cannot expect that! I didn't put that code in
there out of imagined problems. I put it in there because if I didn't,
it failed on some of systems I tested it on. Why? Because you cannot
count on the user to have those in his path, that's why.
VETO
As for the local(), I feel that again falls in the needless
category, although not so strongly as my other positions.
*
chdir(); # go home
my $FIFO = .signature;
while (1) {
unless (-p $FIFO) {
unlink $FIFO; # discard any failure, will catch later
require POSIX; # delayed loading of heavy module
POSIX::mkfifo($FIFO, 0700)
|| die can't mkfifo $FIFO: $!;
}
# next line blocks till there's a reader
open (FIFO, $FIFO) || die can't open $FIFO: $!;
print FIFO John Smith (smi...@host.org)\n, `fortune -s`;
close(FIFO) || die can't close $FIFO: $!;
sleep 2; # to avoid dup signals
}
Bareword filehandle,
Cope. VETO.
and 2-args open
THIS IS A MYTH!
There is nothing whatsoever wrong with using two-argument
open when you have complete control over the content of
those strings and you are not setting the encoding in the
open itself.
Re: Current Issues with perlipc.pod - should they be fixed?
On Fri, Dec 03, 2010 at 03:43:30PM +0200, Shlomi Fish wrote: On Friday 03 December 2010 15:25:14 demerphq wrote: On 3 December 2010 13:49, Shlomi Fish shlo...@iglu.org.il wrote: Hi all, after I posted my series of patches to perlipc.pod , I saw that tchrist posted his version, which got accepted immediately. As a downside to that, I'll have to restart my work. However, I noticed that perlipc.pod still has many perceived issues. Here is a list of things I noticed: Shlomi, why didnt you send this to tchrist, and cc p5p? Don't know - didn't think about it. I assumed he would see my posting as he saw my previous posts about the perlipc.pod revamp. I'm CCing him here. Dont expect Tom to see your posting. OK, why shouldn't I? He saw the previious posts. He is the one you need to speak to about any of the issues that you raise that are not outright bugs but rather style nits. They are still important, because the people who are trying to help the Perl beginners, are often presented with badly written code, and having code like that in the core Perl documentation only amplifies the problem, and makes us look bad. You would have a point if you there are code fragments that are generally considered badly written. But using '||' where you would prefer 'or', or using FILE globs where you would use a lexical handle, doesn't make badly written code. That's just a style preference. And naming anything that isn't written according to your preferences badly written code doesn't really get people to side with you. Abigail
Re: Current Issues with perlipc.pod - should they be fixed?
after I posted my series of patches to perlipc.pod , I saw that
tchrist posted his version, which got accepted immediately. As a
downside to that, I'll have to restart my work. However, I noticed
that perlipc.pod still has many perceived issues.
Having real issues is quite distinct from having perceived issues.
In the case of perlipc, all are from the latter set.
Here is a list of things I noticed:
* «defined($Config{sig_name}) || die No sigs?; »
Shouldn't it be using or instead of || or maybe an if?
No, it should not. That conflicts with my own way of speaking
Perl, one which is self-consistent, perfectly safe, and followed
by a good number of core developers, such as Rafael Manfredi.
If you break my style, you break the document. And upon my
style, Damian has said:
And yes, they evince no lack of style.
Not my espoused style, but so many people forget that PBP was--at
its heart--a plea for code to be written in *any* consistent style,
consciously and rationally chosen to meet one's own needs. No-one,
I'm sure, would every accuse you of failing to do that.
If Damian does not condemn me, who are you to do so?
VETO
*
foreach $name (split( , $Config{sig_name})) {
$signo{$name} = $i;
$signame[$i] = $name;
$i++;
}
foreach my $name (Gotta practice what we preach). Furthermore, someone said
we should recommend using a CPAN module for that instead.
The tone and style of the Perl Documentation as set by Larry and myself is
to omit cluttering declarations from tiny snippets. They otherwise
distract from what the point of what is being illustrated. The exception
is if the point of the snippet is the declaration. Putting in declarations
for every two-bit line of code is madness. Look at perlfunc!
VETO
* unless (kill(0 = $pid) || $!{EPERM}) {
warn $pid looks dead;
}
unless and and ||? That's a bit confusing.
I'm sorry you're confused. Me, I find DeMorgan's
Law confusing and therefore avoid its application
wherever possible.
unless I killed it or else I got a permission error
it looks dead
is perfectly clear.
Let's try it your way:
if (!kill(0 = $pid) !$!{EPERM}) {
warn $pid it looks dead;
}
See what a mess you've made?
Don't be ridiculous. Making people compute boolean
algebra in their heads through a surfeit of boolean
ops is a recipe for confusion.
VETO
*
my $ALARM_EXCEPTION = alarm clock restart;
eval {
local $SIG{ALRM} = sub { die $ALARM_EXCEPTION };
alarm 10;
flock(FH, 2)# blocking write lock
|| die cannot flock: $!;
alarm 0;
};
if ($@ $@ !~ quotemeta($ALARM_EXCEPTION)) { die }
Non-lexical filehandle.
Touch noogies. This is a tiny example. $Did $you $really
$want $more $punctuation? @How %about $we *name $the function,
$too, Like::
my $throw_up_and_alarm_exception_using_die = sub {
die $ALARM_EXCEPTION;
};
Or better yet, we can name our function:
THROW_UP_AND_ALARM_EXCEPTION_USING_DIE {
die $ALARM_EXCEPTION;
};
Except now you'll likely get yourself in a snit for it not having
enough #$%^W#$$^ marks.
VETO
*
# system return val is backwards, so not ||
#
$ENV{PATH} .= :/etc:/usr/etc;
if ( system(mknod, $path, p)
system(mkfifo, $path) )
{
die mk{nod,fifo} $path failed;
}
We probably want local $ENV{PATH} here, and can't we expect the
mkfifo system call to work globally already?
No, we most certainly cannot expect that! I didn't put that code in
there out of imagined problems. I put it in there because if I didn't,
it failed on some of systems I tested it on. Why? Because you cannot
count on the user to have those in his path, that's why.
VETO
As for the local(), I feel that again falls in the needless
category, although not so strongly as my other positions.
*
chdir();# go home
my $FIFO = .signature;
while (1) {
unless (-p $FIFO) {
unlink $FIFO; # discard any failure, will catch later
require POSIX; # delayed loading of heavy module
POSIX::mkfifo($FIFO, 0700)
|| die can't mkfifo $FIFO: $!;
}
# next line blocks till there's a reader
open (FIFO, $FIFO) || die can't open $FIFO: $!;
print FIFO John Smith (smi...@host.org)\n, `fortune -s`;
close(FIFO) || die can't close $FIFO: $!;
sleep 2;# to avoid dup signals
}
Bareword filehandle,
Cope. VETO.
and 2-args open
THIS IS A MYTH!
There is nothing whatsoever wrong with using two-argument
open when you have complete control over the content of
those strings and you are not setting the encoding in the
open itself.
VETO.
and || instead of or.
Broken style. VETO.
I won't mention
bareword filehandles
Re: Current Issues with perlipc.pod - should they be fixed?
On 2010-12-03 13:49, Shlomi Fish wrote:
after I posted my series of patches to perlipc.pod , I saw that tchrist posted
his version, which got accepted immediately. As a downside to that, I'll have
to restart my work. However, I noticed that perlipc.pod still has many
perceived issues. Here is a list of things I noticed:
* «defined($Config{sig_name}) || die No sigs?; »
Shouldn't it be using or instead of || or maybe an if?
*
foreach $name (split( , $Config{sig_name})) {
$signo{$name} = $i;
$signame[$i] = $name;
$i++;
}
foreach my $name (Gotta practice what we preach). Furthermore, someone said
we should recommend using a CPAN module for that instead.
* unless (kill(0 = $pid) || $!{EPERM}) {
warn $pid looks dead;
}
unless and and ||? That's a bit confusing.
*
my $ALARM_EXCEPTION = alarm clock restart;
eval {
local $SIG{ALRM} = sub { die $ALARM_EXCEPTION };
alarm 10;
flock(FH, 2)# blocking write lock
|| die cannot flock: $!;
alarm 0;
};
if ($@ $@ !~ quotemeta($ALARM_EXCEPTION)) { die }
Non-lexical filehandle.
IMO, direct testing of $@ should also be discouraged.
It should test the (enforced) truth of the return value of the eval.
*
# system return val is backwards, so not ||
#
$ENV{PATH} .= :/etc:/usr/etc;
if ( system(mknod, $path, p)
system(mkfifo, $path) )
{
die mk{nod,fifo} $path failed;
}
We probably want local $ENV{PATH} here, and can't we expect the mkfifo system
call to work globally already?
*
chdir();# go home
my $FIFO = .signature;
while (1) {
unless (-p $FIFO) {
unlink $FIFO; # discard any failure, will catch later
require POSIX; # delayed loading of heavy module
POSIX::mkfifo($FIFO, 0700)
|| die can't mkfifo $FIFO: $!;
}
# next line blocks till there's a reader
open (FIFO, $FIFO) || die can't open $FIFO: $!;
print FIFO John Smith (smi...@host.org)\n, `fortune -s`;
close(FIFO) || die can't close $FIFO: $!;
sleep 2;# to avoid dup signals
}
Bareword filehandle, and 2-args open and || instead of or. I won't mention
bareword filehandles again, but the exist in many other places.
*
use FileHandle;
use IPC::Open2;
$pid = open2(*Reader, *Writer, cat -un);
print Writer stuff\n;
$got =Reader;
We need to make it use strict friendly.
*
#!/usr/bin/perl -w
use warnings instead of -w.
*
my ($remote, $port, $iaddr, $paddr, $proto, $line);
$remote = shift || localhost;
$port= shift || 2345; # random port
if ($port =~ /\D/) { $port = getservbyname($port, tcp) }
die No port unless $port;
$iaddr = inet_aton($remote) || die no host: $remote;
we should declare the variables at first assignment instead of all in one
place.
*
Shouldn't the example use IO::Socket and friends?
*
And here's a multithreaded version. It's multithreaded in that
like most typical servers, it spawns (fork()s) a slave server to
handle the client request so that the master server can quickly
go back to service a new client.
The term multithreaded is misleading it. It is multi-processed - not
multithreaded, because it does not use threads.
*
Section 5 of CPAN's Fmodules file is devoted to Networking, Device
Control (modems), and Interprocess Communication, and contains numerous
unbundled modules numerous networking modules, Chat and Expect operations,
CGI programming, DCE, FTP, IPC, NNTP, Proxy, Ptty, RPC, SNMP, SMTP, Telnet,
Threads, and ToolTalk--to name just a few.
We should no longer mention that modules file.
Should I send patches to correct all these issues (because the Perl
documentation should represent the best practices)? And I hope that this time
all my work will not be for naught again.
I agree to most, if not all of your 'corrrections'.
--
Ruud
Re: Current Issues with perlipc.pod - should they be fixed?
On Fri, Dec 3, 2010 at 3:56 PM, Tom Christiansen tchr...@perl.com wrote: We need to make it use strict friendly. No, we do not. Vide fricking supra. We do, honestly. I'm tired of having to explain to newbies why the official perl documentation is not strict friendly, when I tell them they should use strict. **I don't know how to explain that to them**, it simply doesn't compute. Leon
Re: Current Issues with perlipc.pod - should they be fixed?
On Fri, Dec 3, 2010 at 3:56 PM, Tom Christiansen tchr...@perl.com wrote: We need to make it use strict friendly. No, we do not. =C2=A0Vide fricking supra. We do, honestly. I'm tired of having to explain to newbies why the official perl documentation is not strict friendly, when I tell them they should use strict. **I don't know how to explain that to them**, it simply doesn't compute. Then they just aren't smart enough to handle programming, I guess. I have never ever had the least problem. I've taught many thousands of students, directly. I don't believe you. --tom
