Documentation that refers to Perl 5 as new

[p5pRT]

Migrated from rt.perl.org#109408 (status was 'resolved')

Searchable as RT109408$

[p5pRT]

From @nwc10

There are several places in the core Perl documentation that happily announce that something is new. New in 5.004. Even new in Perl 5.

Perl 5 is not new. 5.004 is not new. I suggest that we have a policy on what "new" is\, document it\, and then check the documentation to rephrase away the old new. Given the plateau of 5.8.x

http​://www.dagolden.com/index.php/1587/visualizing-perl-5-release-cycles/

and the still widespread deployment of 5.8.x in distributions and firms\, 5.10.0 is certainly new. Even 5.8.0 might be\, if we want to highlight things to people who are coming back to Perl having learned it a decade ago (or having "learned" it via online code or tutorials of that era)

For starters\, I think that this section near the top of perlfunc.pod should go​:

Inline Patch

```diff diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index 3358a39..c32c902 100644 --- a/pod/perlfunc.pod +++ b/pod/perlfunc.pod @@ -247,22 +247,6 @@ X X C, C, C, C -=item Functions new in perl5 -X - -C, C, C, C, C, C, C, -C, C, C, C, C, C, C, -C, C

(And I'm suggesting removing the "Functions obsoleted" too, because I don't think that it adds any value\, but it takes up screen and brain space. Do we define "obsoleted" anywhere? They've not been removed in the past 17 years of Perl 5. Are we going to remove them in the next 17?)

Nicholas Clark

[p5pRT]

From @cpansprout

On Mon Jan 30 09​:31​:24 2012\, nicholas wrote​:

There are several places in the core Perl documentation that happily announce that something is new. New in 5.004. Even new in Perl 5.

Perl 5 is not new. 5.004 is not new. I suggest that we have a policy on what "new" is\, document it\, and then check the documentation to rephrase away the old new. Given the plateau of 5.8.x

http​://www.dagolden.com/index.php/1587/visualizing-perl-5-release- cycles/

and the still widespread deployment of 5.8.x in distributions and firms\, 5.10.0 is certainly new. Even 5.8.0 might be\, if we want to highlight things to people who are coming back to Perl having learned it a decade ago (or having "learned" it via online code or tutorials of that era)

For starters\, I think that this section near the top of perlfunc.pod should go​:

diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index 3358a39..c32c902 100644 --- a/pod/perlfunc.pod +++ b/pod/perlfunc.pod @​@​ -247\,22 +247\,6 @​@​ X\ X\

C\\, C\\, C\\, C\

-=item Functions new in perl5 -X\

I’m all for removing this section

- -C\\, C\\, C\\, C\\, C\\, C\\, C\\, -C\\, C\\, C\\, C\\, C\\, C\\, C\\, -C\\, C\

=head2 Portability

(And I'm suggesting removing the "Functions obsoleted" too\,

and this one\, too.

because I don't think that it adds any value\, but it takes up screen and brain space. Do we define "obsoleted" anywhere? They've not been removed in the past 17 years of Perl 5. Are we going to remove them in the next 17?)

They have even had bug fixes. They are still used.

--

Father Chrysostomos

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @rjbs

* Nicholas Clark \perlbug\-followup@​perl\.org [2012-01-30T12​:31​:24]

There are several places in the core Perl documentation that happily announce that something is new. New in 5.004. Even new in Perl 5.

Perl 5 is not new. 5.004 is not new. I suggest that we have a policy on what "new" is\, document it\, and then check the documentation to rephrase away the old new.

Specifically\, I think what we want to address is "if a feature is newer than X\, the version in which it was introduced should be mentioned." So\, we don't need to say "this is new" but "as of v5.18.0\, ..." until we reach a point where we assume "everyone" is on at least v5.18.0.

For starters\, I think that this section near the top of perlfunc.pod should go​:

Agreed.

-- rjbs

[p5pRT]

From @nwc10

On Mon\, Jan 30\, 2012 at 06​:40​:38PM -0500\, Ricardo Signes wrote​:

* Nicholas Clark \perlbug\-followup@​perl\.org [2012-01-30T12​:31​:24]

For starters\, I think that this section near the top of perlfunc.pod should go​:

Agreed.

Gone with commit f677dfafdf263271.

The ticket's more general question remains\, about the start of "new".

Nicholas Clark

[p5pRT]

From tchrist@perl.com

The ticket's more general question remains\, about the start of "new".

I am somewhat leary about calling something "new" (as opposed to "new to 5.x")\, because it's going to be dated soon enough no matter what you do. Maybe one could use "recent" instead at times\, but that still gets stale.

It doesn't seem to make much sense to call things "new" that appeared in a release that's no longer supported.

I think I myself generally call "recent" the current or previous release\, and stop there. That means 5.12 is recent and 5.10 isn't. But not for long. Maybe 3 years for recent? Dunno.

One problem is how vendors take decades to ship recent Perl\, so that changes the recent yardstick to people who just use whatever they have shoved at them. But that's not our fault\, and I don't think it helps anyone for us to try to cater to it.

--tom

[p5pRT]

From @nwc10

On Tue\, Jan 31\, 2012 at 08​:43​:36AM -0700\, Tom Christiansen wrote​:

The ticket's more general question remains\, about the start of "new".

I am somewhat leary about calling something "new" (as opposed to "new to 5.x")\, because it's going to be dated soon enough no matter what you do. Maybe one could use "recent" instead at times\, but that still gets stale.

It doesn't seem to make much sense to call things "new" that appeared in a release that's no longer supported.

Sorry\, to be clear\, I didn't mean to suggest using an unadorned "new". I still mean "new in v5.8" or "new in v5.12". But I meant that we should pick a release before which we don't feel the need to highlight features added in it at all. And in the future when we move the cutoff forward\, trim the parts of the documentation that are no longer accurate in advertising something as new.

I don't think that we should be using unadorned "new" at all\, even "new in this release"\, as it will so easily date\, and effectively represents a maintenance liability\, because they have to be manually corrected in the near future.

I think I myself generally call "recent" the current or previous release\, and stop there. That means 5.12 is recent and 5.10 isn't. But not for long. Maybe 3 years for recent? Dunno.

One problem is how vendors take decades to ship recent Perl\, so that changes the recent yardstick to people who just use whatever they have shoved at them. But that's not our fault\, and I don't think it helps anyone for us to try to cater to it.

Agree on ages - 5.8.8 was release 6 years ago today\, is still the /usr/bin/perl in at least 2 widely distributed commercially supported Linux distributions.

It's subjective\, but I disagree on the last part - I think it does help people using or upgrading from these common older versions if we mention in current documentation that features are newer. It acts somewhat as an advertisement in what you could have if you upgraded\, and it stops anyone from being confused or frustrated if they are reading newer documentation but working on (or targeting portability back to) an earlier version.

(Interestingly\, my hunch on what is most common is already wrong - the 2010 Perl Survey showed 5.10.x just ahead of 5.8.x​:

http​://survey.perlfoundation.org/Data-PerlSurvey-2010/R/07_perl_info/index.html

However\, in 2010\, all the firms that I was aware of Perl version were still on 5.8.5 or 5.8.8.

Admittedly a small number\, but the fact that none had even upgraded to 5.8.9\, which should be trivial\, suggested that there was uniformity in the lag on organisations whose main application runs on Perl.)

Nicholas Clark

[p5pRT]

From @Hugmeir

On Tue\, Jan 31\, 2012 at 1​:03 PM\, Nicholas Clark \nick@​ccl4\.org wrote​:

On Tue\, Jan 31\, 2012 at 08​:43​:36AM -0700\, Tom Christiansen wrote​:

The ticket's more general question remains\, about the start of "new".

I am somewhat leary about calling something "new" (as opposed to "new to 5.x")\, because it's going to be dated soon enough no matter what you do. Maybe one could use "recent" instead at times\, but that still gets stale.

It doesn't seem to make much sense to call things "new" that appeared in a release that's no longer supported.

Sorry\, to be clear\, I didn't mean to suggest using an unadorned "new". I still mean "new in v5.8" or "new in v5.12". But I meant that we should pick a release before which we don't feel the need to highlight features added in it at all. And in the future when we move the cutoff forward\, trim the parts of the documentation that are no longer accurate in advertising something as new.

I don't think that we should be using unadorned "new" at all\, even "new in this release"\, as it will so easily date\, and effectively represents a maintenance liability\, because they have to be manually corrected in the near future.

I think I myself generally call "recent" the current or previous release\, and stop there. That means 5.12 is recent and 5.10 isn't. But not for long. Maybe 3 years for recent? Dunno.

One problem is how vendors take decades to ship recent Perl\, so that changes the recent yardstick to people who just use whatever they have shoved at them. But that's not our fault\, and I don't think it helps anyone for us to try to cater to it.

Agree on ages - 5.8.8 was release 6 years ago today\, is still the /usr/bin/perl in at least 2 widely distributed commercially supported Linux distributions.

It's subjective\, but I disagree on the last part - I think it does help people using or upgrading from these common older versions if we mention in current documentation that features are newer. It acts somewhat as an advertisement in what you could have if you upgraded\, and it stops anyone from being confused or frustrated if they are reading newer documentation but working on (or targeting portability back to) an earlier version.

(Interestingly\, my hunch on what is most common is already wrong - the 2010 Perl Survey showed 5.10.x just ahead of 5.8.x​:

http​://survey.perlfoundation.org/Data-PerlSurvey-2010/R/07_perl_info/index.html

However\, in 2010\, all the firms that I was aware of Perl version were still on 5.8.5 or 5.8.8.

Admittedly a small number\, but the fact that none had even upgraded to 5.8.9\, which should be trivial\, suggested that there was uniformity in the lag on organisations whose main application runs on Perl.)

Nicholas Clark

https://github.com/Hugmeir/utf8mess/tree/pod-109408

So. I more or less went ahead and did this\, to some extent. To some other extent the changes are stylistic\, like consistently using v5.x.y instead of 5.x or 5.x.y or whatnot in perlvar (and only in perlvar\, so as to avoid bikeshedding). I also bumped most odd versions\, post 5.6\, to the next stable release (so\, for example\, 5.7.1 became 5.8.0\, and 5.9.0 became 5.10.0\, but 5.005 is still 5.005).

There's only one big deletion\, which was most of perltrap.pod -- It dealt with traps for Perl 4 programmers migrating to Perl 5. It would be really swell if someone could update perltrap for their other favorite language of choice\, since right now the document is severely lacking\, only dealing with awk\, shell\, C/C++\, and Perl itself.

There's some stuff that I didn't really know about\, so I left it alone\, including all of perlhack(tips)? and perl(re|deb)?guts. One thing that came up in IRC while I was doing this is that having a table in perlvar detailing in which version each variable became available would be really swell. And I know that brian d foy compiled one for string/regex escapes\, which strikes me like a good candidate to get in as well.

Also\, there's this note on perlre​:

As of 5.005\, C\<$&> is not so costly as the other two.

Anyone knows if this is still true?

As a bit of a warning to anyone following from home\, I regen'd known_pod_issues.dat\, so don't fall for the lie of the passing podcheck.t​: perlsec and perltrap fail. I probably left an open =over somewhere\, or sosuch; Haven't really looked into it yet.

[p5pRT]

From tchrist@perl.com

Brian Fraser \fraserbn@&#8203;gmail\.com wrote

There's only one big deletion\, which was most of perltrap.pod -- It dealt with traps for Perl 4 programmers migrating to Perl 5. It would be really swell if someone could update perltrap for their other favorite language of choice\, since right now the document is severely lacking\, only dealing with awk\, shell\, C/C++\, and Perl itself.

Brian and I wrote substantial sections for Python\, Ruby\, and Java for Camel4. It's way too long\, but if you want to cut it down to something reasonable\, that might do. The Java I'm pretty firm on\, Python is ok\, but I haven't a clue about Ruby. You have like only 3 days to tell us if any of this is wrong. :( Chromatic checked the Java and Python\, but those I wasn't too nervous about\, especially Java.

--tom

=head2 Python Traps

Perl and Python are both dynamic languages that share some common ancestors and appeared within 5 years of each other (1987 and 1991). Perl 4 even stole Python’s object system for Perl 5. Although the two languages are more alike than their superficial syntax would suggest\, they also see many of same things from different perspectives.

=item *

Python and Perl sometimes use different words for the same concepts\, and sometimes use the same words for different concepts​:

=begin table picture A mapping of Python to Perl jargon

=headrow

=cell Python

=cell Perl

=bodyrows

=row

=cell Tuple

=cell List

=row

=cell List

=cell Array

=row

=cell Dictionary

=cell Hash

=end table

=item *

X\<variables;Perl vs. Python\, names of> Variables begin with C\<$>\, C\<@​>\, or C\<%> in Perl. Using sigils like C\<$str> lets Perl keep its nouns and its verbs separate\, so you never have to worry about accidentally overwriting some important built-in the way you do in Python if you use C\ for your purposes. You I\ override built-ins in Perl\, but never accidentally the way you can in Python.

=item *

Don’t forget to C\ so Perl notices things that in Python give you exceptions. Otherwise in Perl you only learn about these things if you test for them\, so if you forget\, you never know. See also M\ and M\ in A\<29>.

=item *

Many functions take default arguments or have default behavior for their most common cases. See A\<29>.

=item *

Perl knows about patterns and compiles them for you at compile-time along with the rest of your program.

=item *

Perl’s C\<\N{R\}> construct allows shortcuts\, aliases\, and custom names (which can even be different in different lexical scopes); Python’s C\<\N{R\}> doesn’t.

=item *

Perl characters are abstract code points\, not low-level code units as in Python.

=item *

Perl pattern matching uses Unicode rules for case-insensitivity\, but Python uses only ASCII casefolding rules\, but Perl uses Unicode casefolding rules\, so (for example) all three Greek sigmas match case-insensitively in Perl.

=item *

Perl’s casemapping functions like C\ and C\ follow full Unicode rules\, so work on all cased codepoints\, not just on letters.

=item *

Perl understands (potentially nested) lexical scope\, and so is completely comfortable with full lexical closures. Python doesn’t and isn’t.

=item *

Perl uses full Unicode casing\, so the casemap of a string can be longer than the original. Python uses only simple Unicode casing (when it bothers to use it at all)\, which doesn’t give as good results on strings.

=item *

Any subroutine that returns a blessed reference is a Perl constructor. There’s no special name for a constructor method.

=item *

Perl methods are just methods\, and they always receive their invocant as a bonus\, initial argument. Perl as a language makes no distinction between object methods\, class methods\, or static methods in the Python sense of these tings.

=item *

Perl’s object-orientation is optional\, not mandatory. Perl doesn’t enforce pervasive object-orientation on its built-in types unless you ask it to​: not everything has methods. You might like M\ though.

=item *

In Perl\, you call a function with arguments​:

  my $string = join("|"\, qw(Python Perl Ruby) );

In Python\, there’s likely a main argument with a method to do it​:

  new = "|".join(["Python"\, "Perl"\, "Ruby"])

=item *

Perl pattern matches float unless explicitly you anchor your pattern\, like Python’s C\<re.search()> method but unlike its C\<re.match()>\, which can only match at the beginning of a line.

=item *

Perl’s strings aren’t arrays of characters\, so you can’t use array operators on them. On strings you use string operators\, natch.

=item *

Except for a backslash itself or a backslashed delimiter\, Perl never expands backslash escapes in single-quoted strings\, but Python does. Perl’s singled-quoted strings like C\<'\t'> are more like Python’s raw strings like C\<r'\t'>.

=item *

Perl uses backticks to quote literals to execute arbitrary system commands and return their output\, as in C\<$file = `cat foo.c`>.

=item *

You don’t have to preallocate memory in Perl the way you do in Python\, because arrays and other data structures grow on demand\, sometimes via G\. In Python you have to explicitly grow your lists\, and explicitly allocate new lists and dictionaries to grow them.

=item *

Python throws exceptions for normal operations like C\ failures\, while Perl uses special return values\, usually C\. That means if you forget to check for that error return\, you will miss it. You can use M\ to make failed system calls raise exceptions.

=item *

Perl does not by default throw exceptions on failed or partial numeric conversions from strings\, nor on treating C\ as a defined value. You can make it do so with​:

  use warnings FATAL => q(numeric uninitialized);

=item *

Perl lists never nest\, even if you add extra parens. Use square brackets to make nested arrays (of array references) instead.

=item *

Perl’s range operator is inclusive on both sides\, so C\<0..9> includes C\<0> and C\<9>.

=item *

Perl’s interactive shell is its debugger (A\<19>)\, but M\<Devel​::REPL> is good too. Calling Perl without arguments does not drop you into an interactive read-eval-print loop as it does in Python. Use C\<perl -de0> X\<read-eval-print loop> for that.

=back

=head2 Ruby Traps

Matz\, the creator of Ruby\, stole heavily from Perl (and we think he chose a pretty good starting point). Actually\, he put a Perl and a Smalltalk in a room and let them breed.

=over 4

=item *

There’s no B\. See the Python section.

=item *

Perl just has numbers. It doesn’t care whether they have fractional portions or not.

=item *

You don’t need to surround variables with C\<{}> to interpolate them\, unless you need to disambiguate the identifier from the string around it​:

  "My favorite language is $lang"

=item *

Perl interpolated strings don’t have to be double-quoted​: they can uses C\ with arbitrary delimiters. Similarly generic uninterpolated strings don’t have to use single quotes​: they can use a C\ with arbitrary delimiters.

  q/That's all\, folks/   q(No interpolation for $100)   qq(Interpolation for $animal)

=item *

You need to separate all Perl statements with a C\<;>\, even if they are on different lines. The final statement in a block doesn’t need a final C\<;>.

=item *

The case of variable names in Perl don’t mean anything to B\.

=item *

The sigils don’t denote variable type. A C\<$> in Perl is a single item\, like C\<$scalar>\, C\<$array[0]>\, or C\<$hash{$key}>.

=item *

Perl compares strings with C\\, C\\, C\\, C\\, C\\, and C\.

=item *

No magic blocks\, but see M\<PerlX​::MethodCallWithBlock>.

=item *

Perl’s subroutine definitions are compile-phase. So

  use v5.10;   sub foo { say "Camelia" }   foo();   sub foo { say "Amelia" };   foo();

This prints C\ twice because the last definition is in place before the run phase statements execute. This also means that the call to a subroutine can appear earlier in the file than the subroutine’s definition.

=item *

Perl doesn’t have class variables\, but people try to fake them with lexical variables.

=item *

The range operator in Perl returns a list\, but see M\<PerlX​::Range>.

=item *

The C\ pattern modifier makes Perl’s C\<.> match a newline\, whereas Ruby uses the C\ for the same thing. The C\ in Perl makes the C\<^> and C\<$> anchors match at the beginning and end of logical lines.

=item *

Perl flattens lists.

=item *

Perl’s C\<\< => >> can stand in almost anywhere you can use a comma\, so you’ll often see Perler’s use the arrow to indication direction​:

  rename $old => $new;

=item *

In Perl\, C\<0>\, C\<"0">\, C\<"">\, C\<()>\, and C\ are false in boolean contexts. Basic Perl doesn’t require a special boolean value. You might want the M\ module.

=item *

Perl often fakes the job of C\ with an C\.

=item *

Perl allows you to be a bit sloppier because some of the characters aren’t that special. A C\<?> after a variable doesn’t do anything to the variable\, for instance​:

  my $flag = $foo? 0 :1;

=back

=head2 Java Traps

=over

=item *

There is no C\

in Perl\, or rather\, no

  public static void main(String[ ] argv) throws IOException

=item *

Perl allocates memory for you as you need it by growing its array and hashes on demand. Autovifivication means that if you assign to it\, there'll be room for it.

=item *

Perl doesn’t make you declare your variables in advance unless you C\.

=item *

In Perl there is a difference between a thing and a reference to a thing\, so you (usually) have to explicitly dereference the latter.

=item *

Not all functions need be methods in Perl.

=item *

String and numeric literals aren't usually objects in Perl—but they can be.

=item *

Java programmers looking to define a data structure using a class may be surprised that Perl builds these up out simple data declarations mixing anonymous hashes and arrays. See A\<9>

=item *

Instance data on a Perl object is (usually) just a value in the hash used for the object\, where the name of that hash field corresponds to the name of instance data in Java.

=item *

Privay is optional in Perl.

=item *

The function that a method invocation ends up calling is not determined until run time\, and any object or class with a method by that name is just fine by Perl. Only the interface matters.

=item *

Perl supports operator overloading.

=item *

Perl does not support function overloading by signature. See the M\<Class​::Multimethod> module on CPAN.

=item *

Perl allows multiple inheritance\, although this more corresponds to multiple interfaces in Java\, since Perl classes inherit only methods\, not data.

=item *

A Java C\ is not an abstract Unicode code point; it is a UTF-16 code unit\, which means it takes two of Java C\s\, and special coding\, to work outside the Basic Multilingual Plane in Java. In contrast\, a Perl character I\ an abstract code point\, whose underlying implementation is intentionally hidden from the programmer. Perl code automatically works on the full range of Unicode—and beyond.

=item *

Unlike in Java\, Perl’s string literals can have literal newlines in them. It’s still usually better to use a “here” document\, though.

=item *

Functions typically indicate failure by returning C\\, not by raising an exception. Use the M\ pragma if you like the other way.

=item *

Perl does not use named parameters; arguments to a program show up in each function’s C\<@​_> array. They’re typically given names right away\, though.

=item *

The things Perl refers to as function prototypes work nothing at all like Java’s.

=item *

Perl supports pass by named parameter\, allowing optional arguments to be omitted and the argument order freely rearranged.

=item *

Perl’s garbage collection system is based on reference counting\, so it is possible to write a destructor to automatically clean up resources like open file descriptors\, database connections\, file locks\, etc.

=item *

Perl regexes don’t need extra backslashes.

=item *

Perl has regex literals\, which the compiler compiles and syntax checks them at compile time\, and stores for efficiency.

=item *

Pattern matches in Perl do not silently impose anchors on your patterns the way Java’s C\ method does. Perl’s matching works more like Java’s C\ method.

=item *

A Perl pattern can have more than one capture group by the same name.

=item *

Perl patterns can recurse.

=item *

Java patterns need a special option to make them use Unicode casefolding for case-insensitive matches\, but Perl patterns use Unicode casefolding by default. When doing so\, Perl uses full casefolding but Java uses simple casefolding only.

=item *

In Java patterns\, classic character classes like C\<\w> and C\<\s> are by default ASCII-only\, and it takes a special option to upgrade them to understand Unicode. Perl patterns are Unicode-aware by default\, so it instead takes a special option to downgrade classic character classes (or POSIX classes) back to working only on legacy ASCII.

=item *

Java’s JNI corresponds to Perl’s XS\, at least in spirit. Perl modules often have compiled C/C++ components\, but Java’s rarely do.

=item *

Not everything need be rewritten in Perl; Perl makes it easy to call your system’s native programs using `backticks`\, C\\, and pipe-opens.

=back

[p5pRT]

From @tonycoz

On Tue\, Jan 31\, 2012 at 08​:27​:02PM -0700\, Tom Christiansen wrote​:

Brian Fraser \fraserbn@&#8203;gmail\.com wrote

There's only one big deletion\, which was most of perltrap.pod -- It dealt with traps for Perl 4 programmers migrating to Perl 5. It would be really swell if someone could update perltrap for their other favorite language of choice\, since right now the document is severely lacking\, only dealing with awk\, shell\, C/C++\, and Perl itself.

Brian and I wrote substantial sections for Python\, Ruby\, and Java for Camel4. It's way too long\, but if you want to cut it down to something reasonable\, that might do. The Java I'm pretty firm on\, Python is ok\, but I haven't a clue about Ruby. You have like only 3 days to tell us if any of this is wrong. :( Chromatic checked the Java and Python\, but those I wasn't too nervous about\, especially Java.

I only noticed a typo​:

=item *

Privay is optional in Perl.

Tony

[p5pRT]

From @doy

On Tue\, Jan 31\, 2012 at 08​:27​:02PM -0700\, Tom Christiansen wrote​:

=item *

Privay is optional in Perl.

Privacy\, probably.

-doy

[p5pRT]

From @cpansprout

On Tue Jan 31 19​:54​:02 2012\, tonyc wrote​:

On Tue\, Jan 31\, 2012 at 08​:27​:02PM -0700\, Tom Christiansen wrote​:

Brian Fraser \fraserbn@&#8203;gmail\.com wrote

There's only one big deletion\, which was most of perltrap.pod -- It dealt with traps for Perl 4 programmers migrating to Perl 5. It would be really swell if someone could update perltrap for their other favorite language of choice\, since right now the document is severely lacking\, only dealing with awk\, shell\, C/C++\, and Perl itself.

Brian and I wrote substantial sections for Python\, Ruby\, and Java for Camel4. It's way too long\, but if you want to cut it down to something reasonable\, that might do. The Java I'm pretty firm on\, Python is ok\, but I haven't a clue about Ruby. You have like only 3 days to tell us if any of this is wrong. :( Chromatic checked the Java and Python\, but those I wasn't too nervous about\, especially Java.

I only noticed a typo​:

Same here​:

=item *

Perl interpolated strings don’t have to be double-quoted​: they can uses C\ with arbitrary delimiters. Similarly generic uninterpolated strings don’t have to use single quotes​: they can use a C\ with arbitrary delimiters.

  q/That's all\, folks/   q(No interpolation for $100)   qq(Interpolation for $animal)

s/they can use\Ks//;

--

Father Chrysostomos

[p5pRT]

From @tux

On Tue\, 31 Jan 2012 20​:27​:02 -0700\, Tom Christiansen \tchrist@&#8203;perl\.com wrote​:

=item *

Privay is optional in Perl.   c

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @Leont

On Wed\, Feb 1\, 2012 at 4​:27 AM\, Tom Christiansen \tchrist@&#8203;perl\.com wrote​:

=begin table picture A mapping of Python to Perl jargon

=headrow

=cell Python

=cell Perl

=bodyrows

=row

=cell Tuple

=cell List

=row

=cell List

=cell Array

=row

=cell Dictionary

=cell Hash

=end table

You have tables in your POD? We should have that in the core POD toolchain too.

=item *

Perl methods are just methods\, and they always receive their invocant as a bonus\, initial argument.  Perl as a language makes no distinction between object methods\, class methods\, or static methods in the Python sense of these tings.

Isn't the same true for Python? (No python expert here).

Leon

[p5pRT]

From tchrist@perl.com

Leon Timmermans \fawaka@&#8203;gmail\.com wrote   on Wed\, 01 Feb 2012 12​:46​:09 +0100​:

You have tables in your POD? We should have that in the core POD toolchain too.

Perhaps so.

item *

Perl methods are just methods\, and they always receive their invocant as a bonus\, initial argument. =C2=A0Perl as a language makes no distinction between object methods\, class methods\, or static methods in the Python sense of these tings.

Isn't the same true for Python? (No python expert here).

Perl doesn't have or need a special staticmethod() constructor to make a method that doesn't get its invocant passed in.

Python also has a classmethod()\, which makes a method work normally from our persepctive. Normal object methods aren't such.

--tom

[p5pRT]

From dcmertens.perl@gmail.com

... Python sense of these tings.

Tings should be things. On Jan 31\, 2012 9​:28 PM\, "Tom Christiansen" \tchrist@&#8203;perl\.com wrote​:

Brian Fraser \fraserbn@&#8203;gmail\.com wrote

There's only one big deletion\, which was most of perltrap.pod -- It dealt with traps for Perl 4 programmers migrating to Perl 5. It would be really swell if someone could update perltrap for their other favorite language of choice\, since right now the document is severely lacking\, only dealing with awk\, shell\, C/C++\, and Perl itself.

Brian and I wrote substantial sections for Python\, Ruby\, and Java for Camel4. It's way too long\, but if you want to cut it down to something reasonable\, that might do. The Java I'm pretty firm on\, Python is ok\, but I haven't a clue about Ruby. You have like only 3 days to tell us if any of this is wrong. :( Chromatic checked the Java and Python\, but those I wasn't too nervous about\, especially Java.

--tom

=head2 Python Traps

Perl and Python are both dynamic languages that share some common ancestors and appeared within 5 years of each other (1987 and 1991). Perl 4 even stole Python’s object system for Perl 5. Although the two languages are more alike than their superficial syntax would suggest\, they also see many of same things from different perspectives.

=item *

Python and Perl sometimes use different words for the same concepts\, and sometimes use the same words for different concepts​:

=begin table picture A mapping of Python to Perl jargon

=headrow

=cell Python

=cell Perl

=bodyrows

=row

=cell Tuple

=cell List

=row

=cell List

=cell Array

=row

=cell Dictionary

=cell Hash

=end table

=item *

X\<variables;Perl vs. Python\, names of> Variables begin with C\<$>\, C\<@​>\, or C\<%> in Perl. Using sigils like C\<$str> lets Perl keep its nouns and its verbs separate\, so you never have to worry about accidentally overwriting some important built-in the way you do in Python if you use C\ for your purposes. You I\ override built-ins in Perl\, but never accidentally the way you can in Python.

=item *

Don’t forget to C\ so Perl notices things that in Python give you exceptions. Otherwise in Perl you only learn about these things if you test for them\, so if you forget\, you never know. See also M\ and M\ in A\<29>.

=item *

Many functions take default arguments or have default behavior for their most common cases. See A\<29>.

=item *

Perl knows about patterns and compiles them for you at compile-time along with the rest of your program.

=item *

Perl’s C\<\N{R\}> construct allows shortcuts\, aliases\, and custom names (which can even be different in different lexical scopes); Python’s C\<\N{R\}> doesn’t.

=item *

Perl characters are abstract code points\, not low-level code units as in Python.

=item *

Perl pattern matching uses Unicode rules for case-insensitivity\, but Python uses only ASCII casefolding rules\, but Perl uses Unicode casefolding rules\, so (for example) all three Greek sigmas match case-insensitively in Perl.

=item *

Perl’s casemapping functions like C\ and C\ follow full Unicode rules\, so work on all cased codepoints\, not just on letters.

=item *

Perl understands (potentially nested) lexical scope\, and so is completely comfortable with full lexical closures. Python doesn’t and isn’t.

=item *

Perl uses full Unicode casing\, so the casemap of a string can be longer than the original. Python uses only simple Unicode casing (when it bothers to use it at all)\, which doesn’t give as good results on strings.

=item *

Any subroutine that returns a blessed reference is a Perl constructor. There’s no special name for a constructor method.

=item *

Perl methods are just methods\, and they always receive their invocant as a bonus\, initial argument. Perl as a language makes no distinction between object methods\, class methods\, or static methods in the Python sense of these tings.

=item *

Perl’s object-orientation is optional\, not mandatory. Perl doesn’t enforce pervasive object-orientation on its built-in types unless you ask it to​: not everything has methods. You might like M\ though.

=item *

In Perl\, you call a function with arguments​:

my $string = join("|"\, qw(Python Perl Ruby) );

In Python\, there’s likely a main argument with a method to do it​:

new = "|".join(["Python"\, "Perl"\, "Ruby"])

=item *

Perl pattern matches float unless explicitly you anchor your pattern\, like Python’s C\<re.search()> method but unlike its C\<re.match()>\, which can only match at the beginning of a line.

=item *

Perl’s strings aren’t arrays of characters\, so you can’t use array operators on them. On strings you use string operators\, natch.

=item *

Except for a backslash itself or a backslashed delimiter\, Perl never expands backslash escapes in single-quoted strings\, but Python does. Perl’s singled-quoted strings like C\<'\t'> are more like Python’s raw strings like C\<r'\t'>.

=item *

Perl uses backticks to quote literals to execute arbitrary system commands and return their output\, as in C\<$file = `cat foo.c`>.

=item *

You don’t have to preallocate memory in Perl the way you do in Python\, because arrays and other data structures grow on demand\, sometimes via G\. In Python you have to explicitly grow your lists\, and explicitly allocate new lists and dictionaries to grow them.

=item *

Python throws exceptions for normal operations like C\ failures\, while Perl uses special return values\, usually C\. That means if you forget to check for that error return\, you will miss it. You can use M\ to make failed system calls raise exceptions.

=item *

Perl does not by default throw exceptions on failed or partial numeric conversions from strings\, nor on treating C\ as a defined value. You can make it do so with​:

use warnings FATAL => q(numeric uninitialized);

=item *

Perl lists never nest\, even if you add extra parens. Use square brackets to make nested arrays (of array references) instead.

=item *

Perl’s range operator is inclusive on both sides\, so C\<0..9> includes C\<0> and C\<9>.

=item *

Perl’s interactive shell is its debugger (A\<19>)\, but M\<Devel​::REPL> is good too. Calling Perl without arguments does not drop you into an interactive read-eval-print loop as it does in Python. Use C\<perl -de0> X\<read-eval-print loop> for that.

=back

=head2 Ruby Traps

Matz\, the creator of Ruby\, stole heavily from Perl (and we think he chose a pretty good starting point). Actually\, he put a Perl and a Smalltalk in a room and let them breed.

=over 4

=item *

There’s no B\. See the Python section.

=item *

Perl just has numbers. It doesn’t care whether they have fractional portions or not.

=item *

You don’t need to surround variables with C\<{}> to interpolate them\, unless you need to disambiguate the identifier from the string around it​:

"My favorite language is $lang"

=item *

Perl interpolated strings don’t have to be double-quoted​: they can uses C\ with arbitrary delimiters. Similarly generic uninterpolated strings don’t have to use single quotes​: they can use a C\ with arbitrary delimiters.

   q/That's all\, folks/
   q\(No interpolation for $100\)
   qq\(Interpolation for $animal\)

=item *

You need to separate all Perl statements with a C\<;>\, even if they are on different lines. The final statement in a block doesn’t need a final C\<;>.

=item *

The case of variable names in Perl don’t mean anything to B\.

=item *

The sigils don’t denote variable type. A C\<$> in Perl is a single item\, like C\<$scalar>\, C\<$array[0]>\, or C\<$hash{$key}>.

=item *

Perl compares strings with C\\, C\\, C\\, C\\, C\\, and C\.

=item *

No magic blocks\, but see M\<PerlX​::MethodCallWithBlock>.

=item *

Perl’s subroutine definitions are compile-phase. So

use v5.10; sub foo { say "Camelia" } foo(); sub foo { say "Amelia" }; foo();

This prints C\ twice because the last definition is in place before the run phase statements execute. This also means that the call to a subroutine can appear earlier in the file than the subroutine’s definition.

=item *

Perl doesn’t have class variables\, but people try to fake them with lexical variables.

=item *

The range operator in Perl returns a list\, but see M\<PerlX​::Range>.

=item *

The C\ pattern modifier makes Perl’s C\<.> match a newline\, whereas Ruby uses the C\ for the same thing. The C\ in Perl makes the C\<^> and C\<$> anchors match at the beginning and end of logical lines.

=item *

Perl flattens lists.

=item *

Perl’s C\<\< => >> can stand in almost anywhere you can use a comma\, so you’ll often see Perler’s use the arrow to indication direction​:

rename $old => $new;

=item *

In Perl\, C\<0>\, C\<"0">\, C\<"">\, C\<()>\, and C\ are false in boolean contexts. Basic Perl doesn’t require a special boolean value. You might want the M\ module.

=item *

Perl often fakes the job of C\ with an C\.

=item *

Perl allows you to be a bit sloppier because some of the characters aren’t that special. A C\<?> after a variable doesn’t do anything to the variable\, for instance​:

my $flag = $foo? 0 :1;

=back

=head2 Java Traps

=over

=item *

There is no C\

in Perl\, or rather\, no

public static void main(String[ ] argv) throws IOException

=item *

Perl allocates memory for you as you need it by growing its array and hashes on demand. Autovifivication means that if you assign to it\, there'll be room for it.

=item *

Perl doesn’t make you declare your variables in advance unless you C\<use strict>.

=item *

In Perl there is a difference between a thing and a reference to a thing\, so you (usually) have to explicitly dereference the latter.

=item *

Not all functions need be methods in Perl.

=item *

String and numeric literals aren't usually objects in Perl—but they can be.

=item *

Java programmers looking to define a data structure using a class may be surprised that Perl builds these up out simple data declarations mixing anonymous hashes and arrays. See A\<9>

=item *

Instance data on a Perl object is (usually) just a value in the hash used for the object\, where the name of that hash field corresponds to the name of instance data in Java.

=item *

Privay is optional in Perl.

=item *

The function that a method invocation ends up calling is not determined until run time\, and any object or class with a method by that name is just fine by Perl. Only the interface matters.

=item *

Perl supports operator overloading.

=item *

Perl does not support function overloading by signature. See the M\<Class​::Multimethod> module on CPAN.

=item *

Perl allows multiple inheritance\, although this more corresponds to multiple interfaces in Java\, since Perl classes inherit only methods\, not data.

=item *

A Java C\ is not an abstract Unicode code point; it is a UTF-16 code unit\, which means it takes two of Java C\s\, and special coding\, to work outside the Basic Multilingual Plane in Java. In contrast\, a Perl character I\ an abstract code point\, whose underlying implementation is intentionally hidden from the programmer. Perl code automatically works on the full range of Unicode—and beyond.

=item *

Unlike in Java\, Perl’s string literals can have literal newlines in them. It’s still usually better to use a “here” document\, though.

=item *

Functions typically indicate failure by returning C\\, not by raising an exception. Use the M\ pragma if you like the other way.

=item *

Perl does not use named parameters; arguments to a program show up in each function’s C\<@​_> array. They’re typically given names right away\, though.

=item *

The things Perl refers to as function prototypes work nothing at all like Java’s.

=item *

Perl supports pass by named parameter\, allowing optional arguments to be omitted and the argument order freely rearranged.

=item *

Perl’s garbage collection system is based on reference counting\, so it is possible to write a destructor to automatically clean up resources like open file descriptors\, database connections\, file locks\, etc.

=item *

Perl regexes don’t need extra backslashes.

=item *

Perl has regex literals\, which the compiler compiles and syntax checks them at compile time\, and stores for efficiency.

=item *

Pattern matches in Perl do not silently impose anchors on your patterns the way Java’s C\ method does. Perl’s matching works more like Java’s C\ method.

=item *

A Perl pattern can have more than one capture group by the same name.

=item *

Perl patterns can recurse.

=item *

Java patterns need a special option to make them use Unicode casefolding for case-insensitive matches\, but Perl patterns use Unicode casefolding by default. When doing so\, Perl uses full casefolding but Java uses simple casefolding only.

=item *

In Java patterns\, classic character classes like C\<\w> and C\<\s> are by default ASCII-only\, and it takes a special option to upgrade them to understand Unicode. Perl patterns are Unicode-aware by default\, so it instead takes a special option to downgrade classic character classes (or POSIX classes) back to working only on legacy ASCII.

=item *

Java’s JNI corresponds to Perl’s XS\, at least in spirit. Perl modules often have compiled C/C++ components\, but Java’s rarely do.

=item *

Not everything need be rewritten in Perl; Perl makes it easy to call your system’s native programs using `backticks`\, C\\, and pipe-opens.

=back

[p5pRT]

From tchrist@perl.com

... Python sense of these tings.

Yes\, certainly. Thanks. All typos a spellchecker can find are long taken care of; it's things that are real words but which don't scan that are the problem. The version I sent out was a pre-proofed copy of the pod\, not the latest. However\, all that's really different is that it's now been spellchecked. So there might be grammos. But really\, it's the semantics\, scope\, and tone that I'm concerned about. And length.

For perltrap\, I would recommend making a Java\, Python\, and Ruby section that is about the same size as the existing other-language-trap sections\, not these copious lists I have here. Some of my points are *not* things that beginners will get tripped up on\, but only experts. I don't know that those need to be there at all. A bet 30-40% would plenty suffice.

The problem I have with all this is that these read more like things in language X that will trip up a Perl programmer instead of the other way around. Of course\, that's because that's how they were written\, because we are Perl people\, not J/P/R people. That worked find with C/sed/awk/sh\, because we actually *were* those things before we were Perl programmers\, so knew them well. Now with these others\, not so much.

For example\, I'm always megachafed by Java's lack of proper function pointers (and don't get me started on "reflection"). That's because real programming languages have those. But a Java programmer coming to Perl isn't going to be looking for something whose very existence they don't even know about. Function pointers just aren't in the Java programmer's arsenal of attack\, their toolbox.

In contrast\, a Java programmer told me that he had the most frustrating time in the world coming to Perl because he couldn't find an Integer.parseInt() "static method" (read​: function call) in Perl.

See why those are entirely different classes of trap? Right now we have mostly things from the first sort -- mental lacunae that trip up Perl programmers coming to J/P/R\, not the sort that occurs in J/P/R programmers coming to Perl.

Might anyone please have some suggestions for *those* types of things?

I fear we need people who actually *think* in J/P/R for this sort of question. I can think in C without trouble\, but I definitely don't have Python or Ruby internalized; I don't even know Ruby at all\, and Python I still speak with a strong native accent. Java is further along in that regard. But whereas I previously held for Java a cordial dislike borne of having only a cursory notion of how it worked\, now my dislike for the language can no longer be called at all "cordial"\, for familiarity has bred contempt. And that's something that should really be suppressed\, because it doesn't help anyone\, and helping people is the whole point here.

--tom

[p5pRT]

From @abigail

On Tue\, Jan 31\, 2012 at 08​:27​:02PM -0700\, Tom Christiansen wrote​:

=item *

Perl pattern matching uses Unicode rules for case-insensitivity\, but Python uses only ASCII casefolding rules\, but Perl uses Unicode casefolding rules\, so (for example) all three Greek sigmas match case-insensitively in Perl.

I cannot make head nor tails out of this sentence. It starts of with Perl's ability to do case insensitive Unicode matching\, contrasts that with casefolding in Python\, then contrast that with Unicode casefolding in Perl. Too many "but"s to my taste\, and IMO\, you should either mention casefolding three times\, or case-insensitivity three times.

=item *

Not all functions need be methods in Perl.

"need to be"?

=item *

A Java C\ is not an abstract Unicode code point; it is a UTF-16 code unit\, which means it takes two of Java C\s\, and special coding\, to work outside the Basic Multilingual Plane in Java. In contrast\, a Perl character I\ an abstract code point\, whose underlying implementation is intentionally hidden from the programmer. Perl code automatically works on the full range of Unicode—and beyond.

Well\, I grant you that the intent was to hide it from the programmer. Unfortunally\, in practise\, the implementation is often exposed to the programmer.

=item *

Perl supports pass by named parameter\, allowing optional arguments to be omitted and the argument order freely rearranged.

There's support in Perl for named parameters other than that Perl doesn't prevent the programmer from rolling their own named parameter support?

=item *

Perl’s garbage collection system is based on reference counting\, so it is possible to write a destructor to automatically clean up resources like open file descriptors\, database connections\, file locks\, etc.

I don't see why reference counting is neccessary to be able to write destructors to clean up resources. It's true that Perl uses reference counting\, and that it's possible to write such a destructor\, but I don't see the connection.

=item *

Perl regexes don’t need extra backslashes.

=item *

Perl has regex literals\, which the compiler compiles and syntax checks them at compile time\, and stores for efficiency.

Hmmm. The efficiency is only there if you use them in such a way that it cuts down on compilation. It's very easy to get this wrong​:

  my $re = qr {PAT};   $str =~ /^$re/; # Two compilations.

  my $re = qq {PAT};   $str =~ /^$re/; # One compilation.

[p5pRT]

From dcmertens.perl@gmail.com

On Wed\, Feb 1\, 2012 at 8​:32 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

On Tue\, Jan 31\, 2012 at 08​:27​:02PM -0700\, Tom Christiansen wrote​:

=item *

Perl pattern matching uses Unicode rules for case-insensitivity\, but Python uses only ASCII casefolding rules\, but Perl uses Unicode casefolding rules\, so (for example) all three Greek sigmas match case-insensitively in Perl.

I cannot make head nor tails out of this sentence. It starts of with Perl's ability to do case insensitive Unicode matching\, contrasts that with casefolding in Python\, then contrast that with Unicode casefolding in Perl. Too many "but"s to my taste\, and IMO\, you should either mention casefolding three times\, or case-insensitivity three times.

=item *

Not all functions need be methods in Perl.

"need to be"?

I tripped on this\, too\, but it's technically correct. By my third pass I thought the stylistic flare quite nice.

David

-- "Debugging is twice as hard as writing the code in the first place.   Therefore\, if you write the code as cleverly as possible\, you are\,   by definition\, not smart enough to debug it." -- Brian Kernighan

[p5pRT]

From @cpansprout

On Wed Feb 01 05​:52​:42 2012\, tom christiansen wrote​:

I fear we need people who actually *think* in J/P/R for this sort of question.

Unfortunately I can’t be much help there\, as there is no JavaScript section. :-)

--

Father Chrysostomos

[p5pRT]

From dcmertens.perl@gmail.com

On Wed\, Feb 1\, 2012 at 10​:35 AM\, Father Chrysostomos via RT \< perlbug-followup@​perl.org> wrote​:

On Wed Feb 01 05​:52​:42 2012\, tom christiansen wrote​:

I fear we need people who actually *think* in J/P/R for this sort of question.

Unfortunately I can’t be much help there\, as there is no JavaScript section. :-)

--

Father Chrysostomos

--- via perlbug​: queue​: perl5 status​: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=109408

Any reason you haven't written one? :-D

David

-- "Debugging is twice as hard as writing the code in the first place.   Therefore\, if you write the code as cleverly as possible\, you are\,   by definition\, not smart enough to debug it." -- Brian Kernighan

[p5pRT]

From @Leont

On Wed\, Feb 1\, 2012 at 4​:27 AM\, Tom Christiansen \tchrist@&#8203;perl\.com wrote​:

Brian and I wrote substantial sections for Python\, Ruby\, and Java for Camel4. It's way too long\, but if you want to cut it down to something reasonable\, that might do. The Java I'm pretty firm on\, Python is ok\, but I haven't a clue about Ruby. You have like only 3 days to tell us if any of this is wrong. :( Chromatic checked the Java and Python\, but those I wasn't too nervous about\, especially Java.

If things really get long (don't think we're there yet)\, it may not be a bad idea to split them out into their own pages.

Leon

[p5pRT]

From @cpansprout

On Wed Feb 01 09​:05​:37 2012\, dcmertens.perl@​gmail.com wrote​:

On Wed\, Feb 1\, 2012 at 10​:35 AM\, Father Chrysostomos via RT \< perlbug-followup@​perl.org> wrote​:

On Wed Feb 01 05​:52​:42 2012\, tom christiansen wrote​:

I fear we need people who actually *think* in J/P/R for this sort of question.

Unfortunately I can’t be much help there\, as there is no JavaScript section. :-)

--

Father Chrysostomos

--- via perlbug​: queue​: perl5 status​: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=109408

Any reason you haven't written one? :-D

Well\, when I learnt Perl I rarely got tripped up on anything. Maybe I’m just the wrong sort of person. I might be able to do it\, but certainly not in time for Camel 4.

--

Father Chrysostomos

[p5pRT]

From @rurban

On Wed\, Feb 1\, 2012 at 6​:06 AM\, Tom Christiansen \tchrist@&#8203;perl\.com wrote​:

Leon Timmermans \fawaka@&#8203;gmail\.com wrote   on Wed\, 01 Feb 2012 12​:46​:09 +0100​:

You have tables in your POD? We should have that in the core POD toolchain too.

Perhaps so.

item *

Perl methods are just methods\, and they always receive their invocant as a bonus\, initial argument. =C2=A0Perl as a language makes no distinction between object methods\, class methods\, or static methods in the Python sense of these tings.

Isn't the same true for Python? (No python expert here).

Perl doesn't have or need a special staticmethod() constructor to make a method that doesn't get its invocant passed in.

Python also has a classmethod()\, which  makes a method work normally from our persepctive.  Normal object methods aren't such.

FYI​: I summarized all 4 possible perl method calls (plus function calls) here​: http​://blogs.perl.org/users/rurban/2011/06/how-perl-calls-subs-and-methods.html -- Reini Urban http​://cpanel.net/   http​://www.perl-compiler.org/

[p5pRT]

From @cpansprout

On Wed Feb 01 12​:30​:58 2012\, sprout wrote​:

On Wed Feb 01 09​:05​:37 2012\, dcmertens.perl@​gmail.com wrote​:

On Wed\, Feb 1\, 2012 at 10​:35 AM\, Father Chrysostomos via RT \< perlbug-followup@​perl.org> wrote​:

On Wed Feb 01 05​:52​:42 2012\, tom christiansen wrote​:

I fear we need people who actually *think* in J/P/R for this sort of question.

Unfortunately I can’t be much help there\, as there is no JavaScript section. :-)

--

Father Chrysostomos

--- via perlbug​: queue​: perl5 status​: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=109408

Any reason you haven't written one? :-D

Well\, when I learnt Perl I rarely got tripped up on anything. Maybe I’m just the wrong sort of person. I might be able to do it\, but certainly not in time for Camel 4.

On the other hand\, I’ve just thought of a few things\, the first one being a real problem that I’ve seen in Perl code.

I don’t know whether Tom would want to include this.

=item *

C\<? :> has higher precedence than assignment. In JavaScript\, one can write​:

  condition ? do_something() : variable = 3

and the variable is only assigned if the condition is false. In Perl\, you need parentheses​:

  $condition ? do_something() : ($variable = 3);

Or just use C\.

=item *

Perl requires semicolons to separate statements.

=item *

Unlike C\<for...in>\, Perl's C\ does not allow the left-hand side to be an arbitrary expression. It must be a variable​:

  for my $variable (keys %hash) {   ...   }

=item *

The C\<+> unary operator doesn't do anything in Perl. It exists to avoid syntactical ambiguities.

=item *

One cannot easily add arbitrary properties to an existing object. For a publicly-accessible property\, make a subclass\, and maybe consider C\. To associate data with arbitrary objects\, see L\<Hash​::Util​::FieldHash>.

=item *

An object's members cannot be made accessible as variables. The closest Perl equivalent to C\<with(object) { method() }> is C\\, which can alias C\<$_> to the object​:

  for ($object) {   $_->method;   }

=item *

Variable declarations only affect code I\ the declaration. You cannot write C\<$x = 1; my $x;> and expect the first assignment to affect the same variable. It will instead assign to an C\<$x> declared previously in an outer scope\, or to a global variable.

=item *

C\ variables are scoped to the current block\, not to the current function. If you write C\<{my $x;} $x;>\, the second C\<$x> does not refer to the one declared inside the block.

=item *

The object on which a method is called is passed as one of the method's arguments\, not as a separate C\ value.

--

Father Chrysostomos

[p5pRT]

From @ikegami

On Wed\, Feb 1\, 2012 at 9​:32 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

=item *

Perl supports pass by named parameter\, allowing optional arguments to be omitted and the argument order freely rearranged.

There's support in Perl for named parameters other than that Perl doesn't prevent the programmer from rolling their own named parameter support?

It's referring to how easy it is to do

foo(a => 1\, b => 2);

where as it's next to impossible in another set of languages.

[p5pRT]

From tchrist@perl.com

On Wed Feb 01 12​:30​:58 2012\, sprout wrote​:

On the other hand\, I’ve just thought of a few things\, the first one being a real problem that I’ve seen in Perl code.

I don’t know whether Tom would want to include this.

Is this a Javascript section? Really? Cool!

I probably won't be able to squeeze it in. We're at page-break time.

=item *

C\<? :> has higher precedence than assignment. In JavaScript\, one can write​:

condition ? do\_something\(\) : variable = 3

and the variable is only assigned if the condition is false. In Perl\, you need parentheses​:

$condition ? do\_something\(\) : \($variable = 3\);

Or just use C\.

The ?​: precedence thing is an oddity. I feel like I remember this changing between C and C++\, but no longer recall the details.

=item *

Perl requires semicolons to separate statements.

=item *

Unlike C\<for...in>\, Perl's C\ does not allow the left-hand side to be an arbitrary expression. It must be a variable​:

for my $variable (keys %hash) { ... }

=item *

The C\<+> unary operator doesn't do anything in Perl. It exists to avoid syntactical ambiguities.

s/syntactic\Kal//;

=item *

One cannot easily add arbitrary properties to an existing object. For a publicly-accessible property\, make a subclass\, and maybe consider C\. To associate data with arbitrary objects\, see L\<Hash​::Util​::FieldHash>.

You mean data members? I don't believe in letting your member s hang out in public. :) I consider the class a members-only area.

=item *

An object's members cannot be made accessible as variables. The closest Perl equivalent to C\<with(object) { method() }> is C\\, which can alias C\<$_> to the object​:

for \($object\) \{  $\_\->method; \}

A feature\, perhaps somewhat disguised\, but a feature nonetheless.

Then again\, lvaluable methods are kinda variabili(t)ous.

=item *

Variable declarations only affect code I\ the declaration. You cannot write C\<$x = 1; my $x;> and expect the first assignment to affect the same variable. It will instead assign to an C\<$x> declared previously in an outer scope\, or to a global variable.

Good thing we don't want confuse them with

  my $x = 1 + $x;

do we now? :)

=item *

C\ variables are scoped to the current block\, not to the current function. If you write C\<{my $x;} $x;>\, the second C\<$x> does not refer to the one declared inside the block.

In general\, Perl has *lexical* scope\, and indeed\, the scope is the ‘font of all privacy’(⋆) in Perl. Think of (most) pragmas\, for example.

=item *

The object on which a method is called is passed as one of the method's arguments\, not as a separate C\ value.

Not just the object\, but any invocant\, so classes\, too. The invocant is always unshift()ed onto the arglist.

--tom

  PS​: Yeah ok\, if you can't bring yourself to posh up “the /fɔːnt/ of all   /ˈprɪvəsi/”\, you can just say “the source of all /ˈpraɪvəsi/”. :)

[p5pRT]

From tchrist@perl.com

Abigail \abigail@&#8203;abigail\.be wrote   on Wed\, 01 Feb 2012 15​:32​:30 +0100​:

On Tue\, Jan 31\, 2012 at 08​:27​:02PM -0700\, Tom Christiansen wrote​:

=item *

Perl pattern matching uses Unicode rules for case-insensitivity\, but Python uses only ASCII casefolding rules\, but Perl uses Unicode casefolding rules\, so (for example) all three Greek sigmas match case-insensitively in Perl.

I cannot make head nor tails out of this sentence. It starts of with Perl's ability to do case insensitive Unicode matching\, contrasts that with casefolding in Python\, then contrast that with Unicode casefolding in Perl. Too many "but"s to my taste\, and IMO\, you should either mention casefolding three times\, or case-insensitivity three times.

You're right\, you're right\, you're right. It's blather.

=item *

Not all functions need be methods in Perl.

"need to be"?

Turns out that "need" can be an uninflected modal in English\, as in "...if need be"\, or in "She need not call again." I can see why you thought to put the "to" there\, though\, since the uninflected modal use is somewhat less common in regular speech than the more normal regular inflected form. Here's sense 10. c. for need\, v.2 from the OED3​:

10. c. trans. With bare infinitive.

  In modern use chiefly in non-affirmative contexts\, i.e. in negative clauses\,   with near-negative adverbs such as but and hardly\, in as\, if\, or than clauses\,   in statements expecting or implying a negative response\, or in interrogative   clauses; also with only (usually immediately following the verb).

  (a) In a negative clause or a context with negative implications.   In modern use the 3rd person singular inflected form is less   common than the uninflected (β) form.

Citations for the (α) form include​:

  1855 Tennyson Maud xxiii. ix\, in Maud & Other Poems 80 Who knows‥Whether I need have fled?   1875 B. Jowett tr. Plato Dialogues (ed. 2) V. 370\, I need hardly ask again.   1991 What Personal Computer Dec. 19/3 It's a flat panel display with touch screen and stylus modes\, so you never need touch a keyboard again.

and for the (β) form​:

  1915 R. Frost Let. 11 Nov. (1964) 17 He needn't go calling himself sticky names like Gayheart in public.   1921 D. H. Lawrence Women in Love (new ed.) xxx. 510 It was a relief to her to be acknowledged extraordinary. Then she need not fret about the common standards.   1993 Guardian 23 Oct. (Weekend Suppl.) 42/4 Stock-making needn't be the labour-intensive grind described in French cookbooks.   1997 N.Y. Times 16 Nov. i. 32/3 In baseball\, for example\, is there any rule saying that a second baseman need only be in the neighborhood of second base while middle-manning a double play?

So it's still current\, but again\, even a native speaker might well consider whether a "to" might be called for there. I just didn't put it in\, is all.

=item *

A Java C\ is not an abstract Unicode code point; it is a UTF-16 code unit\, which means it takes two of Java C\s\, and special coding\, to work outside the Basic Multilingual Plane in Java. In contrast\, a Perl character I\ an abstract code point\, whose underlying implementation is intentionally hidden from the programmer. Perl code automatically works on the full range of Unicode—and beyond.

Well\, I grant you that the intent was to hide it from the programmer. Unfortunally\, in practise\, the implementation is often exposed to the programmer.

It seems like (nearly?) everything in Java has a 16-bit code-unit "char" interface\, but only a few things have a 32-bit code-point "int" interface.
It makes it really clunky. This is what I was trying to allude to. You don't get to deal with logical characters as often as you'd like to be able to in Java.

=item *

Perl supports pass by named parameter\, allowing optional arguments to be omitted and the argument order freely rearranged.

There's support in Perl for named parameters other than that Perl doesn't prevent the programmer from rolling their own named parameter support?

It's not really possible in most other languages of my acquaintance.

  my %args = @​_;

is pretty powerful\, actually\, and you just can't do that in things like Java. But this is one of those things where I'm coming at it from the wrong direction again\, I wager.

=item *

Perl’s garbage collection system is based on reference counting\, so it is possible to write a destructor to automatically clean up resources like open file descriptors\, database connections\, file locks\, etc.

I don't see why reference counting is neccessary to be able to write destructors to clean up resources. It's true that Perl uses reference counting\, and that it's possible to write such a destructor\, but I don't see the connection.

Ah.

It's that you cannot guarantee that destructors are *ever* called in Java — nor\, now because of J(ava-P)ython\, in Python either. That means you cannot hope to have a destructor duly called to free up a non-memory resource. They might never happen at all\, and in fact\, in most JVM implementations\, never do get called at all in the normal course of running. At all\, I said. Scary.

It's a very different resource-management (non-)strategy than we're accustomed to in Perl\, where the only non-determinism I'm aware of with destructors is their order of firing when several logically achieve a refcount of 0 "simultaneously".

I'm not counting circularities\, though\, since those don't normally get dealt with till thread shutdown time. But at least we guarantee that they *shall*\, assuming you aren't an immortal daemon process.

=item *

Perl regexes don’t need extra backslashes.

=item *

Perl has regex literals\, which the compiler compiles and syntax checks them at compile time\, and stores for efficiency.

Hmmm. The efficiency is only there if you use them in such a way that it cuts down on compilation. It's very easy to get this wrong​:

my $re = qr \{PAT\};
$str =~ /^$re/;    \# Two compilations\.

my $re = qq \{PAT\};
$str =~ /^$re/;    \# One compilation\.

The thing I'm trying to convey is that in contradistinction to the bolted-on-the-side approach to regexes taken by both Java and Python\, in Perl the very compiler itself is aware of their existence. This allows it to syntax check and compile them at compile time\, which can essentially "never" happen in Java or Python. (Ok\, people who are super-careful can do static initializers in Java for this\, but it's a real pain in the butt to manage\, and should be done for you.)

I really appreciate your (and everyone's) help in all of this. I just never became comfortable with my rough draft of this section\, as it never got rewritten. So this helps it not be a complete embarrassment.

thanks again\,

--tom

[p5pRT]

From @tamias

More JavaScript to Perl traps​:

=item *

In Perl\, binary C\<+> is always addition. C\<$string1 + $string2> converts both strings to numbers and then adds them. To concatenate two strings\, use the C\<.> operator.

=item *

To iterate over the indices of an array\, use C\<foreach my $i (0 .. $#array) {}>. C\<foreach my $v (@​array) {}> iterates over the values.

=item *

To iterate over the keys of a hash\, use C\<foreach my $k (keys %hash) {}>. C\<foreach my $kv (%hash) {}> iterates over the keys and values\, and is generally not useful ($kv would be a key\, then a value\, and so on).

=item *

Perl requires braces following C\\, C\\, C\\, etc.

=item *

In Perl\, "else if" is spelled "elsif".

Ronald

[p5pRT]

From @Hugmeir

On Wed\, Feb 1\, 2012 at 12​:27 AM\, Tom Christiansen \tchrist@&#8203;perl\.com wrote​:

Brian Fraser \fraserbn@&#8203;gmail\.com wrote

There's only one big deletion\, which was most of perltrap.pod -- It dealt with traps for Perl 4 programmers migrating to Perl 5. It would be really swell if someone could update perltrap for their other favorite language of choice\, since right now the document is severely lacking\, only dealing with awk\, shell\, C/C++\, and Perl itself.

Brian and I wrote substantial sections for Python\, Ruby\, and Java for Camel4. It's way too long\, but if you want to cut it down to something reasonable\, that might do. The Java I'm pretty firm on\, Python is ok\, but I haven't a clue about Ruby. You have like only 3 days to tell us if any of this is wrong. :( Chromatic checked the Java and Python\, but those I wasn't too nervous about\, especially Java.

Eh. I only really know Ruby of those\, so I'll tackle that. I'll be the first to admit that I'm rather rusty\, so yeah.

=head2 Ruby Traps

Matz\, the creator of Ruby\, stole heavily from Perl (and we think he chose a pretty good starting point). Actually\, he put a Perl and a Smalltalk in a room and let them breed.

=over 4

=item *

There’s no B\. See the Python section.

=item *

Perl just has numbers. It doesn’t care whether they have fractional portions or not.

=item *

You don’t need to surround variables with C\<{}> to interpolate them\, unless you need to disambiguate the identifier from the string around it​:

"My favorite language is $lang"

It's not bare braces\, but #{}​:

$ ruby -e 'x=1; puts "{x}#{x}"' {x}1

As a point of reference\, "#{ ... }" in ruby is roughly "@​{[ ... ]}" in perl.

=item *

Perl interpolated strings don’t have to be double-quoted​: they can uses C\ with arbitrary delimiters. Similarly generic uninterpolated strings don’t have to use single quotes​: they can use a C\ with arbitrary delimiters.

   q/That's all\, folks/
   q\(No interpolation for $100\)
   qq\(Interpolation for $animal\)

I thought this one was phrased very confusingly\, but in any case it's also worth noting that Ruby has similar constructs​:

  %q/That's all\, folks/

   %q\(No interpolation for $100\)

  %(Interpolation for $animal)

(also %r!! for regexen\, %w\<> for qw()\, and %W() for qw() with interpolation.. And I think I'm missing some)

And on the topic of strings\, ruby has a special kind of heredoc\, \<\<-END\, which automagically deals with indentation of the text quoted.

=item *

You need to separate all Perl statements with a C\<;>\, even if they are on different lines. The final statement in a block doesn’t need a final C\<;>.

=item *

The case of variable names in Perl don’t mean anything to B\.

=item *

The sigils don’t denote variable type. A C\<$> in Perl is a single item\, like C\<$scalar>\, C\<$array[0]>\, or C\<$hash{$key}>.

Eh\, sigils in ruby don't do that either\, unless you stress the definition of variable type a lot. They denote scope; $var is a global\, @​var is a instance variable\, @​@​var is a class attribute.

=item *

Perl compares strings with C\\, C\\, C\\, C\\, C\\, and C\.

=item *

No magic blocks\, but see M\<PerlX​::MethodCallWithBlock>.

=item *

Perl’s subroutine definitions are compile-phase. So

use v5.10; sub foo { say "Camelia" } foo(); sub foo { say "Amelia" }; foo();

This prints C\ twice because the last definition is in place before the run phase statements execute. This also means that the call to a subroutine can appear earlier in the file than the subroutine’s definition.

=item *

Perl doesn’t have class variables\, but people try to fake them with lexical variables.

=item *

The range operator in Perl returns a list\, but see M\<PerlX​::Range>.

=item *

The C\ pattern modifier makes Perl’s C\<.> match a newline\, whereas Ruby uses the C\ for the same thing. The C\ in Perl makes the C\<^> and C\<$> anchors match at the beginning and end of logical lines.

=item *

Perl flattens lists.

Ruby sort of does this\, too. Or\, well\, doesn't unless you ask it to\, but pretends that it does even if you don't​:

$ ruby -e '[ [1\,2\, [3\,4]]\, [[[5]]\,6] ].each { |x| puts x }'

Which outputs 1..5. If you check the structure\, it's still an AoA\, but most usual traversal methods seem to call something like .flatten before starting. You can get a totally flattened structure by calling .flatten or .flatten! though.

=item *

Perl’s C\<\< => >> can stand in almost anywhere you can use a comma\, so you’ll often see Perler’s use the arrow to indication direction​:

rename $old => $new;

Also\, in ruby the fat comma doesn't quote it's left-handed argument\, so instead people use 'symbols'\, e.g. :symbol => "yadda".

And in the topic of hashes\, hash keys in ruby can be any object\, whereas in perl they can only be strings\, tie magic notwithstanding.

=item *

In Perl\, C\<0>\, C\<"0">\, C\<"">\, C\<()>\, and C\ are false in boolean contexts. Basic Perl doesn’t require a special boolean value. You might want the M\ module.

=item *

Perl often fakes the job of C\ with an C\.

=item *

Perl allows you to be a bit sloppier because some of the characters aren’t that special. A C\<?> after a variable doesn’t do anything to the variable\, for instance​:

my $flag = $foo? 0 :1;

=back

If it helps\, I posted a handful of things here a while ago​: http​://blogs.perl.org/users/brian_d_foy/2011/10/perl-traps-for-ruby-programmers.html

I'll pod them and send a patch to the list later.

[p5pRT]

From @cpansprout

On Wed Feb 01 16​:49​:50 2012\, tom christiansen wrote​:

On Wed Feb 01 12​:30​:58 2012\, sprout wrote​: =item *

One cannot easily add arbitrary properties to an existing object. For a publicly-accessible property\, make a subclass\, and maybe consider C\. To associate data with arbitrary objects\, see L\<Hash​::Util​::FieldHash>.

You mean data members? I don't believe in letting your member s hang out in public. :) I consider the class a members-only area.

I suppose that entry is a bit vague. In a web browser environment\, it is possible and very tempting (and also safe\, when done carefully) to add arbitrary properties to DOM elements. I’ve abused that many times. Just use underscores\, as underscores are not used in any APIs. It’s quite safe if you control all the code that runs in a particular page\, which is the usual case.

But in general adding properties to objects of another class is not a good idea. So I suppose it shouldn’t be encouraged. :-)

=item *

An object's members cannot be made accessible as variables. The closest Perl equivalent to C\<with(object) { method() }> is C\\, which can alias C\<$_> to the object​:

for \($object\) \{  $\_\->method; \}

A feature\, perhaps somewhat disguised\, but a feature nonetheless.

Yes\, but JavaScript has a very different model. There is no difference between a property and a variable in JavaScript. Every variable is a property of some object. An unqualified variable refers to the property of an object in scope. (A function’s run-time scope is a special object not directly accessible to JavaScript code.)

Then again\, lvaluable methods are kinda variabili(t)ous.

=item *

Variable declarations only affect code I\ the declaration. You cannot write C\<$x = 1; my $x;> and expect the first assignment to affect the same variable. It will instead assign to an C\<$x> declared previously in an outer scope\, or to a global variable.

Good thing we don't want confuse them with

my $x = 1 \+ $x;

do we now? :)

Actually\, that might be good to bring up\, too.

=item *

C\ variables are scoped to the current block\, not to the current function. If you write C\<{my $x;} $x;>\, the second C\<$x> does not refer to the one declared inside the block.

In general\, Perl has *lexical* scope\, and indeed\, the scope is the ‘font of all privacy’(⋆) in Perl. Think of (most) pragmas\, for example.

=item *

The object on which a method is called is passed as one of the method's arguments\, not as a separate C\ value.

Not just the object\, but any invocant\, so classes\, too. The invocant is always unshift()ed onto the arglist.

--tom

PS​: Yeah ok\, if you can't bring yourself to posh up “the /fɔːnt/

That should be /fɒnt/. If you say /fɔːnt/ (British pronunciation of ‘faunt’\, whatever that means)\, you’ll sound like an American trying to put on a British accent. :-)

of all /ˈprɪvəsi/”\, you can just say “the source of all /ˈpraɪvəsi/”. :)

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Wed Feb 01 16​:49​:50 2012\, tom christiansen wrote​:

In general\, Perl has *lexical* scope\, and indeed\, the scope is the ‘font of all privacy’(⋆) in Perl. Think of (most) pragmas\, for example.

In JavaScript\, because of the variable and property equivalence\, one can explicitly create a new scope\, within a function\, by using the ‘with’ keyword to put an object in scope\, so​:

  {   my $x = $x;   ...   }

is written

  with({x​:x}) {   ...   }

--

Father Chrysostomos

[p5pRT]

From @Leont

On Thu\, Feb 2\, 2012 at 2​:30 AM\, Tom Christiansen \tchrist@&#8203;perl\.com wrote​:

It's that you cannot guarantee that destructors are *ever* called in Java — nor\, now because of J(ava-P)ython\, in Python either. That means you cannot hope to have a destructor duly called to free up a non-memory resource.  They might never happen at all\, and in fact\, in most JVM implementations\, never do get called at all in the normal course of running.  At all\, I said.  Scary.

It's a very different resource-management (non-)strategy than we're accustomed to in Perl\, where the only non-determinism I'm aware of with destructors is their order of firing when several logically achieve a refcount of 0 "simultaneously".

This is also known as Resource Acquisition Is Initialization\, which is the poorest name for a programming pattern ever.

Leon

[p5pRT]

From @cpansprout

On Tue Jan 31 19​:20​:06 2012\, Hugmeir wrote​:

https://github.com/Hugmeir/utf8mess/tree/pod-109408

So. I more or less went ahead and did this\, to some extent. ...

Thank you. I’ve applied this and merged it as 598798734\, except for one part of perluniintro\, where you deleted a paragraph about :locale that is still true.

There's only one big deletion\, which was most of perltrap.pod -- It dealt with traps for Perl 4 programmers migrating to Perl 5. It would be really swell if someone could update perltrap for their other favorite language of choice\, since right now the document is severely lacking\, only dealing with awk\, shell\, C/C++\, and Perl itself.

Tom\, may we steal the perl traps from Camel 4? (If so\, we will need the latest version\, not what is already in this ticket.)

Also\, there's this note on perlre​:

As of 5.005\, C\<$&> is not so costly as the other two.

Anyone knows if this is still true?

I don’t think it is.

As a bit of a warning to anyone following from home\, I regen'd known_pod_issues.dat\, so don't fall for the lie of the passing podcheck.t​: perlsec and perltrap fail. I probably left an open =over somewhere\, or sosuch; Haven't really looked into it yet.

Even fixing errors (removing long verbatim lines\, in this case) requires a regen.

--

Father Chrysostomos

[p5pRT]

From @jkeenan

On Tue Jan 31 04​:27​:52 2012\, nicholas wrote​:

On Mon\, Jan 30\, 2012 at 06​:40​:38PM -0500\, Ricardo Signes wrote​:

* Nicholas Clark \perlbug\-followup@&#8203;perl\.org [2012-01-30T12​:31​:24]

For starters\, I think that this section near the top of perlfunc.pod should go​:

Agreed.

Gone with commit f677dfafdf263271.

The ticket's more general question remains\, about the start of "new".

Nicholas Clark

Unfortunately\, tickets where only "more general questions" remain too often lack criteria for being closed. The postings that followed in this RT thread mostly constituted a policy discussion of the kind better conducted on the mailing list.

I recommend that those who posted to this thread last year review their postings and either (a) post policy viewpoints to p5p; and/or (b) create new RT items *with patches*.

I am taking this ticket for the purpose of closing it in 7 days unless someone wants to set off a new round of bikeshedding ;-) .

Thank you very much. Jim Keenan

[p5pRT]

From @jkeenan

On Sun Jun 16 18​:13​:22 2013\, jkeenan wrote​:

On Tue Jan 31 04​:27​:52 2012\, nicholas wrote​:

On Mon\, Jan 30\, 2012 at 06​:40​:38PM -0500\, Ricardo Signes wrote​:

* Nicholas Clark \perlbug\-followup@&#8203;perl\.org [2012-01-30T12​:31​:24]

For starters\, I think that this section near the top of perlfunc.pod should go​:

Agreed.

Gone with commit f677dfafdf263271.

The ticket's more general question remains\, about the start of "new".

Nicholas Clark

Unfortunately\, tickets where only "more general questions" remain too often lack criteria for being closed. The postings that followed in this RT thread mostly constituted a policy discussion of the kind better conducted on the mailing list.

I recommend that those who posted to this thread last year review their postings and either (a) post policy viewpoints to p5p; and/or (b) create new RT items *with patches*.

I am taking this ticket for the purpose of closing it in 7 days unless someone wants to set off a new round of bikeshedding ;-) .

No one has disputed this approach\, so I'm marking this ticket resolved. Please open new RTs focused on particular files if that is necessary.

Thank you very much. Jim Keenan

[p5pRT]

@jkeenan - Status changed from 'open' to 'resolved'