Perl 5.20.0 released
metacpan.org
metacpan.org
Subroutine Signatures
sub foo ($left, $right) {
return $left + $right;
}
Postfix dereferencing
$array_ref->@*;
@{$array_ref};
Also, I think the deprecation of core CGI.pm is pretty major. For now it just issues a deprecation warning, but will be removed totally from core in future versions, only being available via the CPAN.
https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlde...
Perl 5.20.0 represents approximately 12 months of development
since Perl 5.18.0 and contains approximately 470,000 lines of
changes across 2,900 files from 124 authors.
I think we are well past the point now where the language itself is no longer the center of the discussion. Or should not be. What we have is a single back end that's difficult to work on, and which can only target one platform. It's compiled C. Naturally, that's not so bad, as we see Perl is everywhere that Linux is. Which is ... basically everywhere.
But how about a Perl 5 interpreter for the JVM? How about a Perl 5 to Javascript compiler (sort of like Clojurescript)? Or just any other target you can imagine. I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it.
"Kill it," of course, is a relative term. Perl 5 will most likely never truly die. Indeed, I'm writing (what I think is pretty cool) Perl 5 code right at this moment, and putting it on Github and CPAN.
But in terms of attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening. To me, it's a great sadness. I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point).
It can run perl5 and perl6 code, and has proper threading support, but the perl5 backend is still in development.
Regarding the "Perl 5 to Javascript compiler": See perlito
perlcc, the static C compiler is very stable and used in production.
> how about a Perl 5 interpreter for the JVM?
In the opening few minutes of Patrick Michaud's 2013 video "Perl on the JVM", he notes that Jesse Vincent suggested "Perl 6 is Perl's best (only?) hope for running on JVM/.NET".
https://www.youtube.com/watch?v=XgPh5Li3k4g
Have you read about FROGGS' v5?
http://usev5.wordpress.com/2014/05/26/here-implement-labels-...
> I really feel like the difficulty of working on the Perl 5 internals limits the language--and ultimately, will kill it.
There's been a serious effort to clean up the internals in recent years. But yeah, part of the point of P6 was to develop much better internals.
Rakudo and the NQP compiler toolchain are not only well designed but also almost entirely written in P6 code. (Counting NQP as P6.)
> attracting new blood, new developers, young teams of vocal and enthusiastic programmers... I just don't see that happening.
Even in the face of its disastrous reputation, P6 still manages to attract new blood. Aiui the guy who writes the P6 weekly news (http://p6weekly.wordpress.com/) contributed to the Python core before getting in to P6. This year I've seen smart kids visit #perl6 for the first time, chat knowledgeably about a lisp or ML, and start to contribute. Some well known P5 folk such as Nicholas Clark (one of the few folk ever paid by TPF to hack on the P5 internals) and lizmat have fully turned their focus toward P6 in the last year or so.
> I have yet to find another language that I love as much as Perl (and I wouldn't mind doing so, at this point).
What about hanging out on #perl6 for a while (prime time is about 8am thru 8pm EST, 7 days a week) to chat with folk and see what there is to see?
Let me now include a standard caveat list I created last year in an attempt to ensure balance in the force:
"Perl 6 is not remotely as usable and useful as Perl 5; it has dozens of users, not millions; it is 100-1000x slower than Perl 5 for a lot of stuff; the P6 documentation is immature and incomplete; the spec has not reached 6.0.0; the Rakudo compiler has not fully implemented what's already in the spec; most of the concurrency and parallel implementation has only just begun; P6 can not currently use CPAN modules; Perl 6 has syntax and semantics that are not backwards compatible with Perl 5; Perl 6 culture is -Ofun which some think is incompatible with getting things done; some folk think that Perl 6 code looks like line noise... In summary, there are infinitely many things wrong with P6."
I hope that hasn't brought you down to earth with too big a bump.
As a long time professional Perl programmer, I've given up on it. The heartache it has caused on enterprise teams I've been on is not worth the rise in blood pressure. And I'm starting to think that it is inefficient in its yield per unit of effort ratio. Writing good, scalable, clean, modern Perl requires so much couching and qualifying. My teammates couldn't even write good Perl. And so despite my want of evangelizing it, pitching to younger programmers is probably not useful/efficient.
But no, I'm not bitter. =)
Aiui folk who love Perl tend to have a natural affinity for Scala. Stevan Little (the Moose and P5 MOP guy) chose Scala for Moe and I'm pretty sure he enjoyed it.
I'm in to P6. ionforce, please indulge/educate me:
> {Scala|P6 is} a very expressive language that does not sacrifice on power (JVM/type safety).
I hope you see where I'm coming from and are willing to play ball. :)
First and foremost, P6 is incomplete, immature, slow, etc. and almost no one is using it to do anything serious. Aiui Scala is used in a wide range of production settings. This is likely the end of any comparison for most folk.
Scala runs on the JVM. Aiui there's no attempt or intent to run it on anything else. Rakudo (P6) runs on the JVM. It also runs on other VMs including MoarVM. See http://moarvm.org
Scala can "seamlessly" call Java code and vice-versa. Rakudo/JVM can call Java code, but it's currently ugly looking. Java code should be able to call P6 code using Rakudo/JVM but the necessary work isn't complete.
Aiui Scala has solid concurrency and parallelism features. P6 has a good story regarding the language's design as it relates to concurrency and parallelism, but implementation only began last year. See http://jnthn.net/papers/2014-nlpw-reactive.pdf for some of the best Rakudo currently has to offer concurrency-wise.
Scala does type inferencing and you can add explicit types. Its type hierarchy is Java's. P6 also does type inferencing with optional explicit types. But it's type hierarchy is not the same as Java's.
Scala has traits, pattern matching, and higher order functions. So does Rakudo.
> But no, I'm not bitter. =)
Of course not. There's more than one way to do it. :)
> The "interpreter-based threads" provided by Perl are not the
> fast, lightweight system for multitasking that one might expect
> or hope for. Threads are implemented in a way that make them
> easy to misuse. Few people know how to use them correctly or
> will be able to provide help.
Also on the unfortunate side, CGI.pm has been deprecated and will need to be installed from CPAN.
On a happier note, IO::Socket::IP has been added; which finally gives Perl built-in IPV4/IPv6 parity (i.e. one module that can do the jobs of both IO::Socket::INET and IO::Socket::INET6).
No snark: Patches welcome. There have been people who tried to implement better threads for Perl ( https://metacpan.org/release/threads-tbb , https://metacpan.org/release/threads-lite ). However the task is such a monumentally difficult one, that unless you have considerable ressources available (Java, Go), you're unlikely to get a very good implementation of them (Python, Perl). Perl being entirely volunteer-developed means that there currently simply is nobody with both the knowledge, and the available time, to do this. If you think you can do it, or know someone who can, please by all means give it a try.
Use of any of these functions in the POSIX module is now deprecated: isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, and isxdigit
https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsu...
edit: and the copy-on-write string concatenating has the potential to speed up a lot of code, I think.
This is what makes people run way from Perl nowadays. I recently tried to convince someone that Perl is superior to PHP. When he saw the sub and $_ and shift he was like "I'm not touching this with a ten foot pole".
And there was nothing I could say. Compared to something like PHP 5.4, Perl looks like "mildly evolved stone age shell scripting with some chinese characters in it".
And I say this saddened because I still wish PHP wouldn't have won the "battle for the web" over Perl.
Perl was an early love of mine.
I was excited when subroutine prototypes came to Perl. Sadly they were almost completly unlike prototypes in any other language and no-one used them.
Subroutine signatures look like another attempt. Sorry but too late.
You were excited in 1996-Feb-29 when 5.002 was released?
Now _they_ were fine vintages :-)
That is an understandable, yet still naive statement. In the implementation of signatures one has to make MANY decisions concerning the trade-offs of syntax, available features and performance impacts of signatures. The discussions about what was needed and wanted for those experimental signatures were massive and in no way trivial.
Further, asking a PHP person to evaluate another language is often fruitless, as their lifelihood is usually closely tied to that language; and they are largely unaware of the systemic ailments plagueing PHP, thus unable to draw a useful comparison.
I was not aiming to insult, though some might certainly feel offended, but explain why the poster above failed to make a useful point.
Edit: After pizza, clean hands. :-) Just google "cpan method signatures" or similar. The extensible syntax of Perl is really cool. Here is a Moose specific example with type constraints: http://search.cpan.org/~ether/MooseX-Method-Signatures-0.47/...
sub foo($x, $y, $z) ...
sub foo {
my ($x, $y, $z) = @_;
...
The people who want to hate perl will continue to hate it.
After the list of reasons they dislike it are resolved, they'll come up with new ones and/or point to "it's not popular enough" (while simultaneously embracing a brand new language which is significantly less popular).
It would not be the same language in any meaningful sense, beyond branding.
So "people" will never like Perl? Good argument! :-)
Well, what are the reasons to dislike Perl, then?
>>OOP and Unicode etc that require coding against a different abstraction than Perl.
1. Perl, with Moose, has arguably the best OO of the common scripting languages (inspired by the Common Lisp Object System).
2. Perl has probably the best Unicode support of the common scripting languages.
Basic advice:
To be a language war troll you need to know enough so you can make people angry. If they laugh at you, it is a failure.
If you move toward a readable standard "Perl" that supports (only) modern coding styles, you will have something that old Perl users wouldn't really recognize as Perl.
Consider something as simple as: https://news.ycombinator.com/item?id=4774426
This is "Perl" and recognized as such... but my suggestion of calling some entirely different language Perl in the future would make this essentially a non-script. The same is true for most syntax, as well as a large amount of fundamental structures, regexes, etc.
I'll speak following my analogy: I'll call Perl the Apple ][ and some language that wouldn't be recognized as Perl by today's Perl users, but which should be called Perl in the future I will call the iPad.
For example, it's fairly clear that the iPad language should have every single variable be a full object. The Apple ][ does not force this. Likeweise, classes and OOP would not be optional on an iPad, but a fundamental part of writing any program. But on the Apple ][ it is optional. On the iPad it is clear that $_ would be meaningless and not used, ever. It's a syntax error.
On the iPad all source code is UTF-8 or Unicode, and all built-in standard operators including the iPad version of a regular expression (which uses almost none of the syntax of the Apple ][ language natively operate on UTF-8 or Unicode.
The iPad language is longer and has more explicit, longer keywords. The syntax itself is extremely orthogonal and you could describe the entirety of it to anyone who has programmed in any language in a relatively low number of slides, and they can just start coding. It is fully readable to someone who has never read the iPad language, i.e. if you were to read a numerical algorithm or datamining algorithm that was just talked about in a textbook, you wouldn't be distracted by the textbook having to explain what the iPad is. It speaks for itself.
This explicitness is part of the language; there is no way to write one-liners or extremely concise hacks the way the Apple ][ could.
The iPad language lives on the web. It has primitives for handling a client connection as well as a standard framework for rich client-side connections. A persistent connection over http is as everyday as standard input and standard output was on the Apple ][.
And boy can you Google this. The Apple ][ could have a syntactic structure, special variables [1] that were almost impossible to Google. All sorts of Context.
The iPad language has no such context. There is very little you can set to change the fundamental syntax, no way to change the default index on arrays and related things, or any such high-context things or syntactic context. There is just one context, and everything that is done in a program is spelled-out and eminently Google-able. You never have to ask what something actually does, on a syntactic level, or figure it out by running it. You don't have to spend even six days to get to this level at the language: an afternoon tells you all the context that you will ever need. Anything beyond that, you can Google.
Sure, you may not understand what a piece of code does on a higher level. What happens if you apply a fourier transform to _____. It may not be obvious.
But syntactically, it is extremely easy to read off what you're doing. No more difficult than reading off pseudocode in a textbook.
And the language is succinct. The basic syntax is so small, so orthogonal, that you can be handed a 20-page description, having never seen an iPad language, and be able to more or less implement a version in the language of your choice, in a few weeks, without any further information or context. There is not a lot of magic involved.
Of course, the only thing that the iPad language will have in common with the Apple ][ is just the brand (Perl)..or the fact that at some level they're both turing-complete.
The future of Perl is calling an iPad language that is unrecognizable to any current user of Perl, Perl.
Gone are the days of syntactic sugar or short little idioms.
Perl evolved into it's "new form" some time ago. Modern Perl came out 5 years ago and was really just codifying best practice at the time.
It's still the same language if you want it to be. Backwards compatability is taken very seriously. Which - yes - does mean that you can write crappy old perl in it if you want to. (And also that all the crappy old perl you have lying around will continue to work).
But it's also a pretty vibrant, modern language. Any new project or new perl codebase can and should be written in modern perl. And - despite your assertions - it's still very much the same language.
Just now with extra, better stuff too.
So I am actually making the opposite point, that it shouldn't be the same language. I don't think the new form is new enough, I wouldn't call it the iPad of my analogy. In particular, I am also saying that "the iPad shouldn't run Apple ][ code". (at all.) Nearly all Apple ][ code shoudl be a syntax failure on the iPad. Including even $_. Every syntactical element should behave differently, minimally. Much simpler syntax with very little sugar. Much more verbose.
Basically a totally different language should be whitebranded with the brand currently worn by this language. People who used that language shouldn't recognize this language. People who use this language, shouldn't be able to understand that language. They shouldn't have anything in common.
The two things should have literally as much in common as the Apple ][ does with an iPad, which is nigh-unto nothing.
You say, "it's still the same language if you want it to be", but that is a problem. It is like saying you can still pull a jumbo jet with a horse if you want to. No, you shouldn't be able to pull a jumbo jet with a horse at all, a jet just shouldn't support acting as a cab. It should fail to move forward. The horse should give up. The horse in this case is Ascii. It should never even be hitched to it.
Nothing should remain of Perl but the brand, and that they're both turing-complete, just as the intersection between an iPad and an Apple ][ is the null set (plus the fact that they're both physical objects, and a few similar superficial similarities that would apply to every computing device / programming language.)
I'm also not entirely sure what you intend by "changing everything but keep the name the same". Why not use a new name?
The only thing the latter have in common is the name Apple.
The reason you wouldn't use a new name is to show the community of people that you are the same group of people. No other reason.
Perl 6 is not Perl 5, in the same way an iPad isn't still an Apple ][.
Other than that, the main problem I see is you taking a lot of opinion on what you think are good language features and transposing those desires onto "people" who decide what a modern language is. Many of those ideas are based in opinion, or in a language philosophy that is orthogonal to Perl's guiding philosophies, which are very strong and influenced it's design very much.
As far as my "understanding" of Perl 6. According to
http://perl6.org/compilers/std-viv
"The Perl 6 standard grammar is written in Perl 6, and specifies how a Perl 6 program is parsed. The source code can be found on github in the perl6/std project in the file STD.pm6."
That file is here:
https://github.com/perl6/std/blob/master/STD.pm6
Are you saying this is not written in Perl 6?
This is what informs my impression of what Perl 6 is.
It includes lines like this:
token longname {
<name> {} [ <?before ':' <[ a..z A..Z _ \< \[ \« ]>> <colonpair> ]*
}
:my $*QSIGIL ::= '';
token comment:sym<#(...)> {
'#' <?opener>
<.suppose
<quibble($¢.cursor_fresh( %*LANG<Q> ))>
<!before <[,;:]>* \h* [ '#' | $$ ] > # extra stuff on line after closer?
>
<.worry: "Embedded comment seems to be missing backtick"> <!>
}
token pod_comment {
^^ \h* '=' <.unsp>?
[
| 'begin' \h+ <identifier> ::
[
|| .*? "\n" [ :r \h* '=' <.unsp>? 'end' \h+ $<identifier> » \N* ]
|| <?{ $<identifier>.Str eq 'END'}> .*
|| { my $id = $<identifier>.Str; self.panic("=begin $id without matching =end $id"); }
]
| 'begin' » :: \h* [ $$ || '#' || <.sorry: "Unrecognized token after =begin"> \N* ]
[ .*? "\n" \h* '=' <.unsp>? 'end' » \N* || { self.panic("=begin without matching =end"); } ]
| 'for' » :: \h* [ <identifier> || $$ || '#' || <.sorry: "Unrecognized token after =for"> \N* ]
[.*? ^^ \h* $$ || .*]
| ::
[ <?before .*? ^^ '=cut' » > <.panic: "Obsolescent pod format, please use =begin/=end instead"> ]?
[<alpha>||\s||<.sorry: "Illegal pod directive">]
\N*
]
}
token old_rx_mods {
<!after \s>
(\w+)
{
given $0.Str {
$_ ~~ /i/ and $¢.worryobs('/i',':i');
$_ ~~ /g/ and $¢.worryobs('/g',':g');
$_ ~~ /m/ and $¢.worryobs('/m','^^ and $$ anchors');
$_ ~~ /s/ and $¢.worryobs('/s','. or \N');
$_ ~~ /x/ and $¢.worryobs('/x','normal default whitespace');
$_ ~~ /c/ and $¢.worryobs('/c',':c or :p');
$_ ~~ /e/ and $¢.worryobs('/e','interpolated {...} or s{} = ... form');
$_ ~~ /r/ and $¢.worryobs('/c','.subst');
$_ ~~ /a/ and $¢.worryobs('/a','Unicode');
$_ ~~ /d/ and $¢.worryobs('/d','Unicode');
$_ ~~ /l/ and $¢.worryobs('/l','Unicode');
$_ ~~ /u/ and $¢.worryobs('/l','normal regex');
$_ ~~ /p/ and $¢.worryobs('/c','substr or /$<PREMATCH>=[...] <(...)> $<POSTMATCH>=[...]');
$¢.obs('suffix regex modifiers','prefix adverbs');
}
}
}
my @t = grep { substr($_.Str,0,2) ne '::' }, @$t;
It's true that "an iPad isn't still an Apple ][" but I specifically chose those two examples because they have nothing in common. Whether someone has ever used one wouldn't affect their ability to use the other in any way, they are in no sense in the same 'family'. Nothing in common but the brand.
Perl 5 and Perl 6 are clearly in a same general family.
Your final paragraph is extremely fair. Perhaps I should state that I don't know much about why other people don't/wouldn't choose Perl as the first language to do a dynamic web site in in 2018 if they need to pick some language up. It is fair to state that I'm just expressing my own opinion.
1) You seem to be making an argument for some future language. That it would drop many of the things the make Perl Perlish is presupposed as what "people" would want. It would keep the name, as you state, because it would be the same community of people. The community of people that would keep the Perl name are not the same "people" you refer to that after their complaints are fixed would result in a Perl that is not Perlish.
2) If you are just talking about some abstract future language not actually related to Perl, don't use the Perl name. All you are doing is getting people riled up because you are attributing views to them (as the actual Perl community) that they disagree with. Again, I think this can be attributed to you taking a more abstract approach to what you are saying, but choosing to use concrete names, such as Perl, and doing so in the comments of an article about a new Perl release. People here would likely engage you gladly if it was obvious it's just a thought experiment about some futuristic language with nothing to do with Perl, including the name (although there would be challenges as to what you believe are the best features for this new language).
3) You presuppose it's a solved question of what's "best" for specific language features. For example, longer more explicit keywords, very simple to explain, very easy to read by a someone who doesn't know it. These are all good things when you try to maximize learning by novices. One could argue that at the same time, they don't really even allow experts. We have domain languages because they allow us to be more concise and accurate in our definitions. This necessitates learning the domain language, but I think few would argue that the hassle outweighs the future benefit to chemists, physicists, lawyers, engineers and architects to learn the specifics of the domain languages and representations they've developed. As a simple example, look at Ten Hundred Words of Science[1]. I admit it's probably useful to get laymen to understand a topic in general, but is it always sufficient to explain the specifics of that topic in the precise way it requires? Should experts in the field converse with each other this way? Should new bodies of work attempt to use this in the future instead of the domain languages they have developed? It's important to see these for what they are, tools used to shift focus towards or away from specific attributes. It's all a matter of perspective and what the goal is.
You are possibly right, though I was just making an off-hand remark and only just clarified when prompted explicitly. I think the 90 words / 4 lines I wrote originally were fine, and if someone asks for clarification no reason not to include it. In general I don't think an article on a new version of Perl is a bad place for such thoughts.
I like your comments, especially, on domain specific languages, though as mentioned the thread is a bit old and deep to continue here. I couldn't find an email but if you reply with one I'm happy to discuss. Your tenhundredwordsofscience is a really good example of how it gets awkward not to use specialist vocabulary. I like your analogy with chemists, physicists, lawyers, engineers, and architects. The former two especially use specialist symbols that are impenetrable to total laypersons. anyway if you have an email I'll respond to your good points.
Kind of ironic given our conversation :-) Could you bit a bit more explicit ;-)
The thing is that I must have just carefully been doing character transliteration, changing your #, removing spaces, etc, to deobfuscate and @google didn't end up looking wrong enough! Sorry. Sent to the correct (and obvious) email.
BTW the fact this happened is just too good, given the subject! I forgot to dereference a literal in a string. :)
Anyway I've re-sent the email.
(That is why you write so damn much text about something else. Standard behavior for non serious people that are shown to be wrong.)
And the environment changes for everything in computing. Perl is extensible. The use is very different today compared to e.g. before the millennium before testing took over.
So go troll on some subject you know.
(Perl 6 is a different language in the same family. Quite a few features have been backported.)
http://ycombinator.com/newsguidelines.html
"Be civil. Don't say things you wouldn't say in a face to face conversation. When disagreeing, please reply to the argument instead of calling names. E.g. "That is an idiotic thing to say; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them."
As for trolling, at the moment I have four and a half times your karma and am engaging in civil discourse. Try to do the same.
You missed a serious implication with the fact that I'm writing about 'something else'. Which is that what I'm writing about has nothing to do with your language wars. Complaining that I would be wrong if I weren't writing about something else is similar to complaining that an obituary you have read shows extremely shoddy reporting, since a) you're alive, b) they got your birth date, gender, occupation, family history, professional history, and name wrong. They're clearly writing about someone else. Well, yes. I'm actually not part of your language war.
I actually haven't made a single claim about Perl, nor rehashed any arguments.
I explained what features I think a totally new language should have, and that the Perl community should start branding a totally new language as Perl, without starting out from Perl in any way. (As radically new as the iPad is to an Apple ][). It's my opinion.
Without any compatibility or sense of being Perl in any other sense, just like there is zero continuity or compatibility between an Apple ][ and an iPad.
Yes, I agree with you that Perl 6 is a different language in the same family. Perl 6 isn't a candidate for the language that I think should bear Perl branding in the future.
In summary, I like the Perl community and want it to work on some other language and call it Perl. I've given a high-level description of some of the features that I think such a language should have.
My main point is that you could brand anything you want as Perl. It doesn't have to still be Perl to be called Perl. If you disagree, that's fine, but you can't disagree with me for not writing about what you would like me to.
Which were that you made wild claims about stuff you obviously know nothing.
>>I actually haven't made a single claim about Perl
:-)
In the same comment you make explicit claims about what is part of "real" Perl and what is not:
>>My main point is that you could brand anything you want as Perl. It doesn't have to still be Perl to be called Perl.
(Quite fun, considering that programmable language extensions have been on CPAN (/in the Perl binary) for lots of years!)
Originally, I reacted to this claim about what is "real" Perl:
>>even though the modern language has [..] standard computer science constructs like OOP and Unicode etc that require coding against a different abstraction than Perl.
That is not [ignorant] claims about Perl?! (There are more examples.)
Again:
The Perl Unicode support is one of the best of the scripting languages -- and todays std OO (Moo[se]) is arguably better than the other scripting languages.
And OO has been in Perl 5 since the start (1990s).
TL;DR: 1. TRIVIALLY bad claims. 2. Long messages without touching the bad claims. 3. "I never made any claims at all".
If every variable is a reference to an object, that would be a different abstraction from Perl. "The modern language" refers to my hypothetical language which has nothing to do with Perl.
My entire post refers to something hypothetical, which is why you state that it was written about 'something else'.
We are not arguing, and I'm not making any claims about Perl.
I am talking about a hypothetical language in which writing any normal Perl fails with a syntax error.
You wrote "I've flagged your post for your last sentence before your parentheses."
Which was what I discussed. (I did have a 2nd parenthesis, too.)
>>I'm not making any claims about Perl.
I quoted you twice as saying two old language features, which are probably best among the std scripting languages, goes against being Perl. At least one of those features is from the 1990s.
That might mean something different than making claims, but you have carefully not touched it, despite multiple opportunities (while being both called "troll" and down voted over that).
>despite multiple opportunities while being both called "troll" and down voted over that
This style of discussion is not normal here. Nobody but you has called me a troll, because that goes against our community guidelines. Please read the guidelines.
Until then you will not receive more replies from me. If you pay a bit of attention you will note that this community is much more civil than you may be used to from elsewhere.
("But why??" - I hope if you give it some thought you can appreciate the broader context that there is insight to be gained from discussion, as shown by congresses of minds from Athens to the Royal Society, from the Continental Congress to the National Academy of Sciences, all of which have shown that amazing things can be borne of civil discourse.
Whether you think you have anything to gain from anyone else's opinion is up to you to decide. Engaging in name-calling, cheap argumentative tricks (as repeated here), and willful misinterpreting is not up to you.
Please read the guidelines and contribute or ask honest questions, rather than attack. You are very welcome to express a differing opinion, of course, as long as it is done in civil terms.)
(You even quoted part of my comment where I discussed that.)
But it is informative with indignation, while repeatedly refusing to discuss criticism.
You are called troll because of stupid statements on basic points.
You refuse to talk about WHY you are stamped a troll in multiple comments -- instead you complain in big blocks of text about impoliteness!
This is a common troll strategy, but does it really work?
Do a causal reader miss that you refuse to talk about why you are called troll -- and just see two people complaining about each others?
Edit: So your smoke screen of complaints will change my behavior. :-) The next troll with your strategy will just get a note that he refuses to touch why he is called troll + link.
Trying to avoid that is admitting I am correct.
(See my declaration on how to handle trolls in GP.)
Strange that you forgot to link, troll...
I am just going to note that in five^H^H^H^H six^H^H^H seven comments you carefully avoid discussing how I motivate that you are a bad troll: https://news.ycombinator.com/item?id=7809359
> these are going to be littered throughout most perl code
> - its definitely in a lot of my code
Its going to be fun watching people who do used the POSIX functions try alternatives. /[A-Za-z]/, I'd like you to meet umlat-u. The POSIX depended on the locale of the installed software which, assuming that's a feature and not a bug (usually its a bug) it'll be interesting to watch people reimplement that "functionality".
This is a fun 13 year old place to start WRT "simple" data verification, not because it exhaustively covers everything, but its watching a noob start from the beginning and hit about ten different roadblocks. There are plenty more of course.
Alphabetical only? $value =~ /[[:alpha:]]/
Ascii only? $value =~ /[[:ascii:]]/
http://perldoc.perl.org/perlrecharclass.html#Bracketed-Chara...
Hash slices look slick:
%h = (blonk => 2, foo => 3, squink => 5, bar => 8);
%subset = %h{qw[ foo bar ]}; # key/value hash slice
# %subset is now (foo => 3, bar => 8) This deprecation affects things like $\cT, where \cT is a literal control
(such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code.
Surprisingly, it appears that originally this was intended as the
canonical way of accessing variables like $^T, with the caret form only being
added as an alternative.
http://perldoc.perl.org/perlvar.html
If you try to use and output ^O while thinking you're outputting a literal control-O then you'll be in for a big surprise.
The language allows (length) 250 or so character variable names with few restrictions, so using single character names is probably a bug or at least bad style, so when the devs are looking for a class of global "internal-ish" variable names, how about those icky single character names that no one should be using? So that's how you end up with $^V being aliased to a string representation of the version of perl interpreter currently executing. You really shouldn't be using single character variable names so they've been repurposed and attempting to re-re-purpose them might be very exciting.
a C programmer who understands command line argument lists would not even remotely be surprised at the contents of the general variable $0. Its probably more "civilized" to call it $PROGRAM_NAME in your code, but whatever. I don't think this is controversial to alias $PROGRAM_NAME to $0 for anyone civilized aka some minimal C experience.
Perl tends to be consistent. In a similar style, if you insist on implementing a global general variable like $PERL_VERSION which contains a string of pretty much what it sounds like it contains, to keep things consistent all general vars also have a single character synonym, so welcome to $"control-V"
In the "real world" you can write something stupid enough to get yourself fired. This kind of activity probably qualifies unless you have an excellent excuse. Perhaps if you have a complicated if-then statement with numerous clauses and using one individual weird, yet short, variable name allows a debugging programmer to keep the whole control flow in their head instead of scrolling the mess off the screen, then, maybe, its a win. But I wouldn't make a habit of it.
Given that you can pretty much transparently "upgrade" or "downgrade" the code with a simple search and replace its not a major crisis.
A lot of people use Perl::Critic as a Perl "lint" and a lot of those users put large amounts of the perlvars file in the Variables::ProhibitEvilVariables test although the Perl::Critic authors don't by default include them, which many people consider a bug in Perl::Critic but whatever.
There is `use English;` for that. :)
Also interesting, Ruby copied most of Perl's crazy variables [1].
(I say that as a Perl and Ruby fan)
From the obligatory Yegge rant: https://sites.google.com/site/steveyegge2/tour-de-babel
Well, for a certain kind of consistency, yes.
From the perlfunc manpage, about the return values of Perl's operators and functions in scalar versus list context: In general, they do what you want, unless you want consistency.
"Why does Java allow control characters in its identifiers?"
http://stackoverflow.com/questions/4838507/why-does-java-all...