What are /r/perl's favorite Products & Services?

From 3.5 billion Reddit comments

You should be fine starting with the fifth edition, although you'll miss some minor updates to new Perl features. For instance, in the sixth edition we pull back on smart matching; that feature didn't turn out to be as useful or interesting as we thought it would be when 5.10 was released.

At the beginner level, the basics are the same. You aren't going to learn all of Perl from a 300-page book. You'll still have a fine start. Just keep learning more Perl after you read the book. You are never done learning a programming language.

You can see some of the updates in the companion website for Learning Perl and read about Perl's latest features at The Effective Perler.

Well, why not? As stated many times in "Learning Perl" and "Programming Perl", Perl is suited for beginners pretty well. Perl is flexible enough to allow you to express yourself as a beginner as well as an advanced programmer. As you learn more of the language, you can express yourself better. The power of Perl is that it does not enfoce you to be an expert while making your first steps.

you should use ssh keys for this. You can secure the ssh keys with a passphrase and then use an ssh-agent to save the passphrase so you don't have to enter it every time.

If you're in windows you can look at putty, pageant. It will also work with WinSCP and with some other things to make life easier.

This will not help with sudo to root. That is controlled with a local policy on the box and is an administrative decision. You can change the sudoers access to enable sudo to root with no password, you just add NOPASSWD: to the line that controls your access, but again it would be up to the site admins if this were allowed.

Use "visudo" if you make changes to the sudoers file. It protects you from making changes that break the syntax and lock you out of root.

Edit:

Here is a link to working with keys with putty:

http://www.rackspace.com/knowledge_center/article/generating-rsa-keys-with-ssh-puttygen

This is great, thanks for organizing. I love community feedback especially now that the future of Perl is in discussion (e.g. Perl 7). That said, I'm slightly concerned about the ability of Perl Foundation to act on it. Just three weeks ago, they released the results of the developer survey where the community asked for better tooling and IDE support, and they responded with:

> There is already IDE support for Perl - but feedback in the survey shows that we need a page on https://www.perl.org/ 

They basically told the community that we're wrong, IDE support is already great, and we just need an info page.

Now 3 weeks later they're asking for community feedback again. How can I be sure this will result in meaningful and actionable outcomes toward the future of Perl? Or are we just providing input on an updated mission statement to drop on some website?

https://news.perlfoundation.org/post/newcomer-survey-results-actions

Learning Perl (unless you have a couple other languages under your belt, then consider using Programming Perl instead), followed by Effective Perl Programming. For all three books, make sure you're getting the latest edition.

Perl likes recursion just fine. A couple of notes:

• First, use File::Find. It's in the standard library. But if you insist on doing it manually (perhaps this is a learning exercise?)

• Use File::Spec->catfile, this will work on any platform (it looks like you're on windows, which may be the source of your problem - its path separators are different).

• Use lexical filehandles, e.g. opendir (my $dir, ...). You don't have to explicitly close them (they'll close when they go out of scope), and you don't run into global scope issues.

• use the 3-argument form of open(), it's safer. See perldoc -f open.

• I haven't tried the following code, but looking at the differences should get you going in the right direction.

  use File::Spec;

  sub check_directory { my ($path) = @_; print "$directory\n\n"; my $find = '<!--webbot bot="Timestamp"'; opendir(my $dir, $path) or die $!; print "Checking $path... \n" while (my $entry = readdir($dir)) { next if $entry eq '.' || $entry eq '..'; $entry = File::Spec->catfile($path, $entry); my $line_num = 0; if (-f $entry) { next unless $entry =~ /.html$/; open (my $file, $entry, '<') or die $!; while ($line = <$file>) { $line_num += 1; if ($line =~ /$find/) { print "entry at line: $lineNum\n"; } } } elsif (-d $entry) { check_directory($entry); } } }

  check_directory('D:\Public\ssnds')

Regarding Perl6, here's a couple things:

• See this guide: https://github.com/dnmfarrell/Perl6-One-Liners
• See this book: https://www.gitbook.com/book/kyclark/metagenomics/details
• One benefit of going with Perl6 is that the community is pretty close and tight-knit. So if you hang around for a couple of weeks, you'll basically be part of the "in" crowd.

I'd suggest checking out the first one-liner guide and seeing how you feel about it. I think Perl5 still has a good future. It's getting better all the time and it truly is fast (which can't really be said for Perl6 right now).

Here's something I wrote on Quora in response to a similar question:

> People who haven't looked closely at Perl often call it a "scripting language". This > phrase is rather loaded as it implies that Perl is a simple language that you can > use without learning much about it. This was particularly true in the second half of > the 90s when the world was full of people "learning" Perl from dreadful examples > like Matt's Script Archive. > > As a result of this, most of the Perl that people have seen over the last twenty > years was written by people who didn't actually know much about Perl (in many > cases they don't appear to know much about programming!) These programs are > generally terrible examples of Perl programming and contribute greatly to Perl's > reputation. > > On the other hand, good Perl, written by someone who understands the language > can be a thing of beauty. Used correctly, Perl can be one of the most expressive > programming languages around. > > But you need to take the time to learn it. That's where most people go wrong.

The sequel to Learning Perl is Intermediate Perl. The books are deliberately written to complement each other. There's also a third book in the series called Mastering Perl.

It would make sense to keep calling it "Learning Perl". In the current context, someone that's new to Perl, if they have no specific version number in mind, probably wants to learn Perl 5. Someone that wants to learn Perl 6 will know that they want to learn Perl 6.

Edit: typo

> I'd say it would be a good follow up once someone gets the basics down and wants to go back and reinforce the features of the language especially with modern practices

That was my goal. People who haven't programmed much at all before are better off with something like "Learning Perl" first.

I would suggest the O'Reilly books for Perl. "Learning Perl" and "Programming Perl" were the books that helped me the most when I first started. And once you get the basics, it doesn't hurt to get "Perl Cookbook" to see some interesting examples of doing certain things.

Whether I'm downvoted or not, I don't care, these are the things that helped me get started and helped me to learn the easiest. I also agree that using PerlMonks is a great place to ask questions. One thing that I have noted, however, is that Perl programmers tend to be a bit more cynical than the average.. so going on the IRC might seem helpful, but you'll spend a lot of time dealing with assholes.

I'd strongly disagree - the format is well documented, it's a task that Perl is well-suited for, and it'd be easy to break it up into a series of steps.

Try something like this to get an overview of how+where things are stored:

https://blog.angularindepth.com/become-a-git-pro-by-learning-git-architecture-in-15-minutes-9c995db6faeb

and the documentation covers the concepts in more detail:

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

You can compare your code directly against the equivalent git commands and rapidly build up a toolset. Much of git was constructed by shell scripts and Perl scripts originally!

If you google for Perl certificate you'll find a number of sources. There was one company that tried to set up certification a number of years ago, and asked the community to comment on their questions. Opinion was unanimous that the questions were outdated, incorrect, or only partially true. I don't remember hearing from that company again.

Here's what Randal Schwartz thinks on the topic.

In my opinion, certificates tell a company that a candidate has some degree of competence at some drastically limited subset of the CS world. You have certificates in Visual Basic or C# because many companies use the technology, and they want employees that function as interchangeable, disposable units. Perl has a limited market; the best companies use Perl, but unfortunately not enough employers fit into that category. So there aren't a vast horde of applicants who have done a programming course, once, and employers have a little time to pay attention to the applicants capabilities.

Actually, there IS a globally recognized Perl certificate, it's called CPAN. Write a module and publish it. Or write an application and put it on GitHub. (search for legrady on github.com to find me). Or write blog articles about aspects of Perl, how it resembles or differs from other languages, about things you've figured out. Blogs.Perl.org is one place to do it, or you can announce a blog at your own location, via http://ironman.enlightenedperl.org/. Explore other resources at https://www.perl.org/community.html. There's also IRC; become a regular participant / contributor.

Or, people could learn from something like Learning Perl.

But neither strict nor warnings is going to save people the hassle you are trying to avoid. Both of them require quite a bit of knowledge for the beginner programmer, and misunderstanding those things introduce other problems. The warnings mean almost nothing to people who are just starting, especially if they've never written a program.

But, students are bad at programming. That's kinda the point. By the time that someone is in a Ph.D. program, that should be a familiar feeling to them. They've encountered a variety of new subjects and had to jump into them. By that time, they shouldn't default to blaming the subject for their own difficulty. They've had experience with the competency of different sources and don't use a single source of information.

The problem more likely is that she's expecting someone who's not an expert to teach her something that even from the start requires some computer and analytic skills. For instance, very few students think to bisect a program to find the error, but without the chance to run into errors, they also never learn how to debug. I'd say debugging is a more useful skill to learn than the actual language.

I don't teach those things to the second day of a class, but then I also don't overload them with things I don't explain on the first day. Most Perl tutorials written by biologists I've seen go for minimal explanation to jump into using the language immediately for complex problems. That's the wrong way to learn a new tool, but it's pervasive in the natural sciences.

Modern Perl is a good instruction book that is up-to-date in style and best practices. Learning Perl is excellent and has a long tradition, but I don't think it's as current in style and practices. Effective Perl Programming is good, but I don't see it as a training manual.

The documents that are included with perl are free, and already on your computer, so very useful.

I've been a full-time Perl programmer for 12 years. I consider Modern perl Programming an excellent book. The classic Perl texts are Learning Perl, Intermediate perl, Programming Perl. They are great, bu have become somewhat dated; the standard Perl idiom has evolved, and the books haven't. Modern Perl gives you the current way of doing things.

See also Effective Perl Programming .. the book and the website ... http://www.effectiveperlprogramming.com/ for similar but different modern slant on Perl

I read a few chapters when it was on git and got a hard copy for Christmas. It's one of the best Perl books I've read. I would recommend it to anyone learning Perl as their 2nd book to read after Learning Perl. I've been programming Perl on my own time for about four years and have done so as a job for the last year. I could list out a few pages of things that I learned from Modern Perl, it would be more if I hadn't been reading every blog post by cromatic. I'm looking forward to the ePub version.

I've found the process of learning perl is obstruct with outdated sources that only teach bad practices.

As a basic introduction, O'Reilly's Learning Perl, Fifth Edition and Programming Perl, 3rd Edition. Get those editions since they cover Perl 5.10

But from that you might want to review with modern perl books; for instance, Modern Perl, Effective Perl Programming 2nd Edition, and O'Reilly's Perl Best Practices. Those recent books will guide you through the recent features, idioms, styles and syntax. Also the OOP with Perl, and how is used in the present.

There are tons of tutorials and guides, but most are outdated.

There is always irc.perl.org and #perl at irc.freenode.net; Perl mongers ready to answer any query. And by 'any', I mean anything.

I've checked the Google Analytics for the site and Hacker News is slaughtering it.

And thanks for the very kind words about the book! I appreciate it.

I tried from a Win 7 machine to Pfsense gateway and could only get it to work using icmp and running as Administrator

$p = Net::Ping->new("icmp");

From the perldoc Net::Ping:

>If the "icmp" protocol is specified, the ping() method sends an icmp >echo message to the remote host, which is what the UNIX ping program >does. If the echoed message is received from the remote host and the >echoed information is correct, the remote host is considered reachable. >Specifying the "icmp" protocol requires that the program be run as root >or that the program be setuid to root.

Perhaps a similar elevated credential requirement for Windows?

Update: That looks to be the case https://stackoverflow.com/questions/7687401/why-does-ping-work-without-administrator-privileges

> state of the economy

Of course, that explains it. The growth of other dynamic languages has suffered as well, starting in 2011:

http://www.indeed.com/trendgraph/jobgraph.png?q=perl,python,ruby,php&amp;relative=1

Perl was a victim of its own success. It is such a "hacker's delight" that many, many people discovered they could solve pretty hard problems without any background, just by teaching themselves Perl syntax. The problems came because Perl, more than any other language I've encountered, lets you write horrifically ugly code if you choose. Bad Perl code is worse than bad assembler code, it's worse than bad C, it's worse than INTERCAL. Good Perl code can indeed be a thing of beauty.

Python seems to be surging primarily because it does enforce some basic style and design rules -- so it's an easy language to teach. Pascal had a similar run in the 1980s, for similar reasons (compared to C).

For scientific computing: try Perl/PDL. It doesn't have as many specialized niche applications as Python, but it's far more general and powerful than Scipy/Numpy. Among other things, you can use Inline to write hotspots in other languages, right there in the middle of your Perl script. There's also a "Perldlpp" metalanguage that lets you write vector operators very concisely, and that compiles to C.

I see you've made the effort to actually look around a little. You seem to want a solid book. Sadly Programming Perl is not great. Modern Perl is essential reading, but it mainly serves to keep you from stumbling into traps laid by the decades old history of perl. Effective Perl seems to be more a "bag of tricks" book.

For a comprehensive "learn Perl with this" work, you want Ovid's Beginning Perl.

Iv just started learning about a month ago. I asked this question too. Chromatics Modern Perl and O'Rielly's Learning Perl were both suggested.

I am finding Learning Perl a lot more helpful after reading Modern Perl. Also if you are a beginner programmer then i think Modern Perl will be much more challenging.

I hope this helps a bit.

John SJ Anderson (@genehack) says a Static Site Generator should be the project you use to learn a new language, and I agree with his reasoning: https://www.slideshare.net/genehackdotorg/a-static-site-generator-should-be-your-next-language-learning-project

I'm surprised here that the comments are so defensive. 2 people are pointing out that "it's still growing" when the original post title didn't even imply otherwise. In a year, it's down from 30% growth to under 10% growth - a faster decline than the original increase from 10% to 30%.

And when I compare with other languages that I might be interested in moving to http://www.indeed.com/trendgraph/jobgraph.png?q=perl,python,php,javascript&amp;relative=1, I see that Perl is not trending in the same direction.

It might still be growing, but this is still making me uncertain about my job security in Perl, and also happy that I'm hoping to move to something with healthy growth in the future.

"Programming Perl" is more of a reference book than a learning book. I did learn using the 3rd edition myself (in combination with hanging around PerlMonks a lot), so it's doable if you have some programming knowledge already.

I learned with Programming Perl and Learning Perl, but I just bought Perl Cookbook (used) and learned a lot of stuff I hadn't learned before.

The format is especially good for a learner, since it addresses common individual problems.

Another source is to just google 'perl' plus a keyword or whatever else you want to know about.

Learning Perl, page 44.

It's an assignment. The population of @other is going to be copied verbatim to @copy.

To assign a reference you would write: @copy = \@other; # assign a reference of @other to the first element of @copy and clobber anything else there.

#!perl my @other = qw( foo bar baz quux);

print "assign like a boss!\n"; my @copy = @other; foreach (@copy); print $_ . "\n"; }

print "reference like a bad mutha fu-WATCH YOUR MOUTH!\n"; @copy = \@other; foreach (@copy) { print $_ . "\n"; }

$perl foo assign like a boss! foo bar baz quux reference like a bad mutha fu-WATCH YOUR MOUTH! ARRAY(0x826140)

OK, PSGI author here :)

> we should revisit the PSGI spec in tandem with implementing P6SGI much like Perl 6's spec has been written in tandem with writing the language.

I'm not sure I follow what you mean - PSGI and P6SGI isn't apple to apple to P6 spec to Perl 6 the language.

We did iterate over the PSGI spec by writing implementations for popular web frameworks such as Dancer and Catalyst. Actually I have those adapters working before calling the PSGI spec 1.0.

I don't think the spec is dated per se, but you could find some area where it needs to be updated, such as a non-buffered HTTP body read from the clients (some servers like uwsgi already do) or support for newer protocols such as HTTP/2, which wasn't around when we designed PSGI, which was a clone of WSGI and Rack.

Ruby folks basically have given up updating Rack to support H2 though, explicitly yielding others in the community to spin up some replacement. That's the approach I would take here as well.

See also: WSGI 2 proposals

A good example of why it's sad that the White Camel Awards ended when brian stopped running them.

But I've seen a post from Wendy somewhere today pointing out that DHA made a huge number of commits to the Raku codebase - most of them in documentation.

When this was posted on Hacker News, commenter smacktoward beat me to the punch with their comment, which included this bit:

> Writing an article about "the fall of Perl" that only incidentally mentions PHP, for instance, is a big omission. Insofar as Perl has fallen, what it fell from is the position of leading language for building Web applications. PHP is what pushed it out of that position, not Python or Ruby. If you want to write an article about the fall of Perl you have to explain how that happened and why, but this article attempts neither.

I couldn't agree more. While we can debate the fall or Perl (or not), any article that claims that Python is the main reason for a decline in Perl and entirely neglects PHP is just badly written.

As a whole, this article is basically a bunch of the writer's personal thoughts presented as facts, loosely supported by other "facts" like the (pure garbage) TIOBE index.

My favourite example:

http://www.google.com/#sclient=psy&amp;hl=en&amp;biw=838&amp;bih=874&amp;source=hp&amp;q=%25INC&amp;aq=f&amp;aqi=g5&amp;aql=&amp;oq=&amp;pbx=1&amp;bav=on.2,or.r_gc.r_pw.&amp;fp=3897923a35f9f5e8

https://duckduckgo.com/?q=%25INC

Mohammad S. Anwar in this week's Perl Weekly reminded me of the list of past recipients of the White Camel Award. These are all people who have been recognized for their non-technical work for the Perl Community in the past.

https://www.perl.org/advocacy/white_camel/

Now ask yourself this:

• why hasn't there been a White Camel Award since 2018?
• how many of these people have left the Perl Community?

I'd say the majority of these people have left the Perl community either directly or indirectly because of the toxicity of certain members, Subject included.

I strongly urge you to read the modern perl book (free)

http://modernperlbooks.com

Or, if you don't mind paying $33, Learning Perl is a quick and easy way to get going with perl doing exactly what you need, explaining how it works and is fast and easy to learn from the book. O'Reilly sells DRM free ebooks you can download.

http://shop.oreilly.com/product/0636920018452.do

It's not in a language per se, it's a data structure. The only name for it is "a perl optree". It's a tree that contains references to C functions (which do most of the work), the data that those functions need to execute, and previous/next operations in the control flow.

The book Programming Perl contains some reasonably good information about this stuff.

In a nutshell:

Having problems hiring Perl programmers?

Here's your solution:

• Step 1: Hire one senior developer. Splurge on them. Offer a salary worthy of a senior developer. Offer relocation aid. Actively try to woo them and look at it as an investment.
• Step 2: Hire some people who are just out of college/university and give them to your senior developer as their students.

Yes, your senior developer won't spend as much time writing code. However, they will both enjoy the opportunity to give on their knowledge and they will make sure as hell that good, reliable and tested code is being produced.

Keep in mind: Programming Perl is a craft. And any craft needs both masters and students to survive.

Check out brian d foy's "Perl traps for Python Programmers" http://blogs.perl.org/users/brian_d_foy/2011/10/perl-traps-for-python-programmers.html (And the comments). The contents are also in the camel book (Programming Perl, O'Reilly).

You might also want to replace: open (CURFILE, "<$toOpen") or die print $!;

with: open my $handle, '<', $toOpen or die $!;

And then user $handle instead of CURFILE.

You're also constructing the file path with unix and windows styles: if (-f "$directory/$file") CheckDirectory("$directory\$file");

Make up your mind or use File::Spec::Functions! ;)

A few minor tweaks/remarks:

1) Perl's building the regexp to match at each line because you're using a string. You might want to declare your pattern like this: my $find = qr/<!--webbot bot="Timestamp"/; # Build the regexp once Ideally you will even declare this variable outside the function like that the pattern will be built only once.

2) Can the webbot string be in more then once per file? If not then add a "last" statement after your print function otherwise the program is still reading the file for nothing.

3) Perl has a builtin line counter per file handle. You can use $. to get the line number. So you can get rid of $lineNum completely.

The OP is correct. It started out as perl and then shifted to C. See this bit in their manual from 1998.

> PHP began life as a simple little cgi wrapper written in Perl. I wrote it in an afternoon during a period between contracts when I needed a quick tool to get an idea of who was reading my online resume. It was never intended to go beyond my own private use. The web server where I had my resume was extremely overloaded and had constant problems forking processes. I rewrote the Perl wrapper in C to get rid of the considerable overhead of having to fork Perl each time my resume was accessed.

source

This graph, found here, showing the percentage of jobs with each of the major scripting languages is probably easier for people to read who are not used to reading graphs of growth rates.

It suggests that there are even more jobs postings looking for Perl expertise than there are openings for PHP, but the growth rate does look the most troubling. It might be interesting to compare the average salaries of the jobs for the four languages.

Anyway, it is also possible that more people are learning Perl with recent changes, and that they are therefore simply filling a shortage, rather than that there are fewer jobs. It's a bit of conjecture without more data.

Padre works great for Perl.

I do a heck of a lot of scientific analysis work in Perl/PDL, which predates Scipy and is still in many ways more powerful and elegant. It has a very nice built-in shell: though it is not as full featured as Padre, it does have support for multiline commands, line retrieval, and many esoterica that make life easier for that specific application.

My workflow consists of producing a script (in emacs) and pasting lines into perldl (the included shell that comes with PDL), or vice versa. At the end of a "chapter" of processing I have a script that I can run to reproduce the result. (Edit: the perldl shell also logs your work, so you can save your command history to a script -- but I prefer the control that text editor work offers...)

i suggest codefights.com , i'd been coding in perl for about a year. these little challenges made me far more nimble at my real projects. FYI there are other similar sites which can be found here https://alternativeto.net/software/codefights/

hope this helps, i wouldn't comment the "use strict" or "use warnings", it's helpful to force you to keep your code functional and clean,

Note: i did some some quick tricks to clean up your code... but not sure what you're wanting to do with it? (you initialize it so that your $ini, or my $SIR[2] is gonna be 5 all the time...)

edit: and ya, that for loop which infects inside is not gonna be executed as a consequence.. since you never get $population{$in}{'infState'} = 1;

DBD::Pg groks array types. https://metacpan.org/pod/DBD::Pg#Array-support

Use the standard ? placeholder and pass in your arrayref when you call execute(). DBD::Pg will flatten it to the PostgreSQL array syntax (just make sure the arrayref you pass in matches the dimensions of the column as defined in PostgreSQL). When retrieving data, DBD::Pg will automatically explode array type columns in the resultset to Perl arrayrefs, though as the docs linked above point out you can turn that off if you have a specific need for doing so.

If you're asking how to use placeholders for individual elements in a PG array type in your query strings - I'd be inclined to say there is probably a better, more PostgreSQL-y way by sticking with the built-in PG array operators and functions (http://www.postgresql.org/docs/9.4/static/functions-array.html) rather than getting yourself into a situation where you're mangling SQL strings with some unholy mess of sprintfs, joins, concats, and ->quote() calls to build the raw array strings yourself. Let DBD::Pg handle translation between Perl arrayrefs and PostgreSQL arrays, since it will do it consistently and correctly.

For reference, here's the leaked charter document. Leaked, because it isn't public!

The relevant quote:

>Community Scope

>Violations outside TPF spaces can still trigger consequences as they can have as much impact on our >community as behavior which occurs at conferences or TPF online spaces.

>This includes:

> - Violations at other conferences such as FOSDEM, PyCon etc.

> - Public communication or behavior between members of the Perl and Raku community.

> - Private communication or behavior between members of the community when it includes unacceptable behavior which is persistent or severe.

The O'Reily books I have always found useffull, starting at Learning Perl or something.

There is also this free book, which, I wish I would have known about when I started with perl.

Link: http://onyxneon.com/books/modern_perl/modern_perl_a4.pdf

Learning Perl might once have been good. However the bulk of it still assumes we're in March of 2000 and teaches bad practices (coding without strict/warnings, bareword filehandles as default). Please do not recommend it, and instead check http://perl-tutorial.org for current books.

Anything by "brian d foy" is your best bet. O'Reilly has four books that would be very helpful. The first three are a "trilogy" of sorts: Learning Perl, Intermediate Perl, and Advanced Perl. Finally, there is Programming in Perl, which is a massive (1000k+ pages) guide and is an incredible desk reference.

Upvote for the Llama/Camel , but the only reason I'd suggest not starting with perl is that is spoils you for other languages. If your whole career is going to be perl-based, then fine, but I find that whenever I have to write in something else, I miss a lot of perlish tricks etc. If it's a language I know well, then it doesn't matter so much, as I'm already aware of the limitations, but for somebody who'd only ever done perl, it may be a bit traumatic :) Learn C first - then perl becomes a treat.

(Having said that, I consider "Programming Perl" particularly to be one of the best books on programming out there. Get it.)

"Learning Perl: and "Modern Perl" to get the basics, the mechanics.

"Effective Perl", "Perl Cookbook", "Perl Best Practices" to get a feel for idioms.

Note that Modern Perl and Effective Perl are current, the others have some elements which are becoming dated.

Which operating system on the server side and which browser on client? There's a known issue in IE9 and Chrome incognito mode where it hangs the default Plack web server (HTTP::Server::PSGI) causes any requests timing out. https://github.com/miyagawa/Plack/issues/191

To clarify, after some harassment, I didn't want to be the point person for the White Camel Awards anymore. I suggested that TPF find someone else or give them a new direction, but nothing came of that.

I really wanted to highlight the non-technical work that underpinned the community, but every year it because more about people pushing for recognition of technical work and trying to tear down the work of others in favor of their favorite thing.

David was awarded his White Camel in 2001. Years later he took over administration of the awards before I came back and give him a break.

While python may be growing faster, Perl still has twice as many job offers. (Note that the scale of these graphs is 5 years.)

The examples aren't great - for example, in "write code that expresses intent": set_numeric_thumbnail_size talks about numbers right there in the name... but then it takes a string such as xsmall as a parameter.

Descriptive variable names can be useful sometimes, but $elapsed_time_in_days is on the other extreme. I don't think he noticed the disconnect here between the "variables are your nouns" and "here's a phrase that looks fine on its own". Does well-written prose repeat phrases such as "elapsed time in days"? Only when it's trying to make a point, and I suspect the key point in the code that needs this variable is perhaps not that the time is elapsed, and measured in days - as such this risks obscuring important semantics. Too much verbiage is not a sign of clean code.

"Comments are often lies waiting to happen" - the slide content would typically emphasise "document why, rather than what/how" instead.

anyway, I think the original 3-letter summary is actually pretty accurate - there are elements of useful content in here, sure, and it's hard to do an awesome summary of the topic in just 10 minutes. Overall I'd be inclined to point people towards the referenced "clean code" book and other sources rather than this talk:

https://www.safaribooksonline.com/library/view/clean-code/9780136083238/

Dare I suggest Perl 6 and Rakudo? ;P Certainly one of the bigger and more interesting projects, vibrant is debatable since most people around here are all doom and gloom. Plenty to do outside of the compiler too like writing tutorials or coming up with nice tools. Given native typed arrays are being worked on ATM Perl 6 integration with Jupyter might be fun, an equally good project to do with Perl 5 + PDL too. http://jupyter.org http://pdl.perl.org

Are you, perhaps referring to IEEE-754 floating point?

I used the accepted answer here when playing around with the network traffic for WoW. Unpack it with "L" and run it through that function.

As I look at it now, my sent data was put through pack("L", htonl(pack("f", $float)));so I'm not sure why that couldn't just be inverted for received data: unpack("f", ntohl(unpack("L", $received_data)));... there was a lot of blind guesses and trial and error with that project, so I wouldn't be surprised if it's nowhere near optimal.

> I for one plan to stay far away from attending or organizing any conference where TPF is involved, given this how they operate.

Do you have any idea how they operate? How much work has been done by people in the CAT team and on the TPF board to address these issues? How many people they have talked to?

I'd say: no, you don't.

Do you have suggestions for improvements? How it *should be done if it were up to you? Would you want to be a member of the CAT Team?*

I'd say: no, you don't.

So the Perl community should be a purely a "Lord of the Flies" thing? Everybody decides what they find acceptable, and if you disagree with that, you should just leave?

Well, I have news for you: many have already left because it is very much like "Lord of the Flies". And it pains me to say, as the recipient of the 2013 White Camel Award for Perl conferences that I have left the Perl community for the same reasons that are being discussed in the CAT report. There are only very few people in my life that I decided to not trust a word they say anymore: Subject is one of those few.

With regards to boycotting TPF: be careful what you wish for. At one point, everybody involved with TPF will have enough of it, as so many in the Perl community have.

And then who is going to organize just about anything, particularly in the US? The reason that TPF is organizing events is because there are no longer enough grassroots Perl users willing or able to organize Perl events. Think about that!

So, just saying "no" doesn't cut it. If you value the Perl community, you have to come up with something better. I have given up.

IF, and this is a very big if, i understand you right, you have a Perl script that can read data from the device, but you cannot get it to talk to your database. Meanwhile you have a PHP script that can talk to your database.

So if you really want to avoid setting up the Perl script properly, you can change it so it accepts parameters via @ARGV, prints the data, and then use PHP execution operators to run the Perl script and capture its output.

I've always been a fan of Perl books from O'Reilly. Programming Perl would be a solid place to start, then Intermediate Perl, Perl Cookbook, Advanced Perl Programming, and Mastering Perl.

Modern Perl is also good, and it's online for free: http://modernperlbooks.com/books/modern_perl_2016/

Although not free and not online, Learning Perl is an awesome book for learning Perl 5. Each chapter covers a few new concepts of basic Perl and has exercises at the end of the chapter.

Note that I wouldn't really recommend doing it this way. PerlMonks isn't as active as it used to be, and I don't think there's a good alternative out there (StackExchange isn't quite the same thing). I also had some previous exposure to Perl, but it was all in the style of the mid-90s Matt Wright's Script Archive, and I don't usually count that.

The link /u/mghicks gave you should be a good way to learn. And you didn't waste money; Programming Perl is a handy thing to have around.

I used Programming Perl as a reference quite a bit as I was learning (with Learning Perl), and afterwards while I was researching how to do things. I do enjoy books more than reading websites, things just stick in my head better.

One you probably should buy is the Perl Cookbook. I learned more about Perl from that book than anything else - learning what those crazy one-line code segments actually did, and learning how to do them myself...

The Modern Perl book is good if you have some experience programming, but it's also a bit dense.

If you are just starting out in Perl land I would consider starting with Learning Perl; it’s a quick read and not as dry as most books about programming, a nice very gentle introduction.

Modern Perl is a good next step and Programming Perl is good to browse (I at least could not read it cover to cover, but used it as a reference while writing code).

Yes, that's a good example; if you (or someone else) can ask himself/herself "Why didn't he/she ..." a comment should be added.

Another one: when I implement an algorithm I add a comment that gives the source of the algorithm (e.g. "Introduction to Algorithms, 3rd edition, p455-457").

If you already know how to program well in another language, I highly recommend "Modern Perl". You can read my review on Amazon for more details.

If you are generally new to programming, "Learning Perl" is the way to go.

For learning Perl, the standard text is "Learning Perl" (sixth edition is the current one). But "Beginning Perl" by Curtis Poe is very good too (an earlier book, also called "Beginning Perl" by Simon Cozens is available for free online, but is looking a little old now).

When you get a little further into Perl then "Programming Perl" is the standard text (make sure you get the 4th edition). "Intermediate Perl", "Advanced Perl", "Higher Order Perl", "Modern Perl" and "Effective Perl Programming" are also all very good.

"Perl Best Practices" is great, but a lot of its advice is looking a little dated these days. In particular, its chapter on OO programming completely ignores Moose (which is unsurprising as Moose wasn't around when the book was written).

Programming Perl 4th Edition was just revised Feb 2012.
I'm in the same position as OP and I have found both Modern Perl & Programming Perl great resources along with asking smart people who already know Perl to review my code.

I think your worst enemy is strictly reading. You should have a text editor at the hand when reading, and after learning about an idea immediatey make a small toy script to show what you've learned. Name them something close to what they're doing (inputandoutput_stdin.pl for example). This is for you to go back and read, don't use names like "stuff01.pl" or "test.pl". Now when you need to rethink about a concept you can go to your code example and immediately see it. You should be filling up your gist on github.com (or something similar) with code snippets and asking people to review things you don't understand.

With any task, but especially a skill like programming, there is absolutely no substitute to "seat time". It may take you one excercise or twenty to get a concept, but if you implement what you're reading about, however trivial it may feel now, it will allow you structure and implement harder concepts that have otherwise been too large to conceptualize. Go at your pace, and keep it fun.

Also: your programs should all have:

use strict; use warnings;

On all programs for now! Learn it the hard way, you'll be a better person for it.

I would definitely back this up. Not only is it a good primer into Perl, it also discusses numerous modern patterns and methodologies that will serve you very well. I was always a fan of Learning Perl and Programming Perl for reference, but they have both been largely superseded or used for reference as a result of this book for me.

A good web framework would certainly be another compelling reason to try out Perl 6 for your next project. It would probably attract a lot of potential users. However, I think that, at this stage, most people trying it out would -- given the circumstances as of today -- soon leave Perl 6. The reason is that there are no perldocs for it, nor is there a Perl 6 "Camel book". Off the top of my head, there are:

• the Synopses (dense and deep -- not suitable for those wishing to learn Perl 6),
• a number of blog posts (see perlgeek's 5-to-6 articles, also szabgab's and others' posts),
• two holiday seasons' worth of advent calendar entries,
• tons of rosetta code examples,
• and even the beginnings of a book covering some basics,

but there are no real quality docs anything like what Perl 5 has got. And learning Perl 6 by asking endless questions on IRC is not optimal.

If Randal wants to help bring in new users, he'd have a far greater impact writing the next "Camel book" (Butterfly book?) than he would writing a web framework. (Besides, it sounds like a Mojolicious port will make it over at some point anyway.)

Randal wrote the original Learning Perl Oreilly book and the original Camel book. He's written a huge number of highly-regarded magazine articles. Countless detailed and informative replies on Perlmonks. He's easily one of the top 4 or 5 best writers in the Perl community, IMO.

Actually Moose has slowed down enough and core has sped up enough that I bet there isn't really an issue here as long as Moose were dual-life.

I would never want Moose in core because you could do so much better than Moose if you had access to core. This is why Stevan is currently exploring a first-class MOP for 5.16 (https://github.com/stevan/p5-mop).

There are also a half dozen things I'd put into core before Moose, but really putting things into core isn't the hard part. Elegantly deprecating things from core is the hard part. How do you handle that people expect things like CGI.pm to just be there?

You have Javascript disabled, I guess? It seems that the syntax highlighting is done client-side, and for some reason the highlighting code also applies the correct font.

I opened an issue on GitHub for you: https://github.com/CPAN-API/metacpan-web/issues/39

Perception. Many people think 5.8 and 5.32 are similar, even though the releases were 18 years apart. Most people cannot name the version bundle you need to "use" to get certain features, like __SUB__. Thus my proposal: https://dev.to/grinnz/perl-7-a-modest-proposal-434m

I'm not sure if you were around before they invented "late static binding".

But nothing about needing it, or the reality of the nature of PHPs OO after adding it, strikes me as "Right"

Everything about this page just reeks of failure.

http://php.net/manual/en/language.oop5.late-static-bindings.php

Two courses I've run at the London Perl Workshop.

• Modern Core Perl covers Perl 5.10 to 5.14
• Modern Perl Catch-up covers Perl 5.16 to 5.24

I use the Dark Sky API directly.

https://darksky.net/dev/docs

The JSON returned is really easy to work with, but there's a Perl wrapper for it here ..

http://search.cpan.org/~martyloo/Forecast-IO-0.21/lib/Forecast/IO.pm

.. if you can't be bothered to parse the data yourself. The module really doesn't do very much.

Example data returned by the API ..

{ "latitude": 51.4764332, "longitude": 0.002573, "timezone": "Europe/London", "offset": 1, "currently": { "time": 1501304924, "summary": "Partly Cloudy", "icon": "partly-cloudy-day", "nearestStormDistance": 95, "nearestStormBearing": 146, "precipIntensity": 0, "precipProbability": 0, "temperature": 13.39, "apparentTemperature": 13.39, "dewPoint": 12.71, "humidity": 0.96, "windSpeed": 4.3, "windGust": 9.3, "windBearing": 258, "visibility": 15, "cloudCover": 0.49, "pressure": 1008.34, "ozone": 318.09, "uvIndex": 0 },

.. followed by forecasts by the minute, hour and day (up to 5 days IIRC)

Generally, I skip the capturing part if I have access to the API. I'll use SoapUI (http://www.soapui.org/), point it toward the correct end-point and let it stub out the requests. I'll get my payload right in SoapUI and then convert it over to SOAP::Lite.

When I do need to see data going back and forther (generally HTTP calls) I'll bust out Fiddler, a local HTTP(S) sniffer: http://www.telerik.com/fiddler

But there is also other good info in this thread including an alternative to SOAP::Lite.

Ok. So just lose all the dtterm from the front of your command. So it becomes:

ssh -t <servername> /usr/local/bin/sudo su - oracle ...

That will log you in to the remote server, run the command and then log off from the remote server.

And if you can control the ssh keys for the oracle user on all of the remote servers, then you should be able to configure things so that you can load up the correct key on your local server and then connect as the oracle user on all the remote servers without a passwords, using a command like

ssh -t oracle@<servername> ...

Here's a good starter article on how to set that up.

I've said this a few times on here. there are websites made exactly for this. https://alternativeto.net/software/codefights/ . i use codefights.com (FYI i dont work for them) , i'd been coding in perl for about a year or so. these little challenges made me far more nimble at my real projects. As for scripts, if you using *nix, i recommend getting comfortable for Bash too.

The local server would handle queuing and retrying, but typically you would configure to deliver through a "smart host".

See https://www.linode.com/docs/email/postfix/configure-postfix-to-send-mail-using-gmail-and-google-apps-on-debian-or-ubuntu/ for example.

You're only partly correct. What you wrote used to be accurate, but now you also have the aforementioned Lumo and Planck if you want to run ClojureScript directly, without the whole transpile phase. They're standalone tools that can run cljs directly, with no need for Java or Clojure to be installed.

Planck's completely standalone, whereas Lumo requires node.js to be installed, but can also import and use node modules, and using either allows you to run cljs scripts via shebang just like you would Perl, Ruby, Python, or even Clojure.

In fact, if you restrict yourself entirely to Clojure and avoid calling out to the host (JS or Java), it really is as simple as replacing the shebang and calling it a day. The caveat there is that Clojure (and thus Clojurescript as well) is made to interop with the host platform heavily, so the more complex your program, the more likely it is you'll have to resort to interop. (Though there is a way to define functions so that they run different code depending on platform, which means you can write mostly shared code with a few wrappers.)

The dot matches any one character. The asterisk means the dot matches zero or more characters.

Check out http://regex101.com/ While it doesn't have a specific option for perl, you can still plug most regexs into it and it will give you exacting details on what each part of the regex is doing. For example, on your last expression, it tells you the following:

/-d(.*)/

-d matches the characters -d literally (case sensitive) 1st Capturing group (.) . matches any character (except newline) Quantifier: Between zero and unlimited times, as many times as possible, giving back as needed [greedy]

> There is already IDE support for Perl - but feedback in the survey shows that we need a page on https://www.perl.org/ 

This feels like a huge miss. The community provided feedback that IDEs are generally not that good with Perl, and their response was essentially "No, you're wrong; IDE support is great and you just don't know".

OK, several reasons:

• one of the core committers has a rough time in real life. And that is a bit of an understatement.
• as chromatic points out, the graph only measures commits in the master branch
• lots of work happens in the nqp repository (also in branches), in preparation of moving to a new meta object model, which is based in nqp (nqp is used to build rakudo, so it makes a lot of sense to stuff it there, and later import it in rakudo. That way it is also available for other nqp based projects)

fzf already offers generic file listing, so the trade-off matrix is:

File listing for the prove use case described in the blog post:

• fzf -m -q '^t .t$' goes to stdout
• prove -lv <ctrl+t> goes to readline with the filter inserted from klipper if needed

There is no "Programming Perl 6" book. (Yet; Larry wants to write it eventually).

> Absent that, I'd hoped to find a book on Perl 6 aimed at Perl 5 programmers.

Migrating to Perl 6 by Andrew Shitov targets exactly this audience. Enjoy!

No one has yet mentioned the "bible", Programming Perl.

Presumably that's because it's too comprehensive, too advanced, too long (current edition is 1200 pages)? Or is there some other reason?

I think the latest edition is the 5th edition published in 2012. I recall hugely enjoying reading earlier editions (1st and 3rd iirc), even when not near a computer, back in the day.

Oh I see. Well in that case, I'd recommend you'd rather dig into more abstract, theoretical books, whatever the language, and not so much the hands-on guides. Stuff like the "SICP" book, long title "the Structure and Interpretation of Computer Programs", which is in Scheme, a Lisp dialect, but the code is incredibly compact and readable. In Perl I could recommend "Advanced Perl Programming" from the O'Reilly collection (I prefer the original version to the rework), and "Higher Order Perl" by M.J. Dominus. Books that make you think, rather than rush to a keyboard to try it out.

I thought Perl Cookbook was a great book, but haven't opened my copy in a decade and a half. Rather, look for a copy of Perl Best Practices, which itself is getting a bit long in the tooth.

Programming Perl of that vintage is also only interesting for historical interest, as I doubt there's anyone that's locked into Perl 4 and is looking for a new maintainer. I would recommend Modern Perl for those looking for something on the same subject, though.

Great find!

I think this is the best answer. It is regrettable that we have a de facto fork taking place, but most users -are- going to still want to learn Perl 5. It follows that Perl 6 books should say, "Learning Perl 6" rather than give Perl 5 focused titles the suffix.

Learning Perl would be better an geekuni has the best internet tutorial I've seen it nothing like code academy you actually get your own VM you ssh into it gives you a quick intro in each section then let's you come up with your own solution teaches you how to look through perldocs ... I think the first three days are free give it a try I recommend it to any learning Perl after already having some programming experience.

In the beginning of the book "Programming Perl" there is a section on its philosophy comparing to "natural language". The key in natural language is we speak/write what we thinks. Speaking or writing is basically thinking it loud, therefore, natural. When we read or listen, we reiterate what we heard or read in our thinking.

In trying to imitate natural language, while getting the efficiency, Perl also get the problem of natural language. Our natural language is highly context dependent. The context is often complex, and not easy to fully confine. So it leads to ambiguity or surprises, when some aspects of the specific context is missing or mixed up.

Perl is of no problem for whom is experienced in Perl who have the context of Perl built into subconscious. This is more true in the old days when Perl's culture is wide spread, and people have no problem accept Perl's context. It is a problem now as most new programmer are thinking in OOP, functional, or whatever dogma they are being bombarded. If it is true natural language, we would all have changed our slangs and styles and moved on. But since Perl is still a programming language bounded by legacy, it is stuck.

So if you are willing to look past the difficulty learning perl and willing to put Perl's context into your subconscious (through effort), Perl is really the only expressive, effective, flexible, natural programming language out there. But if that is not acceptable, then forget about Perl.

I really found Beginning Perl to be much easier to follow and learn over Learning Perl.

Another suggestion is the http://perlmaven.com/perl-tutorial site. There is a video series as well that helped me get started with Perl.

If you had used those 20 hours to read a book on Perl, like "Learning Perl" you would've had no problem to make it work in 5 minutes in Perl as well.

This has always been Perl's main problem, in my opinion. People starting to program in it because "It's a programming language! I know this!", only to get utterly confused and often ending up writing the kind of code that gave Perl it's for a large part (again IMO) reputation of being unreadable. Cargo cult coding at its best.

Perl comes with documentation, very good at that. Use perldoc perldoc (at the command line) to get started.

As for qw(): what parameters do you want it to take? Maybe you're looking for split? (See perldoc -f split).

I don't think the language should be changed just to teach new people. They can learn the tiny subset they choose to start with and grow from there. As well as Modern Perl mentioned already, Ovid's Beginning Perl, and Learning Perl are all good places to start learning.

I think it is probably better to put forth some collective effort to help everyone see what is and can be built with Perl ( E.g. Built In Perl ) as well as working to get in more places such as repl.it.

I think showing new people something like:

perlcritic -theme pbp --stern

from the beginning would probably be pretty useful in the long run.

Something else to add, the Beginning Perl book starts off with CPAN whereas other books don't touch this until much later or not at all. I personally felt this really brought up how powerful Perl really is. Also the examples given in the book are much more real world where you can piece together something handy just from the chapter questions.

Learning Perl is a good book as well but didn't feel it was as quick to get you started on real work.

Ironically, the O'Reilly book with the same name as your post is one of the best ways to start.

Although if you are comfortable with basic programming concepts, you can probably jump to Programming Perl.

There is no quick path. But you can pick a fast path or a slower path. The fastest path is to pick a good book -- the old hands such as "Learning Perl" and "Programming Perl" are a bit dated by now, but the style taught there is still the majority of Perl. I have not read Perl-related books for over 10 years, so you should probably go with /u/TomDLux's suggestion.

I'd say that it took me about 6 months to feel that I had a proper handle of Perl, and for many years later I was still surprised by the behaviors of the various builtins as I used. Some things you guess based on what they seem to be doing, and guessing wrong leaves you with subtle bugs that can take a long time to understand. It is a sad fact of life that virtually every built-in of Perl has some weird quirk that you just won't know about until it bites you somehow.

When I started using Perl after programming in other languages (C, AREXX, Amiga E, various BASICS), I picked it up haphazardly. A few years later when I came back to Perl after having not done a lot with it, I picked up the camel book (Programming Perl) and read it. A world of difference in how I understood and used the languages. Since you've done some programming, you may be OK skipping Learning Perl (which is also a good book), or you may want to give it a shot, anyway. I think Modern Perl is also being recommended a lot lately, though I haven't read much of it yet, so can't say.