sub function_name
    {
        my ($var1,$var2..) = @_;

    }

There's a few Perl programmers at work who end up using just a bunch of global variables instead of doing pass by reference or returning values from subs.

sub do_something { # modify %my_global_hash }

It's just strange working with Perl after working in more OO languages. But, like you said, Perl adapts to your style. I want it more like other languages I've written in, whereas the people I work with don't.

Getopts::Long is amazing for parsing command line, and I don't know how I would work without being able to do the inline if and unless statements.

There are other modules out there like this, including one that bakes it into Moose methods. This also highlights a cool Perl feature: hack able syntax.

https://metacpan.org/module/Method::Signatures https://metacpan.org/module/MooseX::Method::Signatures https://metacpan.org/module/Method::Signatures::Simple

and many more. In this case, there might be too many ways to do it.

While writing Perl one liners it might become difficult to fit in the parameters in the usual C based function implementation syntax, in such cases this might turn out useful.

Let us not forget sysadmins use Perl a lot on the command line.

Once you realize that the control structures flow like an English sentence, once you grok that, the language simply gets out of the way. It's not bound to an ivory tower of a certain paradigm. It's a human language. Sure you can write Perl that's almost unreadable, but you can do that in many programming languages, and you can do it in real human languages. Written well, reading Perl is like reading beautiful poetry.

Case in point, I once wrote a program in Perl, about 30,000 lines of code (which by Perl standards is relatively large, a Java port ended up about six times as large), then didn't see it for 2 years. I was asked to guide a team to port the code to Java, I sat down one afternoon, and just read the code like a book. After that I almost never had to refer to the code again, and guided the team through the rest of the porting process. I knew it like I had just read a novel. Cause and effect was obvious, the bundling of the chapters (modules) made dramatic sense, and when I had to refer to the code to show it to one of the Java devs, it took seconds to find the code segment in notepad of all things.

Very little boilerplate, the best integration of regexes in the industry, yet still powerful enough to write major sites and applications in.

Downside: it ruined me as a developer, all the BS you have to go through in other languages to just get something done seems like such busy work. I ended up writing a set of libraries in C++ to handle lots of things in a perlish sort of way, typeless primitives, perl style containers, etc. But at the time C++ didn't have the same kinds of sentence-like control structures and simple regex matches always became a dozen lines of compiling regexes and then matching, and then iterating some data structure to get at the results. Painful.

Java became intolerable. I remember the last time I sat down to write something in Java, spending hours hunting through the standard library documentation thinking "this is bullshit, I shouldn't have to create xyz minor feature from whole cloth, it's got to be in the standard library, for fuck's sake Java has 3 gui frameworks and I have to parse a csv file by hand!!!"

According to Ohloh, LedgerSMB has 54k lines of Perl code. The quality of code ranges from abysmal (mostly inherited code from SQL-Ledger, things like some_func(\%config_has, \%$object)... \%$object? wtf?) to code that I am actually thinking is starting to look very elegant, even if it isn't a popular way of doing some things.

I find for me the boilerplate is all POD suff. Very little boilerplate in code.

I think a big downside though is that some developers are uncomfortable with the flexibility. They want to do Perl the Python way, or the Ruby way. This leads to code that's hard to follow very fast....

I came to the Perl party a pretty late. But Perl is so much like Emacs. Once you learn it well the productivity gains are exponential.

Once you are familiar with the language to a level. The program just flows out naturally even as your thinking. And yes to mention somethings in Perl make it so easy for that happen is really Larry's genius to build such a thing.

This is also what enables a person to write useful applications in very little time, while avoiding most of the cruft traditional languages have.

The surprising thing is, most people don't know about this. But when they first encounter it literally hits you like a lifelong addiction.

I do a lot of innovation at $dayjob and most of the times people think I'm a genius or super productive. But, its only that Perl enables me to do stuff so quickly it often looks like magic to people around.

If you're coming back to perl, read Modern Perl. Then learn Moose and its ecosystem. That will get you about 90% of the way to writing good, maintainable perl. :)

some systems, such as human and computer languages, contain a minimum amount of complexity, and that attempting to "push down" the complexity of such a system in one place will invariably cause complexity to "pop up" elsewhere.

Take for example the given-when syntax in Perl - http://perldoc.perl.org/functions/given.html

It really works hard enough to work as a switch statement with smart matching - http://perldoc.perl.org/perlsyn.html#Switch-statements with the adapting to the user intention.

I have always wondered how the Perl will evolve in the future. I see it will look more and more like Perl 6 adding features to make the magic look spectacular and amazing. We are already seeing Moose and Moosex and various other modules developed using Devel::Declare and the amazing stuff that they can do.

By working to match the user intention, the programmer generally can build the program in his head even while he is imagining the features.

Overall the greatest power of Perl that I have seen is, You can start your text editor and really build things as you think. Unlike many languages where you need a IDE which 100's of MB's heavy or you have to continually bother dealing with piles and piles of verbose code which often requires hours and hours of effort figure out what's happening underneath the layers.

I just wrote it as things were flowing out of my mind.

There are likely to be mistakes.

And after all, its a comment.