
Dwindling CPAN Releases - perlancar3
https://perlancar.wordpress.com/2019/08/01/dwindling-cpan-releases/
======
leejo
I'm an author on CPAN who pushes one or two releases a month[1]. I'm actually
surprised the number of uploads is still as high as it is, and a few thoughts
struck me about the graph:

1) Most long time libraries have pretty much reached stability and the (still
relatively high) backwards compatibility promise of perl5 means they don't
have to be updated to support changes in the language, which still has
releases every year.

2) The quality of uploads to CPAN is of the form of solving more complex
problems or interfacing with core Unix/network/internet/lower level lib stuff
stuff - you don't see so much of the leftpad type modules on CPAN.

3) It definitely feels like the number of authors has shrunk significantly,
even though the graph suggests that has stayed relatively level. I suspect
there's a long tail of active authors and most signups never actually upload
anything

4) The biggest problem now is finding modules for newer APIs - I wrote some,
including for more well known services such as GoCardless and Monzo

5) Holy crap, the graph covers almost 24 years of uploads. You will probably
see the same pattern in Python, JS, Go, and so on if you come back in an
equivalent number of years - the most common problems get solved first, and
libraries uploaded for those.

6) The graph covers uploads to CPAN, I'd guess a far more important one would
be downloads from CPAN as that will probably give you more information about
the relative level of use of the language.

[1] [https://metacpan.org/author/LEEJO](https://metacpan.org/author/LEEJO)

------
roryrjb
There's so much negativity in this thread. I think that a big part of Perl's
decline is exactly because of people's attitudes. I don't actually write any
Perl now, but to me it's a beautiful language, I always enjoy working in it.
You can abuse it in the wrong way like every other language. If I was to
suggest using it in the day job there would be uproar probably. But just
because I like Perl doesn't mean I want to write everything in it, use the
best tool for the job and sometimes the best tool is Perl.

~~~
cheeze
Prel is great and has an important role, even today.

That being said, I'm a professional dev and we own a decent amount of perl.
That codebase is by far the most difficult to work in out of anything we own.
New hires have trouble with it (nobody learns perl these days). Lots of it is
next to unreadable.

I agree that like any other language, perl can be written well and can be
written poorly. That being said, perl makes it _really_ easy to write
something poorly, in contrast to something like python which is a bit more
rigid and tries to have one right way to do things.

I still use perl pretty extensively for little one liners, but at this point
we are actively trying to get rid of as much perl that we own as possible. We
find that rarely writing anything longer than 10 lines should be done in perl,
if only from a readability and maintainability standpoint.

I love perl. It was THE game changer for many many years. But perl is falling
out of fashion quick.

I'd have no problem working in the language with some very rigid guidelines
and a bunch of experts.

But the reality is that nobody is hiring perl experts, perl experts are
becoming more and more scarce, and most new hires have a bit of experience
with py or rb. I dont dislike perl, I'd just argue it's almost always the
wrong thing tool for the job these days.

In a previous life I worked at a large E commerce company. You've likely
ordered from them. Pretty much _everything_ ran on perl/perl Mason for over a
decade. At that time perl was the cool new thing that everyone wanted to pick
up. Now (or when I left a few years back), most of that code represented a
liability if it needed to be changed.

IMO this is just the cycle of a programming language.

I remember reading Spolsky articles where he talks about VB6 like it's some
shiny new amazing scripting language, akin to python 10 or so years ago. But
alas, time moves on and so do most programmers.

~~~
anomalizer
I've gone from finding perl an absolute joy to program in circa 2005 to now
(2019) where I wouldn't touch it with a barge pole. The sentiment seems pretty
natural and common.

------
hobojones
I work on a large, legacy codebase (the oldest modules date from the mid-
nineties) that's slowly being rewritten from Perl into Python. A handful of
developers have been involved with the project from the beginning. Looking at
the long term contributors, readable or un-readable code seems to be more
about the person than the language. Unsurprisingly, the person who produced
the most unreadable, unmaintainable code is now doing the same in a new Python
only project.

I've always tried to look at programming in a similar manner as writing
research papers, your ideas are no good if no one understands how they're put
to paper. Explicitly stating your intentions is better than assuming the
reader knows the subject matter. If something is clever, overly-compact or
your reviewer expresses confusion, rewrite it or at least spend an extra line
or two in explanation.

At the language level, I miss Perl's handling of regexps and shell commands
(which consist of large amounts of this codebase). Python requires a fair
amount of overhead to handle both and always feels a little clunky. While I'm
far more fluent in Python, I typically reach for Perl when needing to quickly
handle log files, automate shell tasks, and prototype ideas. On the flip side,
now that Python supports type hinting, function signatures are much more
valuable, and overall I feel I can write far more robust tests in Python than
Perl. Given that the direction of the project is to move from a collection of
one-off scripts that just kept on growing to a tested, maintainable, modular
codebase, Python is the better choice.

~~~
alexpotato
> Looking at the long term contributors, readable or un-readable code seems to
> be more about the person than the language. Unsurprisingly, the person who
> produced the most unreadable, unmaintainable code is now doing the same in a
> new Python only project.

I would totally agree.

I learned Perl after first learning Basic(and Visual Basic) then Java.

Coming from Java meant that I always tried to use clear variable names, good
comments, broke my code into small and simple functions etc. I repeatedly had
people say to me "Wow! I didn't know you could do that in Perl!"

A lot of Perl's bad reputation came from sysadmins and other busy folks who
either weren't familiar with good syntax or were in a hurry and basically were
playing Perl Golf to get things done quickly. This is probably where the line
"Perl is a write only language" came from.

I will concede that Python and it's forced indenting leads to much easier to
read code for beginners. That being said, trying to understand what's going on
with advanced Pandas usage written by Numpy wizards is no walk in the park
either.

I also totally agree that the Perl one liner is still my go to even though I
do everything else in Python these days.

------
gkfasdfasdf
I still use perl for handy one liners on the command line. E.g. I had a 1 GB
log file where I wanted to generate a histogram of the intervals between
certain log messages. I used a perl one-liner to extract the timestamp via
regex (regexs are perl's bread and butter), calculate the diff between the
previous timestamp (easy because of auto string => double conversion), use the
diff value as a key in a hash of counters (autovivification really handy
here), then print the hash at the end with sorted keys using the Data::Dumper
module. Took me all of 5 minutes to write. I don't write Perl often but I am
thankful that it exists.

~~~
markoman
I'm an occasional perler myself and I bet that others or myself would find
that code you mention to be useful, at least for the black book of snippets.
Would you mind pasting?

~~~
gkfasdfasdf
Here is the command I used (added linebreaks for clarity):

    
    
      rg '<filter pattern>' <logfile> | \
      perl -MData::Dumper -n -e '
      m/\d{2}:\d{2}:([\d.]+)/;
      if ($last) {
        $diff = $1 - $last;
        print "$diff\n";
        $hist{$diff} += 1;
      }
      $last = $1;
      END {
        $Data::Dumper::Sortkeys = true;
        print Dumper(\%hist);
      }
      '

------
_rrnv
Consider this: Perl codebase is reaching perfection and no longer needs
releases. After this, we get eternal Perl ;)

~~~
trabant00
From a experienced linux sysadmin point of view perl5 is as good as it gets.

I've been searching for alternatives for about 10 years now, at first because
my novice self was heaving headaches reading other people code and even my
own. I hated perl but I hated everything else even more as I came to know
them. No autovivification? Some assignments copy the data and some create
references and you need to memorize the conventions of which does what? 3x to
10x lower performance? My program crashes because of white space? Fuck that!
Back to perl5.

I'm sorry to say nothing can replace perl5 for me even now in 2019. I wish
something would come along even if it takes years. We need alternatives and
competition, perl5 will get too old at some point and 6 is... I don't even
want to go there.

~~~
SmirkingRevenge
Autovivication seemed like a great feature to me, back in the day, when I was
getting started with Perl. Working with similar data structures in languages
like Python always seemed like a chore.

I had heard a few perl monks criticize it a bit, as an "end run around _use
strict_ ", but I was kind of dismissive. It turns out, that's a really apt way
to describe it. It basically tosses the niceties of _use strict_ out the
window, so long as its a hash. And sooo many things are hashes/hashrefs in
Perl.

The first time I wasted a day tracking down a bug that turned out to be a well
hidden typo in a hash key assignment, changed my mind. Well... maybe the third
time.

~~~
joosters
FWIW, you can 'lock down' a hash so that reads or writes of non-existing keys
will cause a fatal error. Not only does this stop autovivification on 'writes'
to a hash, but it will also help catch typos in your code just reading from
the hash: e.g. if you accidentally wrote

    
    
      $foo = $bar{Autovivication}
    

instead of

    
    
      $foo = $bar{Autovivification}
    

in your program, it will abort instead of returning an undefined value :)

See Hash::Util for details.

------
nkozyra
Perl is the language I once understood when I used it everyday but now look at
with utter confusion. It's definitely not a casual language.

As a comparison, I peeked at some Delphi/pascal code I'd written and a book a
few weeks back and it was still parseable by my brain years later.

~~~
tootie
No languages are casual. I wrote Perl for about 5 years and was super
productive with, but haven't looked it for quite a while. Most energy these
days goes into JavaScript/node and it devolves into gibberish really, really
quickly. The community really dove into the punctuation-based syntax,
preprocessors and meta languages head first and created a real Frankenstein.
And they'll complain that Java or C# are too verbose and slow to work with.

~~~
futureastronaut
> The community really dove into the punctuation-based syntax, preprocessors
> and meta languages head first and created a real Frankenstein.

More is on the way. Github issue thumbs up-driven development means it's the
new C++ kitchen sink.

------
eruci
There is more than one way to look at it.

I've been coding in Perl for 20 years, I'm a CPAN author [1] and I just
published my third CPAN contribution yesterday.

I've written over half a million Perl lines of currently in use enterprise
cloud software[2] and I'll keep coding in Perl because I don't like the big
snake dictatorship of "There should be one — and preferably only one — obvious
way to do it."

[1] [https://metacpan.org/author/ERUCI](https://metacpan.org/author/ERUCI)

[2] [https://aws.amazon.com/marketplace/seller-
profile?id=434e986...](https://aws.amazon.com/marketplace/seller-
profile?id=434e9862-6909-489d-8159-669bdb38f724)

~~~
MichaelMoser123
"There should be one — and preferably only one — obvious way to do it."

That is a python design principle
[https://en.wikipedia.org/wiki/Zen_of_Python](https://en.wikipedia.org/wiki/Zen_of_Python)

Now there are multiple (sometimes very confusing) ways to import stuff in
python, so I am not quite sure if this principle is being followed.

[https://realpython.com/absolute-vs-relative-python-
imports/](https://realpython.com/absolute-vs-relative-python-imports/)

~~~
cure
The other place where this principle is completely ignored is when it comes to
Python packaging, which is a complete and utter disaster.

There are many different ways to package Python, none of them are feature
complete, and the result is an absolute maintenance nightmare for those of us
who have to maintain tools that have Python dependencies.

Perl got packaging right, there's one way to do it, and it just works!

~~~
perigrin
There isn't one way to do it in Perl (EUMM, Module::Build,
Module::Build::Tiny, Module::Install etc), we just tried to make sure that
they all interoperated cleanly. And we have things like the Toolchain Summit
to make an emphasis on that.

~~~
cure
I stand corrected, thank you :) Clearly, you succeeded in your mission since
it feels like there's one way, and most importantly, it 'just works'. Many,
many thanks to you and everyone who made that happen!

------
iamnotacrook
I used Perl for a bit but switched to Python because I was finding it harder
to work out what some code I'd written a year or so ago did than to write it
again, a problem I don't have with Python.

~~~
isostatic
I used python for a bit but switched to Perl because it

1) Works

2) Is ubiquitous

3) Is stable

4) Is normal (semicolons, braces etc)

~~~
unmole
> 2) Is ubiquitous

On which systems do you have Perl readily available but not Python?

~~~
isostatic
Which version of python?

Perl documentation online applys to versions of perl that are installed.
Python stuff is all bleeding edge - you'll research why something isn't
working and after 30 minutes find it's expecting python 3.7.

The whole concept of "virtualenv" gives me an impression of fragility I don't
get with perl.

~~~
jsymolon
Wanted to use Python 3 for some processing but the Sysadmin said that only
Python 2 was available for that distributions version and "didn't want to
frankenstein the box"

~~~
mkl
What about installing miniconda in your home folder?

How ancient is that system?

~~~
isostatic
> What about installing miniconda in your home folder?

This is not how you deploy software

~~~
mkl
You are right, but I interpreted it as a one off manual task. I've used
miniconda in that way.

------
tus88
It's interesting. I started Perl in around 2005, and moved entirely to Python
in 2014, exactly when it reached it's peak and started to decline. Seems I
wasn't the only one.

~~~
latchkey
Now I feel old, I started with Perl 4 around 1992-1993. There wasn't even a
CGI query args parser library yet, you had to roll your own.

~~~
tus88
What kind of web server would even be calling Perl CGI scripts in 1992? I
thought it was all bulletin boards back then. Personally I just got my first
PC and was learning to play Commander Keen in 1992 ;-)

~~~
latchkey
I started with perl in 1992, ncsa httpd came out in 1993, which was the first
release of CGI.

I ported EBBS/BBS to A/UX and ran one for a few years.

[https://en.wikipedia.org/wiki/NCSA_HTTPd](https://en.wikipedia.org/wiki/NCSA_HTTPd)

[https://github.com/virtadpt/eBBS](https://github.com/virtadpt/eBBS) (my name
is in the credits)

------
ojosilva
I think Perl was fighting on too many fronts at the turn of the century: web,
systems automation, data processing, science and a few more. Today these areas
are better covered by other languages that have hefty internet buzz and
corporate support behind.

Perl also has no shiny features. It's just extremely dynamic and paradigm
agnostic, great at shell interactions and natural at text processing
(specially with regexes), good enough at binding C/C++ libraries, has package
management built-in (CPAN) and an automated testing culture. Perl basically
set the baseline for a lot of today's languages.

Perl5 devs put a lot of focus on making Perl even more dynamic during the
2000s, relying on CPAN/community to fix language quirks and plug in novelties.
It worked to some extent, Perl got to the point where it could be written like
Haskell, Ruby... During that time it also got a powerful but optional class
system (Moose) and reinvented itself as a web language (Mojolicious, Plack).

Unfortunately it all came too late, most Perl5 devs moved to something else or
maintained Perl5 code frozen in legacy mode. Fewer and fewer started new
projects using Perl. For instance, nowadays I tend to pick a
language/ecosystem pair based on these concerns first depending on what the
job requires:

\- asynchronous event processing, specially network related -- I pick
JavaScript/Node.

\- real parallel processing and highly performant systems, I'd use Go.

\- "we got a package for that" \-- Python or JS at the forefront here. It
depends on what package I'll need for the job, typically it's not going to be
in CPAN.

\- great code reuse/portability -- to me JS wins here. And still the only
single language for both server and browser.

\- compiled hard-packaged binaries: Go, but also Rust, Elixir, Nim, and others
can fit the bill.

\- code style and paradigm -- a very personal choice, I think Typescript and
ES2019 are both great here. Golang and others are also great if I feel like
staying away away from OO.

Perl would have a hard time competing in any of these fronts, but it still is
one of the greatest for practical extraction and reporting, text or database
wise and easily available or pre-installed on many servers out there new and
old.

~~~
cat199
> web, systems automation, data processing, science and a few more.

doesn't this apply to python, although now there are additional competitors?

> reinvented itself as a web language (Mojolicious, Plack).

highly opinionated and potentially flame creating , but -

perl was the original web language in the CGI era, PHP pretty much dethroned
it due to simplicity of server integration, rails knocked them both out of
'leading edge', then the Node/SPA era arrived.

mojolicious / plack are pretty much things to bring perl up to date w/r/t the
'rails' type

~~~
hnick
I've long thought if they had PHP-style inline HTML/Perl templates it would've
given the language some legs. I'm pretty sure it exists (since I remember
using it back in the day as a toy, just like JSP and other stacks), but it
either came too late or didn't take off before PHP stole the throne.

I love Perl but I'm currently looking at around a decade of experience which
is really hard to take into a new role. I'm working a bit on Wordpress now but
PHP is basically close enough to Perl for me that it sits in a weird uncanny
valley where I get things just wrong enough to cause headaches every time.

------
nurettin
This september 2012 release was kinda huge for me. It brought venv, generator
expressions (event loops) a-la nodejs at the time, sped up a lot of things as
well. It was a great release and a step in the right direction. Perl6 was
still a myth at the time.

I did not start using python3 until last year, but I was aware it was evolving
quickly to one day become usable.

[https://docs.python.org/3/whatsnew/3.3.html](https://docs.python.org/3/whatsnew/3.3.html)

------
rurcliped
Perl is good for a competent coder who doesn't work as a developer,
occasionally has a one-off coding task, and wants to incorporate a code
excerpt from the web and immediately execute it (and then throw the code
away). Languages with whitespace as syntax often fail the "immediately
execute" requirement.

~~~
TylerE
That seems like a stronger argument for Excel than for Perl.

------
yellowapple
I actually used Perl last week to whip up two scripts (csv2insert and
csv2update) to automate converting CSV files to MSSQL-specific SQL
insert/update scripts (respectively). Microsoft's own CSV import tools suck,
and it was pretty straightforward to use Text::CSV and print() a bunch of SQL
lines.

I'd need to do some more polishing before putting it up on GitHub or something
(namely: sanitize incoming single-quotes in CSV cells, and possibly break the
steps into subroutines), but I was yet again impressed by the ability to
automate a bit of text data processing with less than an hour's work.

------
gpvos
Looks like peak Perl was about 2012-2014. :(

~~~
peteretep
Which is ironic, because even the most ardent Perlies among us were wringing
our hands about its inevitable decline well before then.

~~~
barrkel
The rate of increase must have been declining (i.e. rate of rate of increase
negative) in order for it to have peaked. This was probably detectable.

~~~
benj111
"and rate of rate of increase negative"

Are you a politician? Because that's a very round about way of putting it. :P

If the rate of increase is negative, there is an actual absolute decline. Is
that want you were meaning to say?

~~~
barrkel
I said rate of rate of increase. The second derivative is negative at a local
maximum.

[https://en.wikipedia.org/wiki/Derivative_test#Second_derivat...](https://en.wikipedia.org/wiki/Derivative_test#Second_derivative_test_\(single_variable\))

~~~
caf
...and the sign of the second derivative flips at an inflection point.

------
FranOntanaya
I wish someone poked irssi devs to support other languages. I basically
learned Perl just for it.

~~~
Fnoord
I assume you already knew and don't wish to change client -which is fair
enough- Weechat supports Python and Ruby in addition to Perl.

I remember the time before Irssi, when even CLI clients regularly had remotely
exploitable vulnerabilities in them (including the 1337 BitchX). Irssi was
programmed with safety in mind. Either way, scripts increase attack surface.

I'm not using IRC clients right now (I quit after realizing more than 50
windows open isn't productive), but I really love both Irssi and Weechat's
interface (including default themes) and CLI. Did have to finegrain the
configs but the same's true about nearly any application these days.

------
Audiophile65
Nice post :)

------
foobar_
Perl went full lisp. Never go full lisp.

------
mattbillenstein
Large Perl codebases are terrible - let it die.

~~~
Arnt
But the small perl codebases I have are great.

I have a crontab that runs every five minutes: 30 lines that use one CPAN
module, no bugs in years. The code has the kind of hackiness that's okay when
it fits on one screen, and it fits on one screen precisely because of that
hackiness.

~~~
lmm
It's very hard to know which codebases will grow to be large - every codebase
starts out small, and by the time you realise it's going to be big, rewriting
into another language is expensive. Better to use a language that can scale to
small codebases and large, that can accommodate hackiness and cleanness alike.

~~~
Arnt
Nicely put, but I notice that you avoid names and numbers.

How expensive can it be to rewrite a hundred or a thousand lines, if a perl
script keeps growing? And what are these languages (you use plural so I do
too) that are optimal for every case?

~~~
lmm
> How expensive can it be to rewrite a hundred or a thousand lines, if a perl
> script keeps growing?

A hundred lines, or a thousand lines, is not so bad. But where do you draw
your line in the sand that you're going to stick to? If you don't insist right
at the start on coding to your maintainability standards, why would you make
that change when your script went from 30 lines to 100, or 100 to 500 (no
doubt always driven by an urgent functional need)? It's always easier to add
one more change to the existing codebase; the only point where you'd rewrite
is when the codebase becomes literally unmaintainable because no-one
understands it, and at that point migrating it is extremely expensive.

> And what are these languages (you use plural so I do too) that are optimal
> for every case?

I'm not saying optimal (I doubt that's possible), I'm saying pick a language
that's adequate for every case. I'm partial to Scala, which was explicitly
designed as a "scalable language" that would work for large and small
codebases; other ML-family languages (e.g. OCaml) are similar. In my book any
language with the ML featureset is more than adequate for large codebases, and
any language that has a REPL/interpreter and doesn't require Java-like
explicit types is adequate for scripting tasks. (Side note: I've always found
it odd that Perl didn't have a first-class REPL, since IME that's one of the
biggest natural advantages of scripting languages). If you want to start from
the scripting end, Python, Ruby or even TCL offer a level of consistency and
least-surprise that let them scale to larger codebases than Perl, though I
wouldn't really want to use any of them on a truly large codebase.

~~~
Arnt
Next question: Code written in which of these languages tend to avoid needing
major redesign when a thirty-line script grows unanticipatedly to much, much
more?

~~~
lmm
I've seen plenty of Scala codebases grow without ever needing an overall
redesign, and don't see why it would be different for any other language. Of
course the end state is very different from the start state, and no doubt
pieces end up getting rewritten many times over. But being able to
incrementally evolve the codebase while keeping it all working is much easier
and cheaper than having to rewrite in one go. In my experience you only need a
"redesign" when you did too much design up front in the first place; if you
always keep code changes driven by concrete use cases and avoid premature
generalisation, you end up with a codebase that won't impede future changes
any more than it has to.

------
l33tman
Long ago I used to joke that perl is write-only... was that harsh or
realistic?

(I still believe it - too clever constructions which feel smart at the time
you come up with them :)

~~~
isostatic
"too clever constructions which feel smart at the time you come up with them"

That's the coder, not the language.

Which is more obvious what's happening.

    
    
      print ''.join('%(pre)s%(num)s %(bot)s on the wall, %(nul)s %(bot)s,\n%(tak)s\n' % (lambda c,b: {'pre':['','%s %s on the wall.\n\n' % (c,b)][abs(cmp(c,'Ninety-nine'))], 'num':c, 'nul':c.lower(), 'bot':b, 'tak':['Go to the store and buy some more... Ninety-nine %s.' % b,'Take one down, pass it around,'][abs(cmp(x,0))] })((lambda x,o: [(['Twenty','Thirty','Forty','Fifty', 'Sixty','Seventy','Eighty','Ninety'][x/10-2]+'-'+o.lower()).replace('-no more',''), o][int(x<20)])(x, ['No more','One','Two', 'Three','Four','Five','Six','Seven','Eight', 'Nine','Ten','Eleven','Twelve','Thirteen','Fourteen', 'Fifteen','Sixteen','Seventeen','Eighteen','Nineteen'][[x,x%10][int(x>=20)]]),'bottle%s of beer' % ['','s'][abs(cmp(x,1))]) for x in xrange(99,-1,-1))
    
    

Or

    
    
      my $firstline = 1;
     my @tens = qw/Ninety Eighty Seventy Sixty Fifty Forty Thirty Twenty/;
     my @teens = qw/Nineteen Eighteen Seventeen Sixteen Fifteen Fourteen Thirteen Twelve Eleven Ten/;
     my @ones = qw/Nine Eight Seven Six Five Four Three Two One/;
    
      sub go {
         my $num = shift;
         my $bottles = "bottles";
         if ($num eq "One") {
             $bottles = "bottle";
         }
         if ($firstline == 0) {
             print "$num $bottles of beer on the wall.\n";
             print "\n";
         }
         $firstline = 0;
    
         print "$num $bottles of beer on the wall, ".lc($num)." $bottles of beer,\n";
         print "Take one down, pass it around,\n";
         if ($num eq "One") {
             print "No more bottles of beer on the wall.\n";
             print "\n";
         }
     }
         
     foreach my $ten (@tens) {
         foreach my $one (@ones) {
             go("$ten-".lc($one));
         }
         go($ten);
     }
     foreach my $teen (@teens) {
         go($teen);
     }
     foreach my $one (@ones) {
         go($one);
     }
     
     print "No more bottles of beer on the wall, no more bottles of beer,\n";
     print "Go to the store and buy some more... Ninety-nine bottles of beer.\n";
     print "\n";
    
    
    

People can do clever things in either language, people can write clear code in
either language.

~~~
ninkendo
This post reminded me that Perl doesn’t even have a concept of a method
signature, even so much as showing the number of arguments. You have to look
at the next few lines to hopefully see all the `... = shift;` lines to see
what you’re actually supposed to send.

I mean, a lack of type annotations is normal for a scripting language, but
Perl always seemed to go a bit far by not even having a standard way of
showing parameter names.

I remember doing `my ($arg1, $arg2) = @_;` or something similar, but even that
felt weird, and not everyone adopted that convention.

~~~
isostatic
I usually do

    
    
      sub mymethod($$)
        my ($arg1, $arg2) = @_;
      }
    

Apart from on the smallest programs. So it does have a method signature (obv
it's an untyped language)

There are shortcuts (just like you could write "doSometing() unless $var;").
Perl does give you options.

Python has different options for passing methods - passing variables, passing
a dict,

P.S. while looking at python method declartions, you can send variables, a
key-value, multiple keyvalue, and then there's this:
[https://stackoverflow.com/a/16785702](https://stackoverflow.com/a/16785702)

Which comes out with

    
    
      f = lambda **dic: ' '.join(dic.get(key, 'None') for key in 'abc')
    
    

Which is no more or less readable than the most confusing perl I've ever
encountered.

"Cool Shortcuts" are a problem in any language. There are values in anonymous
functions on occasion (especially in sorts), there should be a very compelling
reason to do so.

~~~
bmn__
> sub mymethod($$)

That does not work. Prototypes are ignored for method calls. You are expected
to not abuse prototypes for signatures as they serve a different purpose.

> it's an untyped language

That's wrong even with the most lenient/charitable interpretation. Using an
unexpected type of data is a fatal error.

    
    
        perl -e'$x = {}; $x->[0]; print "survived"'
        Not an ARRAY reference at -e line 1.
    

Type constraints have existed for a very long time, for example see
[http://p3rl.org/Kavorka::Manual::Signatures#Type-
constraints](http://p3rl.org/Kavorka::Manual::Signatures#Type-constraints)

