1. 15
    1. 22

      As an aficionado of dead languages you should not greet Perl’s death with hand-wringing and apologia. You should instead look at what is nice about niche languages:

      • Enthusiasts are really enthusiastic
      • Few dead weight users that just beg for other people to make things easier for them
      • Really interesting and bizarre libraries will appear, and gain big traction
      • Quality of content will, in general, become higher

      When people who had to use Perl despite what it is are gone, you’ll be left with people using Perl because of what it is, and that will lead you to a nice, albeit quieter, renaissance. Similar things happened with Smalltalk and Prolog. So celebrate these days as the end of having to convince people to use Perl, or having to convince people using Perl to use it better. You won’t have to explain why Perl isn’t Python or why Perl isn’t bash or whatever. It will be nice.

    2. 14

      This is a correct but largely valueless rant.

      What about a post listing ways to get started with various types of projects in Perl?

      1. 6

        Great idea! Next blog?

        1. 1

          Yes please

    3. 6

      I have been working really hard the past years to make Perl less painful to work with. Imo the main problem with Perl is the same with Javascript prior to typescript: too much flexibility created unbounded complexity.

      I have tried lobbying for a TypePerl superset of Perl, similar to Typescript to JavaScript, but the idea was not greatly received by our Perl experts. Without it, creating good developer tooling for Perl like a proper LSP would be really hard and thus the barrier of entry remains high, killing the growth of the language.

      1. 3

        javascript tooling in vscode is built on top of typescript technology. May be worth building a typed perl even if the majority of folks don’t use it

      2. 1

        Why but building it instead of lobbying?

        That said it kind of feels wrong. Not the idea, I’d still suggest to do it. However Perl is around flexibility, about TIMTOWTDI and about borrowing concepts from natural languages. Making something l more rigid in that sense feels like taking the core of Perl away from it. Of course that’s not true if you just pick some parts. I’d be curious about it. Maybe some ideas from Raku also help.

        I think PHP,. Perl, Ruby and to some degree Python and JavaScript and others like smalltalk started out with the idea of bringing programming languages closers to natural languages. A trend that has since been reversing again. But honestly I would be very curious about such a concept would be approached in today’s world, where things like implicit typinge for example exists in systems languages.

        There’s lots of concepts that can be stolen. On top of that there’s lots of great programming language backends basically ready to be used and they are used, but not so many going into that for a lack of a better word “very high level”, “copying natural languages”, “do what I mean”, rather than do what I say direction.

        I also think there’s a general trend to languages being optimized for big projects rather than scripting. Scripting therefore feels a bit like that thing that people did maybe in the 90s. I think taking the learnings from the past few decades could be a big factor here. I just maybe wouldn’t go so much for copying languages but going after their core concepts or call it philosophies.

        1. 1

          Why but building it instead of lobbying?

          Because its not the type of job that make sense to build alone by yourself, but to discuss with teammates and colleagues to collaborate on, and business to invest engineering hours into.

          Also I was not working that close to Perl, but a lot more around CI/CD, code health, code review system around a big Perl code base. So I don’t have the language expertise to properly evaluate whether if a solution is right

          feels like taking the core of Perl away from it

          Yes, some of my colleagues share this sentiment as well.

          But leaving Perl at the current state significantly make it hard to build concrete developer tooling (LSP, LSIF, etc…) and static analysis around. It’s also much harder to read, let alone write tests. Programmer from different backgrounds also have a much harder time onboarding a Perl code base.

          Overall, there will be tradeoff for sure.

          But if you look at Python, Ruby, Javascript or even Erlang, you would find a movement of big companies (Facebook, Stripe, Microsoft, …) having to apply gradual typing into their repos to improve code health and developer experience. It looks like the tradeoffs has been working out for those languages, and there is a high chance that it also will successful with TypePerl

    4. 4

      I feel the value-add of CPAN is slightly disingenuous when I bet a majority of those packages are no longer maintained (or work, considering how APIs for services can change), and other ecosystems have leapfrogged it.

      1. 1

        Yeah, CPAN ain’t what it used to be, and for “package-driven” development, Python is probably the way to go nowadays.

        On the other hand, I find that the diminishment in value due to unmaintained API-dependent packages is compensated by the volume of packages that change and augment the language in really powerful ways. See e.g. Keyword::Declare (and the accompanying presentation).

      2. 1

        I’m one of those people who actually tries very hard to write Perl scripts that don’t have CPAN dependencies, even if I end up reinventing the wheel now and then.

    5. 5
      1. 3

        Without controlling for seniority or location, those numbers are pretty meaningless. According to levels.fyi, the most junior software engineer that they track at any of the big tech companies makes over $150K/year, yet this list has an upper bound of $95K/year. The numbers for the big tech companies are skewed by the fact that they are mostly based in a couple of big tech hubs (San Francisco and Seattle) that have very high cost of living. In contrast, someone in a small town can make half as much and still have a higher disposable income. I’m really curious how that’s going to change as more places move to remote working (why should the company pay you more to live in San Francisco if they don’t need you to live in San Francisco?).

        There are a few things on that list that make me very suspicious. For example, they report Objective-C developers making about 10% more than Swift developers. As the maintainer of the GNUstep ObjC stack, I’d love to believe that, but I suspect it’s really just an artefact of seniority: most new developers in the iOS / macOS ecosystem are going to be using Swift and so there are probably more junior Swift developers than there are total Objective-C developers. HTML/CSS developers are paid less than bash developers, which makes me think that they let people select multiple options and more junior folks are willing to report doing front-end work, whereas more senior folks report doing more *NIX sysadmin work. PowerShell is mid way between F# and C# in reported earnings, but I’d expect pretty much everyone who ticked F# or C# to also tick PowerShell (and probably a lot of folks to tick all three), so the location of PowerShell probably tells us more about the relative numbers of C# and F# developers in the sample than anything else.

    6. 2

      It is not, but it is clearly declining in usage even in places deeply involved with it. It is a pity, because modern Perl code can be very elegant :(

      1. 6

        It can be elegant, but to me the best value of Perl is in writing utility scripts, too awkward for shell.

        I generally prefer to write small things in Perl… but I would prefer to read other people’s work in Python.