[HN Gopher] The Future of Perl
___________________________________________________________________
The Future of Perl
Author : bmn__
Score : 117 points
Date : 2021-03-24 09:38 UTC (13 hours ago)
(HTM) web link (perl.topicbox.com)
(TXT) w3m dump (perl.topicbox.com)
| alexhutcheson wrote:
| Perl deserves credit for being way ahead of the curve: It was a
| free, widely available, garbage-collected language with good
| support for strings, during a time when the server-side
| alternatives were basically (primitive, early) C++ or expensive
| commercial toolchains. By 1995 it also had CPAN, which was (I
| believe) the first comprehensive directory of modules available
| for a language ecosystem.
|
| The combination of garbage collection, good string support, and a
| huge set of easy-to-use third-party modules made Perl _insanely_
| productive relative to the other options at the time. Remember -
| Python didn 't release a 1.0 until 1994, and Java 1.0 didn't come
| out until 1996, and the early versions of those languages were
| missing a lot of features you'd recognize today, and still had
| plenty of bugs and performance issues to work out. By 1994 Perl
| had been out for >6 years, and reached version 5.0 that year. In
| both capabilities and maturity, it was ahead of the other free
| alternatives, and _way_ ahead of trying to wrestle with string
| templating in C or C++. Perl enabled a ton of cool things to be
| built much more quickly than they would have with the other tools
| available at the time.
|
| At the same time, it's hard to see a viable niche for Perl going
| forward. The advantages I mentioned above are no longer unique to
| Perl - they're now table stakes for any mainstream language.
| _Every_ mainstream language has a package archive now. There are
| at least 7 mainstream general-purpose languages with a garbage-
| collecting runtime, with quality ranging from decent to
| incredible. Every language except C evolved decent support for
| string manipulation. Perl deserves tremendous credit for leading
| the way in making these things mainstream, but it has left Perl
| with very few distinguishing advantages.
|
| Without those advantages, Perl seems destined to gradually fade
| away. The sheer mass of existing code means it will probably
| never be gone - there will always be important systems still
| running on Perl. But very few greenfield projects will use it,
| and fewer programmers will learn it in the future.
|
| We can quibble about _why_ Perl has gradually faded from
| relevance. Personally, I think people generally overweight the
| importance of the Perl 6 announcement, and underweight the impact
| of Apache 's mod_php in shifting usage away from Perl. mod_php
| enabled hosting providers to safely enable PHP on shared hosting,
| while mod_perl couldn't be used in that context, because users
| could affect the Perl environments of other users on the same
| system. As a result, PHP hosting was cheap and had tons of
| options, while Perl hosting required a more expensive option like
| VPS or a dedicated box. This kick-started the PHP ecosystem, and
| its growth came largely at the expense of the Perl web
| development ecosystem. One could imagine an alternative world in
| which PHP never took off, and Facebook, Wikipedia, Wordpress,
| etc. were all started in Perl, but that's not the world we live
| in.
| shagie wrote:
| > Personally, I think people generally overweight the
| importance of the Perl 6 announcement, and underweight the
| impact of Apache's mod_php in shifting usage away from Perl.
|
| I'll agree with this... conditional. The overweight of the
| importance of the Perl 6 announcement also had a change in the
| release cadence of perl5.
|
| Prior to the perl 6 announcement, there was a release of perl 5
| every year - sometimes multiple releases in a year.
|
| With the announcement of perl 6 in July of 2000 - there wasn't
| another release until 2002... and then the next in 2007... and
| then the next in 2010.
|
| That decade of stagnation when everyone was waiting for perl 6
| shouldn't be underweighed either.
|
| This also coincided with the rise of php and Java with
| application servers during which there wasn't any significant
| of perl in a web serving environment. And while there were web
| application frameworks for Perl (Catalyst in '05, Mojolicious
| in '08, Dancer in '09)... that was too little, too late.
|
| And the web has become the dominant story for how applications
| run - not scripts.
|
| Perl lost development mindshare at a time when the "how things
| work" was undergoing a major shift. Raku remains a language
| designed for scripts rather than delivering data to other
| systems. The rise of Docker for serving may give Raku some
| reprieve - but so much effort has already been focused
| elsewhere. I don't see Raku with Cro being a compelling
| alternative for a new developer over Spring Boot or NodeJS.
| peteretep wrote:
| https://docs.google.com/document/d/1OxeK0ctbBPtNw7UPG5x9iRYM...
|
| ... is probably a better link than the random discussion in that
| horrible JS webapp?
| blewboarwastake wrote:
| I appreciate the effort. If you don't like webapp bloat
| consider using pastebin: https://pastebin.com/, or any other
| text-sharing service.
| yellowapple wrote:
| I ain't sure if replacing a horrible JS webapp with a different
| horrible JS webapp is much of an improvement ;)
| haolez wrote:
| Off topic, but the best programmers that I've met so far in my
| career were Perl gurus. They had this super power where they
| could implement new tools from scratch and they would feel robust
| as if they were made by an external vendor or an open source
| project. It was magic to me.
| aduitsis wrote:
| I started using Perl in 2000 to rescue my diploma thesis (which
| was Java and C). I was working on a piece of software that was
| to communicate with another system that was the subject of
| another sister-thesis. The person working on the sister-thesis
| decided to abandon it. And I could really not demonstrate my
| work as it couldn't work standalone. In the place of the
| missing sister-system, I quickly put together something in Perl
| and was able to salvage the work and deliver my thesis.
| Compared to Java and C of the day, it felt like magic.
|
| To this day, I have never seen anything that can even remotely
| approach the ability of Perl to prototype something out of thin
| air. Usually there is a gap between script-like tools (like sh,
| sed, awk, grep, jq, curl, etc) with which you can quickly put
| together stuff and a "real" language which usually needs
| scaffolding and preparation. Perl can do both, you can write
| excellent one-liners and you can also write complex software
| with libraries and frameworks and dependencies and tests.
| wmichelin wrote:
| Python is pretty great for rapidly putting together
| prototypes. You ever give that a shot?
| haolez wrote:
| Perl goes farther than Python when trading sanity for
| productivity :)
| cookiecaper wrote:
| Yeah, I started working at a place where 90%+ of the production
| codebase is actively-maintained Perl, and it honestly feels
| great.
|
| These guys might have a hard time fitting a recruiter's
| definition for a "rock star" but they're the best set of
| colleagues I've had in a very long time, and that's after
| working at multiple flashy tech companies.
|
| Long live Perl. We can only hope to get another generation of
| programmers as committed and useful as the people who still
| write Perl every day.
| haolez wrote:
| Btw, my gurus are working at Comcast. I was kind of surprised
| to see Perl demand in a company as big as Comcast nowadays.
| iso1210 wrote:
| I've got a perl website dating back to 2004 - from before php5
| was out - that is still used by hundreds of people a day on an
| internal system.
|
| Works great, the code is deployed by a deb in the same was as it
| deployed in 2008.
|
| Since initial creation, had about 10 hours effort to put in a
| mobile view for an iphone and blackberry in 2008/9, and maybe 5
| hours effort to replace the <object> with <video> a couple of
| years ago. Update the 3 files, roll the new deb, and away we go
| for the next forseeable, until the userbase finally decides that
| the multi-man-year all-singing replacement that's some javascript
| heavy frontend and microservice backend actually lets them do
| their job better (which it seems isn't the case from the
| complaints it gets)
|
| Sometimes a tool just works and enables you to get on and do
| things beneficial to your product.
| acomjean wrote:
| Perl has really fallen out of favor in bioinformatics. I
| inherited a bunch of Perl scripts that have been running
| basically for over 10 years. The input data is the same so they
| keep working. I'm not great at Perl and I do find them hard to
| read. While I get the goals I'm not super happy to have these
| scripts end up on the continuous upgrade as the language changes
| path.
|
| The goals seem good. A language needs users, and fewer and fewer
| are using it lately. Error messages can be obtuse, the package
| system while powerful is confusing..
|
| Out cluster upgraded the os a couple years ago. Once you figure
| out how to a missing Perl library installed everything kept
| working. (The cpan installation story isn't easy for a novice).
| the fact that it hasn't changed much is kind of nice compared to
| some other language where a lot of scripts needed a fair amount
| of touch up when the language had a lot of breaking changes.
| ktpsns wrote:
| The same is true in many other data science branches (such as
| physics). Perl was the perfect glue language in the 90s but
| then got more and more replaced by python. I think one reason
| for that is Numpy/Pylab, which makes python a perfect
| replacement for proprietary Matlab codes. All at once,
| scientists can write most of their codes in a single
| language/software ecosystem which also feels relatively close
| to mathematical notation, at least you can write equations
| similarly readable as in (modern) Fortran. The perl sigils
| really got out of fashion.
| attractivechaos wrote:
| > _compared to some other language where a lot of scripts
| needed a fair amount of touch up when the language had a lot of
| breaking changes._
|
| Python, I am looking at you!
| valarauko wrote:
| Similar story here - during my PhD my lab worked mostly in perl
| & C, but for my purposes R was a better fit. Some years down
| the line, I grew frustrated & moved to python, where I've been
| ever since. In my postdoc lab we're mostly leaning R, though a
| few of us are on python. I suspect newer members will be mostly
| python.
| lizknope wrote:
| I learned Perl in the late 90's and I still use Perl 5 all the
| time. The semiconductor industry is held together with thousands
| of lines of Tcl and Perl code.
|
| Every day I have to parse some new type of text file and Perl is
| great for that. Everyone else I work with are also in the same
| age range and everyone already knows Perl. Introducing a new
| language doesn't seem worth it.
| goto11 wrote:
| Are you considering moving to Raku or Perl 7 or will it be Perl
| 5 forever?
| petre wrote:
| Ruby is a more logical choice, or Elixir, depending on your
| usage domain. Or maybe Python or Julia if using PDL? Raku is
| nice but still slow and not there yet. No nice http framework
| like Mojolicious for one, not enough libraries to get stuff
| done. Pdf support is still quite lacking in Perl for
| instance. Good luck churning out a nice looking report for a
| client.
| forgotmypw17 wrote:
| I started a new project in Perl a couple of years ago
| precisely because it has remained stable and without breaking
| changes for all this time.
|
| It's a feature, not a bug, that the language has remained
| stable and backwards compatible all this time.
|
| I switched away from PHP (except for a few glue shims)
| because on several occasions they made changes which broke my
| shit when the web host I was using upgraded.
|
| I want a language which doesn't cause me extra worry and
| inconvenience with breakage, I do enough of it already by
| myself.
|
| I am so grateful for Perl, can't speak of it highly enough.
| It takes an amazing, WISE community to resist the shimmering
| temptation of breaking compatibility for so many years.
| tannhaeuser wrote:
| TBH, Perl being frozen in time isn't by design but rather a
| result of the extremely long (15+ years?) cycle of
| releasing Perl 6/Raku. In its heyday, Perl used to
| introduce new features and sigills all the time in dot
| versions. Also, I don't think Perl can claim the moral high
| ground on stability when the languages Perl was supposed to
| replace, such as awk, are POSIX-standardized and have
| multiple interworking implementations, and Perl even
| shipped an aggressive awk-to-Perl converter (a2p). As a
| legacy of Perl, PCREs with capture groups and above-regular
| language features invading environments and especially web
| frameworks and JavaScript also are of dubious value because
| of the attack vectors they bring.
| forgotmypw17 wrote:
| Fair points... But that's what has happened, and whatever
| the reasons, I am grateful for the blessings.
|
| Awk and friends are great, but also a bit awkward to
| write complex applications with, in my non-expert
| experience.
| tannhaeuser wrote:
| Yeah on a second reading I didn't want to come down on
| Perl too harshly even though I still have memories of
| that moment where I had to listen to someone telling me
| "What, awk? We're doing Perl these days!" plus 3 not-so-
| pleasant projects over the years where we had to re-
| implement Perl systems.
|
| OTOH there are a couple of Perl tools that I still use
| (or whish I'd still be able to use), and I'm grateful
| those exist and Perl 5 is being maintained: Norman
| Walsh's SGML DTD documentation generator, the old
| citeseer code base (infinitely more useful than it's
| today), Debian's apache a2enmod/a2ensite management tools
| (that I've partly rewritten in shell) and apt tools. I
| even wouldn't hesitate to use RequestTracker tools
| (ticket management over mail) today even though it might
| not scale all that well.
| raiph wrote:
| My view:
|
| The first version of PCRE was released in 1997, first
| Perl that supported PCRE in 2009. Claiming PCRE is "a
| legacy of Perl" is like saying C is a legacy of C#.
|
| Calling a2p "aggressive" because it did a surprisingly
| good job converting awk to perl is like saying useful
| technology is aggressive.
|
| Perl wasn't supposed to replace awk. It was designed to
| integrate features of C, shell, sed, and awk into one
| tool. That was spectacularly useful.
|
| Perl is a high point in PL stability, still correctly
| running most Perl _4_ scripts from the last century, with
| _active community support_ for versions of Perl from 15
| years ago. This is despite continuous evolution, eg
| adding Unicode support, in contrast to POSIX ( "printable
| ASCII characters, space, BEL, backspace, tab, carriage
| return, newline, vertical tab, form feed, and null").
|
| "Perl used to introduce ... sigills all the time in dot
| versions." Perl has never introduced a new sigil.
|
| Perl maintains backwards compatibility despite also
| evolving because it's maintained by smart and
| conscientious professionals.
|
| The OP discussion of the future is a continuation of that
| same philosophy.
| snicker7 wrote:
| I maintained a financial data pipeline written almost entirely
| in Perl. Literally thousands of scripts accumulated over
| decades.
| racl101 wrote:
| Sounds like a good way to stay employed ha ha.
| ptero wrote:
| > Every day I have to parse some new type of text file and Perl
| is great for that. Everyone else I work with are also in the
| same age range and everyone already knows Perl.
|
| You nailed it, but this cuts both ways: as the folks who used
| to do everything in Perl move out, the language fades. In the
| last few years I see that new tasks that would be done in perl
| several years ago are now done in python. I like perl, but I
| think its best days are over.
| tmountain wrote:
| I also learned Perl in the 90s. I loved it at the time, as it
| was so much easier than writing C code to parse a config or
| do basic text manipulation (was working at an ISP). Hearing
| about the "future of Perl" feels a bit like pondering the
| future of VHS tapes. Perl exists, and as far as I'm
| concerned, it is a finished product. There are countless
| language options that have come onto the scene since it was
| in its heyday, and that leaves me wondering what the goals
| are regarding reinventing or reimagining Perl. Who is the
| target audience? What is the target problem space, and why
| can't those issues be tackled within the modern language
| ecosystem? I'm not knocking the effort or initiative. I'm
| genuinely curious.
| thatwasunusual wrote:
| > The semiconductor industry is held together with thousands of
| lines of Tcl and Perl code.
|
| Is that the reason why there's a shortage of new NVidia cards?
| /s
| dtech wrote:
| That's going to work right up until you all retire around the
| same time
| brokenkebab wrote:
| There are loads of battle-tested well-working Perl code
| around, and its cheaper to hire one smart dev who can learn
| Perl to maintain than to hire a whole team to re-write in a
| new PL. So no matter what is Perl's future in terms of
| evolution, or mindshare there will be Perl programmers until
| the code is retired, and its unlikely to happen anytime soon.
| thatwasunusual wrote:
| > its cheaper to hire one smart dev who can learn Perl to
| maintain than to hire a whole team to re-write in a new PL.
|
| Short term? Probably.
|
| Long term? Probably not.
|
| At one point your _one_ Perl developer will disappear, and
| while you held onto that one person, the Perl language has
| faded even more into oblivion, making it literally
| _impossible_ for you to hire people to maintain your
| product.
| brokenkebab wrote:
| Yes, but in the long term everything will break, no
| matter what language one uses. The question is how long
| is long? I suppose when talking about PLs it's
| proportional to amount of working code in the wild.
| thatwasunusual wrote:
| > I suppose when talking about PLs it's proportional to
| amount of working code in the wild.
|
| It comes down to the number of people that knows, or
| shows interest in, any given programming language.
|
| You are right that you might need to diverge from your
| language of choice at one point, even rewrite your whole
| application (which is scary enough), but you should do
| that at a point where a different language is "at top",
| or at least trending towards "the top."
|
| Perl is trending downwards in all statistics,[1][2][3]
| except maybe statistics that has to do with salaries,
| because it's hard to find people who can do the job.
|
| This is not a bashing of Perl itself: I love Perl, but I
| also see where it's failing, which is why I make use of
| several different programming languages to get a job
| done, if necessary. At the end of the day, Perl is just
| another tool in the toolbox, and as a boss you need to
| employ people that are familiar with the most popular
| (not necessarily the best, sadly) tools to get the job
| done.
|
| [1] https://trends.google.com/trends/explore?date=2011-01
| -01%202...
|
| [2] https://insights.stackoverflow.com/trends?tags=perl
|
| [3] https://www.statista.com/statistics/793628/worldwide-
| develop...
| dspillett wrote:
| _> Long term? Probably not._
|
| If companies are sensible and have learned from past
| issues, yes. But I live in the real world, so no!
|
| Reference: the COBOL programmers pulled out of retirement
| en-mass in the late 90s to perform Y2K audits/fixes.
|
| _> to maintain your product._
|
| Often with Perl it isn't the end product that is the
| issue, that is more likely to have been ported to some
| other language/framework, but instead all that Perl is
| managing IT and project infrastructure.
| thatwasunusual wrote:
| >> Long term? Probably not.
|
| > If companies are sensible and have learned from past
| issues, yes. But I live in the real world, so no!
|
| In my world, more and more companies learns from past
| issues/failures. They also live in the same world as you
| do, which sees a decline in both number of Perl
| programmers and a decline in general usage of the
| language itself.[1][2][3]
|
| > Reference: the COBOL programmers pulled out of
| retirement en-mass in the late 90s to perform Y2K
| audits/fixes.
|
| That was 20 years ago. Plus, it's not a good thing that
| people are "pulled out of retirement" to fix things.
|
| [1] https://trends.google.com/trends/explore?date=2011-01
| -01%202...
|
| [2] https://insights.stackoverflow.com/trends?tags=perl
|
| [3] https://www.statista.com/statistics/793628/worldwide-
| develop...
| edoceo wrote:
| > In my world, more and more companies learns from past
| issues/failures.
|
| Welcome to earth! We don't do it that way here.
| thatwasunusual wrote:
| Not Perl's - or any other programming language's -
| problem if a company doesn't know how to do their stuff.
| iso1210 wrote:
| And I'm sure some companies spent money rewriting
| perfectly functioning perl code into something like ruby.
| zimpenfish wrote:
| Or, in my experience, node.
|
| (Although it wasn't "perfectly functioning" Perl code but
| whilst it was an abhorrent mess internally, the actual
| problems were largely caused by the database parts -
| awful schema, bad server setups, godawful queries from an
| insane home-grown ORM, etc., which could all have been
| fixed in a couple of months.)
| dtech wrote:
| There is regular news about how one COBOL system or the
| other has become unmaintainable and is causing problems.
| [1] If your hypothesis would be true this wouldn't be the
| case, as there would always be enough smart devs to learn
| COBOL and keep working on them.
|
| [1] example:
| https://www.bloomberg.com/news/articles/2020-04-13/an-
| ancien...
| clipradiowallet wrote:
| It's a pay problem. I don't mind learning some random
| COBOL codebase and maintaining it, but clients don't want
| to pay consulting rates over the long term, for what they
| view as "maintaining an old system".
| rst wrote:
| It's not just COBOL, it's the whole OS environment --
| which, for a lot of these old systems, involves legacy
| mainframe tech (z/OS) with its own peculiar jargon. Basic
| concepts like "file", "directory", and "disk drive" have
| different names, and subtly different relationships, and
| the closest thing to shell scripting is the notorious
| JCL, with a syntax derived from assembly language (back
| when writing applications in assembly was a common
| thing), and described more than once by the person most
| responsible for it (Fred Brooks) as "the worst computer
| programming language ever devised by anybody, anywhere".
|
| Here's a blow-by-blow from someone who was, at the time,
| dealing with some of these systems as part of the United
| States Digital Service, and thought she ought to get to
| know the beast up close. It's not pretty:
|
| https://medium.com/the-technical-archaeologist/hello-
| world-o...
| nix23 wrote:
| Yeah, just imagine a part of the Goverment would say "hey
| we forgot to bring in new peoples and pay them
| right..sorry", instead of "we did nothing wrong, it's
| that bad unmaintainable Code-Base and that bad Language
| named Cobol, and the Mainframe is btw 15 years old" told
| over Zoom on a Windows10 Machine ;)
| brokenkebab wrote:
| It perfectly supports my hypothesis. Cobol is bloody 60+
| old. It was in the category of "oh so old" languages in
| 80s already, and it took another 40 years to reach the
| point when its code became too old to support.
| rory wrote:
| Perl is far less exotic than COBOL when compared to
| modern languages that are still in heavy use. It looks
| kinda like C or PHP and feels kinda like Python or Ruby.
| I've never written COBOL but it looks almost as foreign
| to me as a punchcard.
| dragonwriter wrote:
| > There is regular news about how one COBOL system or the
| other has become unmaintainable and is causing problems.
|
| Well, yes, but as someone who works in public sector in-
| house IT, often tangentially around old COBOL systems and
| has been directly involved in systems replacements for
| some that had become unmaintainable, I sit on the
| "familiar" side of the Gell-Mann Amnesia Effect with
| those stories and recognize that they rely almost
| entirely on the accounts of people and organizations
| whose massive institutional failures they cover for.
|
| They aren't unmaintainable because "COBOL", but because
| of poor choices is contracting and contracting oversight
| as they were developed, both initially and with
| subsequent revisions, which leaves them both poorly
| architected for change and without useful documentation
| of functional/behavioral requirements, concrete design,
| or, really, much of anything else, with key knowledge
| trapped in individual people's heads, scattered among
| business and IT _initially_ , and almost all of which
| have since moved on, leaving behind a smaller set of
| people responsible for the system who deal with it
| through rote, cargo cult practices that they don't
| understand the reasons for. They'd be unmaintainable if
| COBOL was a currently-popular language.
|
| If you look at the same institutions, .NET (maybe even
| .NET Core) apps that are comparatively in infancy, only a
| handful of years old, are following those COBOL apps
| rapidly down the same path, and have frequently already
| become difficult to maintain.
|
| But an old language is a convenient scapegoat for deep
| and entrenched organizational dysfunction.
| fatbird wrote:
| The problem is that it's not just learning Perl, it's
| learning Perl and the monolithic app (or forest of
| microservices) at the same time; and if that one smart dev
| doesn't want to keep doing it, you keep repeating that
| learning curve with all the costs associated with it.
| iso1210 wrote:
| Just around 2038 as people go "what the hell does this perl
| code do" as the clock rolls over.
| petre wrote:
| It already supports 64 bit ints and relies on time_t and
| other lower level types. If these work in 2038 so will
| Perl.
| bmn__ wrote:
| https://perldoc.perl.org/perl5120delta#Y2038-compliance
| n3storm wrote:
| LoL
| asicsp wrote:
| > _The semiconductor industry is held together with thousands
| of lines of Tcl and Perl code_
|
| That's where I learned Perl (along with getting familiar with
| Linux and Vim). I didn't have to use Tcl, but my team members
| had to. Based on our experience, we got a one-credit course
| started on these topics for our dept in college. These days
| they have moved on to Python though.
| bachmeier wrote:
| There are so many stories from people that used Perl long ago but
| have since moved on to better languages. My story is the
| opposite. I tried Perl ages ago and couldn't understand why
| anyone would use it for anything. A couple years ago I decided to
| give it a try (it was the best fit for unimportant reasons). What
| I found was a solid language that was great for working with
| text, highly performant, a good replacement for Bash, and
| everything just worked so easily, including CPAN packages.
|
| A few days ago, I returned to modify something I wrote last year.
| I was surprised at how easy it was to read and understand the
| code. The $ and @ that folks complain about are pretty handy
| tools to convey what the variable holds. Though I won't be moving
| most of my code to Perl, I think it's great for what it was
| originally intended to do.
| wvenable wrote:
| I have the opposite experience to you; I was required to use
| Perl ages ago and built enough software in it to actually like
| it. I understand why some people are big Perl lovers.
|
| But of all the programming languages that I know (and it's a
| long list) Perl is the only one that I can't just jump back
| into. I've forgotten all the esoteric things about it. Unlike
| most languages, you can't get far in Perl without knowing those
| esoteric things.
| wott wrote:
| > The $ and @ that folks complain about are pretty handy tools
| to convey what the variable holds.
|
| It doesn't convey much. $scalar or @array, that's all. An array
| is always an array of scalars. Scalar can be almost anything:
| any kind of number, a string, a reference (often a reference
| to... an array or a hash, since you can't have arrays of arrays
| or array of hashes, only arrays of scalars).
| bachmeier wrote:
| > It doesn't convey much. $scalar or @array, that's all.
|
| It's useful when you have a healthy mix of arrays and scalars
| scattered throughout your code. Static typing would be
| better, but $ and @ are better than tracking the information
| manually.
| citrin_ru wrote:
| > people that used Perl long ago but have since moved on to
| better languages
|
| For tasks where Perl is a good fit I moved to Python, but
| cannot say that it is better (or worse). It is much more
| fashionable, which is an advantage on its own though - more
| people will be able to read code written in Python, there are
| more libraries which are actively maintained.
|
| Many years ago I used Pascal and now work with software written
| in C. In my opinion Pascal is much better language than C, but
| Pascal is mostly the thing of the past and C is still very much
| alive. Sometimes we have to move to languages which are worse
| or at best - not much better.
| erik_seaberg wrote:
| Python has safer defaults. If you want lexical scoping, or
| errors when you make mistakes, you have to ask for it in
| Perl.
| cogman10 wrote:
| Perl is great because it makes text processing and CLI tool
| development really stupid simple. The language was built for
| that sort of thing.
|
| Perl suffers for the same reason. It's early prioritization of
| text manipulation makes it not great at general purpose
| programming.
| bachmeier wrote:
| > It's early prioritization of text manipulation makes it not
| great at general purpose programming.
|
| Exactly, and that's where I went wrong the first time I
| looked at Perl. You can tell the language was designed by
| someone that knew a lot about text manipulation. That means
| it's really good at solving those problems. Unfortunately I
| wasn't using it for text manipulation at that time.
| throwaway0x1 wrote:
| The future or Perl: Python
| shrubble wrote:
| JavaScript only website (couldn't even load the page without it)
| with a link to a Google Docs document.
|
| They've lost their way.
| oneeyedpigeon wrote:
| In case anyone else is unclear on what the objection to the
| google doc might be, it also requires JavaScript.
| [deleted]
| gekkonier wrote:
| It was my first programming language I got things done with -
| until I discovered ruby. After a ride into lisp/scheme/racket
| world I'm on ruby again.
|
| I have good memories with it, but I wouldn't jump train again.
| mlang23 wrote:
| The Future of Perl apparently resides on a JavaScript only site.
| What a weird world.
| chrisseaton wrote:
| Just because you use Perl doesn't mean you can't use any other
| languages where appropriate. You don't need to be a zealot
| about everything.
| mmcclimon wrote:
| I work for Fastmail, and helped write Topicbox, the backend of
| which is entirely written in modern Perl. The frontend
| obviously uses JavaScript, and talks to the backend using JMAP
| (RFC 8620), which we helped to develop; Topicbox was using 100%
| JMAP well before Fastmail itself did.
| phillc73 wrote:
| > and talks to the backend using JMAP (RFC 8620)
|
| FastCGI and mod_perl would have been a better choice.
| mst wrote:
| JMAP operates over http and the backend http server is
| almost certainly PSGI based, which obsoletes both FastCGI
| and mod_perl as deployment approaches.
| phillc73 wrote:
| Thank you, I didn't know that. I was also being slightly
| facetious given the topic.
| bshimmin wrote:
| Why can't the back-end of Topicbox do the JMAP stuff and then
| serve up some HTML? Beyond "because that's how we built it
| and it must be thus", it's quite hard to see why the front-
| end would need so much JavaScript to render nothing more than
| a chain of emails.
| brongondwana wrote:
| If you're just loading a single page, then yeah - it's
| pretty useless. If you're spending any time in Topicbox
| then the benefits of push updates and dynamic preloading
| pay off, and it's pretty lightweight as Javascript goes.
|
| But yeah, in a perfect world where we had infinite time to
| develop it, we'd have the backend serve up a non-javascript
| static version of the content in response to direct links -
| if nothing else because it makes things a lot nicer for
| search engines - and then the javascript would load in and
| take over if enabled to allow you to keep moving through
| the site like usual.
| gerikson wrote:
| Perl is nothing if not pragmatic.
| cygx wrote:
| _v8 will actually change defaults_
|
| Bad idea, imo. Keep the _perl_ binary backwards-compatible
| (unless _' use v8'_ is specified), and add a separate _perl8_
| alias that does so implicitly.
| yellowapple wrote:
| It'd be interesting to see versions specified by their file
| extension. Perl 6 already set that precedent with the .pl6/.pm6
| extensions, and I don't see any substantial downsides aside
| from maybe some file association inconvenience (but that's
| pretty trivial to fix). Plain .pl/.pm files can then always be
| assumed to be Perl 5 code, and to be treated as such.
| cygx wrote:
| Didn't think of that, but it could work. If you only provided
| the _perl8_ alias, you 'd still need to add a _use_
| declaration to modules, whereas that could be absorbed into
| the file extension...
| toast0 wrote:
| There's no need to set it with a file extension. You can set
| the #! or put use v8.
| yellowapple wrote:
| Right, but that's extra boilerplate. Granted, it's only one
| line (two if you do both), but still. Reducing boilerplate
| is already an explicit goal for v8, so it seems like it's
| worthwhile to be consistent on that front.
|
| Also, not all Perl files have a shebang, and not all files
| are invoked in a way that'd make a shebang useful. Modules
| are the obvious example here.
|
| In any case, nothing precluding all three approaches from
| being supported in case Perl hackers really prefer a "use
| v8;" over changing the filename or vice versa.
| zokier wrote:
| If the defaults are not changed, then what would be the
| difference between v7 and v8?
| cygx wrote:
| If backwards compatibility was kept, there would be nothing
| special about v8 - it would just be the next major relase
| after v7.
| sigzero wrote:
| No, Perl needs to move forward. v8 would be a sane timeline
| since that is a year or two away anyway.
| eruci wrote:
| You can build anything in any programming language, even byte
| code/assembly if you're so inclined. What you end up using is the
| one that can do the job faster. I built a custom web store
| yesterday entirely in mod Perl in 2 hours flat (
| https://store.poidata.xyz ). If you can beat that in some other
| programming language, like Python, by all means, stop using Perl.
| einpoklum wrote:
| > What you end up using is the one that can do the job faster.
|
| Not necessarily. Maybe you're interested in:
|
| * Performance optimization.
|
| * Maintainability.
|
| * Accessbility to more programmers (= fashion)
|
| * Conforming to organization policy on the language to use
|
| * Code readability
|
| etc. Different target function -> different considerations.
| eruci wrote:
| Agreed. These are fair points of consideration. In my case
| though, the main one to consider is speed of development.
| tyingq wrote:
| _" We're determined to have improved OO syntax in a future
| release, and we'd love that to be v8, but we don't want to hold
| up this plan because OO needs time to mature."_
|
| I wonder what this means. Especially if signatures are on by
| default, the OO syntax is pretty straightforward already, with
| most boilerplate gone. Like: package Some::Object
| { sub new ( $class, $args = {} ) { bless
| $args, $class; } }
| clscott wrote:
| This is the current proposal (it's a living document). For
| example it was just decided to drop the CONSTRUCT phaser and
| likely the common keyword.
|
| https://github.com/Ovid/Cor/wiki/Corinna-Overview
|
| This is an implementation of some of the ideas that is proving
| out to be faster (execution wise) than hash based objects:
|
| * https://metacpan.org/pod/Object::Pad
| chrisseaton wrote:
| > with most boilerplant gone
|
| Boilerplate class variable, boilerplate args variable, both
| written twice, deliberately cryptic whimsical 'bless' operation
| that for some reason needs to be done manually. Come on...
| tyingq wrote:
| The boilerplate class and args aren't mandatory, @_ still
| exists. I put them in the example to mean that if you wanted
| to use them, you don't have to pull them out of @_ with
| boilerplate.
|
| As for bless(), it's what makes Perl OO work. Getting rid of
| it is an option, but to me getting rid of it makes things
| more cryptic.
| chrisseaton wrote:
| > As for bless(), it's what makes Perl OO work. Getting rid
| of it is an option, but to me getting rid of it makes
| things more cryptic.
|
| Yeah I get it... but it's still boilerplate. Something you
| have to write out manually each time which you don't need
| to do in other languages.
| tyingq wrote:
| Yes, but it is significantly less boilerplate than
| before.
|
| If you get rid of bless(), you would need to add some
| equivalent to "package" that is OO specific rather than
| just namespaces, and/or a magical constructor method
| name. That (to me) is no less whimsical than bless.
| eCa wrote:
| I would guess something that allows defining classes in a way
| that resembles Moo or Moose.
| j4yav wrote:
| I once loved Perl, it was the first language I learned, but
| reading through the comments and link I don't see how you turn it
| into a modern, well loved and well used language (or even stop
| the decline) through small improvements but no grand vision, or
| by stepping away from the past in a meaningful and painful way.
|
| I wish them nothing but success, and sincerely hope their plan
| works, but I personally didn't read anything there that made me
| think "oh wow, I'll have to give Perl a try again when they
| deliver on their vision."
| dash2 wrote:
| I wonder if they got burned by Perl 6/Raku. That had tons of
| new features but took so long to deliver that it became a
| burden. Anyway, I think you're right: they have to be more
| proactive than just going for "feature parity with a modern
| language".
| Stranger43 wrote:
| I don't remember anyone paying much attention to perl6 before
| long after perl had peaked. It was for a while seen as an
| potential savior for perl but that faded too.
|
| It was more about PHP, Ruby and Python entering the stage and
| diluting the market for scripting languages by each offering
| something special that one set of users really wanted weather
| it be an easier deployment path better standard libraries or
| a more beginner friendly community.
| G3rn0ti wrote:
| Yeah, Perl 6 created a lot of confusion especially inside the
| Perl 5 community. But, in the end, they figured it all out:
| Perl 5 lives on and Perl 6 got out of its way by renaming
| itself to Raku. And, for the record: Raku itself is a gem of
| a language, I believe. A pretty solid OO system, optional
| typing, powerful language constructs, stellar Unicode support
| and somehow it is still staying true to Perl's rather
| pragmatic and, if I may say so, libertarian approach to
| software developing. I personally love raku's "grammars" most
| because they render writing parsers a routine job, it's
| amazing and no other programming language provides such a
| feature.
|
| If you're interested I strongly suggest you to check out
| Brian D Foy's book on Raku:
| https://www.oreilly.com/library/view/learning-
| perl-6/9781491....
| vram22 wrote:
| How about the _reported_ Perl6 / Raku speed issues? Saying
| "reported" because I have not done an in-depth study if
| they exist, just read about it briefly somewhere (and a
| while ago, may a year or so). If they did/do exist, was/is
| anything being done about them? Asking because I, for one,
| found both Perl 5 and 6 interesting, and the language
| features of both, somewhat unusual and powerful.
| G3rn0ti wrote:
| I think Raku is still quite a bit slower. But I am not
| up-to-date with the latest state. However, this is "just"
| a matter of optimization of the interpreter over time.
| It's just that Perl 5's interpreter had a head start of
| more than 25 years.
| vram22 wrote:
| Yes, that is possible. Java was dead slow early on (I
| first used it soon after it came out, and pioneered use
| of servlets in my company at the time), but after Sun's
| management threw millions of dollars and high-end tech
| people at the problem, it got fast enough for many uses
| in a few years, what with the Hotspot VM and JIT tech and
| so on.
| vram22 wrote:
| Sorry, the millions of dollars was mostly for marketing
| (which is largely what led to its huge adoption), but at
| least some of that money would have been used to hire top
| people like computer science compiler specialist PhDs to
| work on making it faster. I had read about that at around
| that time.
| thatwasunusual wrote:
| > I wonder if they got burned by Perl 6/Raku.
|
| I have the same feeling. I've been programming Perl since mid
| 90s, and I was - as many others - hyped when Perl 6 was
| announced early 2000s. 20 years later, it's just different
| programming language in my eyes; I won't spend any time on
| it, because if I need Perl, Perl 5.x will do just fine.
|
| Unfortunately, because of Perl 6/Parrot/Raku, or what the
| current name is, I think it made many developers get off the
| Perl train. There are lots of good frameworks for Perl that
| makes it super-easy to get something up and running really
| quickly; * Mojolicious (and its multitude
| of plugins, Minion etc.) * DBIx::Class (not pretty,
| but still just works) * Moose/Mouse (for decent OOP)
| * JSON::Validator (and friends, for mocking and validating)
|
| The list goes on, but this is the "out of the box"-stuff for
| me to get up and running with something, if not just a
| prototype of something.
| Macha wrote:
| Wasn't Perl 6 itself a reaction to the fact that a lot of
| developers already leaving for PHP in the web space and
| Python in the "I need something like a shell script, but
| need/want a real programming language".
| thatwasunusual wrote:
| I honestly don't remember. Nor do I care anymore. :)
| bmn__ wrote:
| No. http://strangelyconsistent.org/blog/happy-10th-
| anniversary-p...
| raiph wrote:
| As Jon Orwant (supposedly) said in 2000 (quoting from the
| article you linked):
|
| > we are fucked unless we can come up with something that
| will excite the community, because everyone's getting
| bored and going off and doing other things
| yabadubakta wrote:
| I recommend going to https://raku.org/ and reading up on the
| language because Raku actually has features "modern
| languages" do not. E.G. the grammars.
| sigzero wrote:
| There is no "wonder". They did.
| wpietri wrote:
| I wrote a ton of Perl as well, but that stopped long ago. In
| the meantime I've learned a number of languages, Python and
| Ruby included. Maybe what they're doing is enough to slow down
| the decay in terms of user base. But I'd be shocked if it
| reversed it either by bringing old Perl users back or getting
| new ones.
|
| Of course, it could just be that this is an internally focused
| text. Maybe there's some other document that explains a product
| vision that says, "Perl will be better at X,Y, and Z for groups
| A, B, and C"?
| cestith wrote:
| This document is mostly discussing how they can deliver on a
| product vision without breaking existing code too badly. The
| product vision would be a different document of which
| features to add and why.
| wpietri wrote:
| Oh, sure. But does that different document exist?
| fangorn wrote:
| I liked writing Perl a lot, but when it came to reading, let
| alone fixing, other people's Perl, it was always a bit of a
| nightmare. That's one of the main reasons I was reasonably
| happy to move away from it - nobody seemed to heed "Just
| because you can, doesn't mean you should" mantra. Sure you can
| write good Perl, and I always did my best in that area, but it
| was not the reality for most Perl programs out there. CPAN also
| turned to a bit of a mess at some point, and in general
| dependency management was non existent, really. Containers
| could help alleviate this pain now, to an extent. Still, it
| would need to seriously improve to lay any claims to being able
| to write modern stuff in Perl.
| forgotmypw17 wrote:
| I use almost no third-party modules and write largely what I
| call "PHP style" Perl, so mostly $variable =
| SomeFunction($someOtherVariable);
|
| I've had no issues with reading my own code, and others are
| able to follow along as well.
|
| I admit that, because of its poetry-enabling flexibility, in
| terms of readability and maintainability foot-shooting, Perl
| is like an AK-47 with a full clip and no safety.
| philote wrote:
| CPAN is great, but also horrible. There are so many packages
| that do the same thing, and it was often hard for me to know
| which to pick. Want OO? Use Moose, or Moo, or Mouse or
| whatever else. Then hope that the one you picked will
| continue to be maintained. I resisted moving to Python for a
| long time, but when I finally did it was a bit refreshing to
| have more packages built into the language so I didn't have
| to make so many choices on what 3rd-party libraries to
| install. Perl will always have a special place in my heart
| though.
|
| As far as reading code goes, Perl could be particularly
| messy, but I've seen some very hard to read Python code as
| well. And Javascript... I still don't get why people want to
| use it server-side. But all these languages have tooling that
| helps make sure code is at least formatted correctly, and
| follows some sort of best practices. I think one of the
| hardest parts of reading Perl, to me, was that it wasn't
| always clear what package a particular function or class was
| imported from.
| petre wrote:
| Just use Moo or none at all. Moose is to big and slow pulls
| too many deps for my taste, Mouse involves XS. Perl is
| messy if your coding is messy. Why server side? Because
| DBI, Mojolicious and a good glue language for business
| logic already written in Perl. Would I pick it for
| something new? Maybe simple scripts or some quick web
| service or web API access tool or things involving text
| processing.
| thatwasunusual wrote:
| > CPAN is great, but also horrible. There are so many
| packages that do the same thing
|
| IMO, that's a good thing. Imagine having only one choice at
| any layer in society (to make my example extreme): one type
| of house, one type of car, one type of computer, on type of
| OS, one type of file system, one type of programming
| language etc.
|
| > Want OO? Use Moose, or Moo, or Mouse or whatever else.
|
| This is true; no built-in "proper" OO has been a pain for
| Perl for a long time. However, I've used to love Mouse
| (like Moose, but a trillion times faster), and I've never
| had any problems with it.
|
| There are plans to inject proper OO into Perl, though.[1]
|
| > Then hope that the one you picked will continue to be
| maintained.
|
| This is my biggest problem. I wish there was a "system" of
| sorts that let _groups of people_ adopt/take over a Perl
| module and Just Fix It (tm). Having only one person take
| over a module/package isn't good enough; there must be more
| people involved in fixing things.
|
| One good example is Crypt::Curve25519[2] which could/should
| have been fixed years ago, but because the maintainer is
| inactive, it won't happen.
|
| And now we're back to where we started: because things
| doesn't get fixed, people create their own versions of CPAN
| packages just for the F[ix|uck] of it.
|
| [1] https://dev.to/ovid/bringing-modern-oo-to-perl-51ak
|
| [2] https://metacpan.org/pod/Crypt::Curve25519
| petepete wrote:
| I did a fair amount of Perl just over a decade ago but can't
| really see any situation where I'd reach for it over Ruby now.
| Ruby has Perl's text manipulation goodness with a saner syntax.
| blacktriangle wrote:
| Performance.
|
| Perl was a legit tool in bioinformatics due to its insane
| text parsing performance. Ruby performance is absolute
| garbage.
| yabadubakta wrote:
| And ubiquity: there's a Perl for almost all systems
| eu wrote:
| I wonder for how long..
| anthk wrote:
| OpenBSD ships it by default, with Pledge support.
| PLenz wrote:
| I still do my NLP preprocessing in perl for this exact
| reason
| phone8675309 wrote:
| I learned Perl in the mid 2000s because I was working with
| a company that took text (and sometimes spreadsheet) dumps
| of public records data and processed them into a database.
| The entire ETL pipeline was a set of Perl scripts, and, as
| far as I know, that system is still running. The Perl
| iteration was actually the second iteration of that system
| - the first iteration was a set of C programs and shell
| scripts that were replaced over time.
|
| The rich ecosystem of tested Perl modules for file formats
| along with the testing frameworks made coping with change
| bearable - not enjoyable, but bearable.
| blacktriangle wrote:
| Oh man the ecosystem. I still think CPAN set the bar for
| what a high-quality language ecosystem should look like.
| npm and rubygems look like amateur hour by comparison.
| yoz-y wrote:
| Do they have to enter the modern world and compete with the
| modern languages?
|
| Personally, I'd like them to focus on shell scripting and tool
| making. (But that's what I use Perl for, so of course I'd say
| that)
| j4yav wrote:
| They don't have to, but it seems to be their stated goal.
| forgotmypw17 wrote:
| It is already modern. The Perl community has boldly remained
| committed to compatibility over chasing the shiny and breaking
| shit, unlike many others (coughphpcough), which is why I chose
| Perl for a new project a couple years ago.
|
| I don't WANT so-called modernization. I want my program to
| remain working without having to change. it
| klibertp wrote:
| > I want my program to remain working without having to
| change. it
|
| Can't you bundle the interpreter, possibly stripped down and
| compiled as a static binary, along with your program?
|
| But yes, strict backward compatibility, while having many
| downsides, provides a lot of value, too. The trade-off is
| situation and project dependent, and it's good to have both
| kinds of platforms: ones solid as a rock and moving slowly,
| and ones moving fast and breaking things.
| jrsj wrote:
| This will work for awhile until you stop receiving security
| updates and have to adapt to breaking changes to do so.
| forgotmypw17 wrote:
| Bundling the interpreter would interfere significantly with
| being able to download and run from source.
| bmn__ wrote:
| https://metacpan.org/pod/pp
| https://metacpan.org/pod/staticperl
| https://metacpan.org/pod/perlcc
|
| But that's the worst way to deploy a program.
| eddyg wrote:
| Why wouldn't the future focus be on Raku at this point? Perl is
| (was?) a great language, but Raku offers so much more.
|
| Of course Raku has the "expected" things from Perl like classes
| and all the fantastic regex and string manipulation features.
|
| But Raku brings:
|
| * Optional/gradual typing (and unlike Python, declared types are
| enforced)
|
| * Pattern matching, where different function definitions can be
| defined for different input values, like Haskell
|
| * Multiple dispatch, so different function bodies can be defined
| for different sets of argument types (like pattern matching, but
| based on types, like Julia)
|
| * Lazily-generated sequences, like Haskell or Clojure
|
| * Lisp-like AST macros
|
| * A built-in syntax for defining grammars and generating parsers
|
| Not to mention junctions, autothreading, hyperoperators (vector
| operators), asynchronous operations, parallelism, concurrency,
| and multi-core support. The list goes on and on...
|
| It's unfortunate that so many programmers I talk to aren't even
| willing to consider looking at Raku, even though it has a _lot_
| to offer.
|
| But I am confused by this "future" where Perl wants to continue
| on to v7, v8...
| arunix wrote:
| It wouldn't be much of a future if the large amount of existing
| Perl code couldn't be utilised.
|
| The original vision for Perl6 included a runtime called Parrot
| which would have been capable of running both Perl6 and Perl5.
|
| If Parrot had been realised, Perl6(Raku) and Perl5 would have
| been able to interop similar to how Java and the other JVM
| languages can.
|
| But without that, Raku and Perl remain incompatible so e.g. the
| existing large Perl ecosystem can't be leveraged from Raku.
| raiph wrote:
| > Raku and Perl remain incompatible so e.g. the existing
| large Perl ecosystem can't be leveraged from Raku.
|
| Au contraire, they remain _compatible_ along the lines shown
| in this example from a StackOverflow answer[1]:
| use Text::BibTeX::BibFormat:from<Perl5>; ...
| @blocks = $entry.format;
|
| I'll be happy to dialog about this compatibility, but the key
| thing is to start with an open mind; a recognition that the
| original vision predated Parrot; and a recognition that
| Rakoons have never relinquished that original vision even
| while many of us are delighted that Perl folk are keeping
| Perl healthy as a separate thing in its own right.
|
| To be clear, the realization of Larry's original vision is
| not constrained to interop with Perl. Raku has extraordinary
| potential, some already realized, for _pan-language_
| compatibility via its Inlines[2].
|
| The steady improvement of the exemplar Inline[3] for the last
| 6 years; its evident maturing; its suitability as a solid
| blueprint for upgrading all the others; all of this bodes
| well for being able to use a lot of the world's best existing
| code from within Raku this decade, with Inline::Python quite
| plausibly shining in this regard within the next 2-3 years.
|
| [1] https://stackoverflow.com/a/45181464/1077672
|
| [2] https://modules.raku.org/search/?q=inline
|
| [3] https://github.com/niner/Inline-Perl5
| nickelcitymario wrote:
| I'm a little ignorant about Raku, so take my comments with a
| grain of salt, but...
|
| Saying Raku is the future of Perl is like saying Objective-C is
| the future of C. Or Ruby is the future of C. Or Python is the
| future of C. Or C++ or... really most languages out there,
| because most of them are built on top of or branched from C.
|
| Yet we're all quite capable of recognizing that each as its own
| place and path and future. They didn't replace C, and Raku
| didn't replace Perl.
|
| And, of course, Perl built on what came before: C, AWK, shell
| scripting, sed, BASIC, LISP... and Larry Wall never pretended
| otherwise.
|
| So I think Raku is a very interesting project, but calling it
| the future of Perl seems mistaken. Raku is the future of Raku.
| atweiden wrote:
| > I'm a little ignorant about Raku, so take my comments with
| a grain of salt, but...
|
| That makes two of us. Albeit, I began working with Raku in
| 2015, when it was still called Perl 6. What follows is just
| my opinion, so take my comments with a grain of salt.
|
| > Saying Raku is the future of Perl is like saying
| Objective-C is the future of C.
|
| This isn't true. From the beginning, Perl 6 was always
| envisioned as the successor language to Perl 5. The reasons
| given for this were myriad: Perl 5 would benefit from having
| a more regular syntax (e.g. `$this{}` would become
| `%this{}`), a decideably parseable implementation [1], first-
| class OOP support in the standard library, as well as gradual
| typing and a concurrency/parallelism story, amongst many
| other things.
|
| Objective-C is more of a bolt-on addition to C. It's less a
| separate programming language _from C_ than it is a
| potentially useful paradigm for programming _in C_.
| Objective-C was never designed to "replace C" the way Perl 6
| was designed to replace Perl 5.
|
| > and Raku didn't replace Perl.
|
| Well, it should've. Other than nostalgia attached to
| graybearded Perl developers of yore, you can see ITT the
| writing is on the wall for Perl 5. IMO Perl 5 looks clearly
| destined to the same fate as Sed and Awk: a CLI "power tool"
| -- critical to infrastructure in unappreciated ways -- but
| ultimately disposable and not a serious solution.
|
| Raku is to Perl 5 what Perl 5 is to Awk, IMO.
|
| In my view, it was deeply unfortunate certain loud minorities
| from Perl 5 were able to derail Perl 6, as if _that_ would be
| the thing that could save Perl 5 from its destiny of utter
| irrelevancy.
|
| [1]: https://news.ycombinator.com/item?id=5770531
| shagie wrote:
| While Raku was envisioned to be the successor to perl... I
| remember going to the Perl Conference back in '00 and
| thinking "Oh, Neat!" and being excited about Perl6.
|
| And I waited. And I waited. And I waited.
|
| The mindshare of improving perl5 and making it competitive
| with the emerging application servers and compelling for a
| web development platform rather than Java wained.
|
| Java became more and more useful over the next decade while
| perl5 remained static. People wrote some rather impressive
| libraries - but the mindshare wasn't there. Mod_perl in
| apache was useful... but BEA WebLogic was becoming more and
| more useful.
|
| Meanwhile, more and more features and major changes were
| slated to be part of perl6... and the release date felt
| more and more distant in the future for where I could
| actually get something to work in a production environment
| with perl6 and say to my manager "this should be what we
| target for new development."
|
| I had changed two jobs between first getting hired as a
| perl programmer and perl6 being released (though I pity
| anyone who would have tried to run perl6 in production in
| '15).
|
| So while Raku is neat... it really lost its mindshare of
| developers over two decades.
|
| The writing is on the wall for perl5 - I left that in '10
| when I was hired as a Java developer rather than a Perl
| developer.
|
| But the writing is on the wall for Raku too - already. In
| '00 and even a few years later, there was still enough
| inertia to say "perl6 is out, lets move our stack from
| perl5 to perl6". Today? I don't see it. I think there would
| be a stronger push from perl5 to Java (or other JVM
| language) or Python depending on the shop.
|
| The last version of perl4 was in '93 when perl5 started
| work. Perl 5.000 was released October 17, 1994. 5.004 was
| in '99... and then the long dark time began as efforts for
| perl6. Four years later we got perl 5.6... and another five
| years for perl 5.8. Still no perl6.
|
| Raku won't replace perl5 because any place that perl5 is
| going to be replaced isn't likely going to move to Raku.
| The effort to move from perl5 to Raku is likely similar to
| the effort to move to Java, or Python, or Ruby... all
| languages with greater mindshare and developer stories (and
| Jetbrains IDEs).
|
| I've left perl. Any scripting that I do now is groovy which
| leverages my tooling in Java.
|
| In the "well it should have replaced perl5" - that boat
| sailed over a decade ago when the systems running perl were
| being migrated to other platforms and languages... and the
| developers lost faith, had their beards turn gray, and
| retired.
| unixhero wrote:
| Because Raku and Perl5(7,8,9) communities are now two separate
| worlds and is to be considered two separate languages.
|
| Raku seems like an incredible language which I would learn if I
| was a capable enough developer to understand the implications
| of everything it offers.
| melling wrote:
| I used Perl for years... Perl missed its transition window.
|
| Randall Schwartz and the community would tell you that "Perl is
| more popular than ever", because the rising tide of programmers
| meant it was used by more people.
|
| The Perl 5 vs Perl 6 created weakness and Python filled the
| void and won over that segment.
|
| It became the new standard. Now it will be very difficult to
| dislodge.
|
| Anyway, the entire Perl 6 fiasco will serve as a lesson for
| future projects.
| brongondwana wrote:
| See also "IPv6" - the number 6 is cursed.
| homarp wrote:
| see also PHP6
| brokenkebab wrote:
| While confusion around P6 certainly hurt Perl, Python started
| to conquer over areas previously held by Perl even before
| that. AFAICT educational establishments didn't like Perl
| because it embraces expressivity. There's more then one way
| approach feels good once you grok it, but for the most
| teachers its anathema - it means you need to explain much
| more.
| qsort wrote:
| Eh, kind of. Perl as a teaching language is obviously
| terrible, but on the other hand Python outside of academia
| is basically the DSL to call numpy. I think the problem is,
| more simply, competition. Now that Perl isn't the only
| reasonable dynamic language (you have ruby, python,
| nodejs...), people have more choices, and are ultimately
| just going to use what they already know as a 'plumbing'
| language.
| zokier wrote:
| Raku is neat language, but it's not Perl. You might as well ask
| if the future is Python.
|
| Perl v7 as I understand aims still to be fully compatible with
| Perl 5, and function as a bridge towards v8. This is to attempt
| smooth gradual transition, something that Raku distinctly does
| not have.
| raiph wrote:
| Fwiw Raku does have an attempt at a smooth gradual
| transition, and in some regards it's a remarkable success.[1]
|
| That said, its approach is profoundly unlike the v7 strategy.
| My take on v7 is that it boils down to:
|
| * Pulling off such a silky smooth gradual transition that it
| can continue to be used for /usr/bin/perl without unduly
| inducing distro and/or user revolt/forking/eoling.
|
| * Setting the stage for a gradual clean up / refresh loosely
| akin to Python 3 relative to Python 1, but without Python's
| abrupt incompatibility discontinuities and the consequent
| decade of contentious and costly transition pain.
|
| [1] https://news.ycombinator.com/item?id=26572531
| cygx wrote:
| Raku regex performance sucks, for one.
|
| Let's parse some data into a hash in Perl:
| %words = ($input =~ /([^\n\t]+)\t(\N+)/g);
|
| In Raku, equivalent code will be slower by an order of
| magnitude or more. The only way I've managed to get comparable
| performance is to write code like this: use
| nqp; my str $str = $input; my int $pos = 0;
| my int $chars = nqp::chars($str); while $pos < $chars {
| my int $tab = nqp::index($str, "\t", $pos); my int
| $nl = nqp::index($str, "\n", $tab);
| %words{nqp::p6box_s(nqp::substr($str, $pos, $tab - $pos))} =
| nqp::p6box_s(nqp::substr($str, $tab + 1, $nl - $tab - 1));
| $pos = $nl + 1; }
|
| Generally, the situation has been getting better, though. In
| contrast to the early days, for $input.lines
| { my $tab = .index("\t");
| %words{.substr(0, $tab)} = .substr($tab + 1); }
|
| also performs adequately today.
| Pet_Ant wrote:
| What exactly is Larry Wall's involvement with Perl anymore? Has
| he moved entirely to Rakudo (ne Perl 6)?
| cygx wrote:
| For the record, the language is called Raku, whereas Rakudo is
| the compiler.
|
| Larry stepped back from Perl 5 a while ago, but used to
| actively contribute to Rakudo until 2017 or so. I haven't seen
| him around as much over the last couple of years, but then
| again, I also do no longer keep abreast of Raku development and
| might jsut have missed it...
| bmn__ wrote:
| retired https://youtu.be/T2e0xSOHd-0
| G3rn0ti wrote:
| Larry Wall designed Perl 6 i.e. Raku and created the original
| parser. I am not sure if he is still actively working on it.
| The actual implementations, however, were done by others. So
| like Lisp or C Raku is actually a specification driven language
| in contrast to languages like Perl 5, Ruby or Python where the
| most popular interpreter serves as the specification.
| cygx wrote:
| _Raku is actually a specification driven language_
|
| That hasn't been true for a while. The test suite is supposed
| to be canonical, whereas the 'specification' hasn't been kept
| up to date with language evolution.
| G3rn0ti wrote:
| > whereas the 'specification' hasn't been kept up to date
| with language evolution
|
| You mean Rakudo added features not listed in Raku's
| specification? Which ones?
| raiph wrote:
| That hasn't been true for a while.
|
| Within minutes of announcing Raku nearly 21 years ago Larry
| answered a question about it from the audience[1]:
|
| > Question: Will Raku have specs ...?
|
| > Larry: ... develop the real regression tests into a
| validation test ... then we actually have a machine-
| readable spec. And to me that's actually a lot more
| important than what the verbiage on the human readable
| thing says.
|
| It took years before folk caught up with Larry's intent,
| but the regression test suite has been called "roast"
| (Repository Of All Specification Tests) for something like
| 15 years and what you're calling "the 'specification'" was
| renamed to "the 'speculation'" around the same time.
|
| [1] https://www.perl.com/pub/2000/10/23/soto2000.html
| lizmat wrote:
| FWIW, the "specification" now only has historical value,
| and possibly as an inspiration for implementing features
| that were once considered. It is nothing more than that,
| nor has it ever been.
|
| The test-suite _is_ canonical: being able to pass a
| significant number of tests, allows you to say you 've
| implemented a significant portion of the Raku Programming
| Language.
| Pet_Ant wrote:
| > The test suite is supposed to be canonical, whereas the
| 'specification' hasn't been kept up to date with language
| evolution.
|
| This is so disappointing. Feels like the language over time
| has lost everything that made it interesting. PUGS for
| example.
| raiph wrote:
| I hear you feel disappointed, but it is presumably due to
| someone having misled you due to their misinterpretation
| of Larry's design.
|
| Roast (the Repository Of All Specification Tests) has,
| for over 20 years in design terms, and 15+ years in
| reality, been Raku's canonical, _machine readable_
| specification that is versionable, branchable, forkable,
| mergeable, and which is backed by a PL design that
| envisages its versioning, branching, forking, and
| merging.
|
| So we now have a suite of approaching 200K tests that
| provide a principled _software engineering_ way to
| generate a single boolean True|False that a so-called
| Raku compiler does or does not precisely implement the
| machine readable specification.
|
| Features cannot be removed or added without not only
| being specified in language, and if appropriate subjected
| to formal analysis, but also openly discussed and
| debated, implemented in a branch, hammered on for however
| long with beta testers trying it out to see if it's worth
| removing/adding, and only _then_ arriving in the official
| master branch of roast.
|
| This can and has meant there can be up to a 3 year period
| before changes become official, or, conversely, a 24 hour
| period for a security patch to become official, and the
| system _guarantees_ that any risk of breakage is
| controlled by _users_. This is a revolutionary level of
| centralized /distributed digital governance.
| jerf wrote:
| This is a good "patch the holes" plan, but I think it needs to be
| followed up in short order by some deeper thinking. And some very
| painfully honest thinking.
|
| Paul Graham, whom some of you may have heard of, once wrote an
| essay about "What Languages Fix": http://paulgraham.com/fix.html
|
| I think of it a bit differently, which is that languages have a
| _thesis_. (Not quite the same but a lot of overlap.) Paul writes
| that what Perl fixes is "Shell scripts/awk/sed are not enough
| like programming languages." I would personally rephrase it to
| something like "There isn't(/wasn't) a language dedicated enough
| to Getting It Done."
|
| If you put yourself in the context of the time, this was
| absolutely true. Most languages for getting things done involved
| a lot of drama and boilerplate. Popular languages of the day
| would require you to implement your own hash table for a quick
| script, if you didn't have one on hand. Libraries for that
| existed of course, but the Internet wasn't really up and running
| the way it is now yet, and things were hard to find. Perl came in
| and provided a great Get It Done languages.
|
| However, landscapes evolve over time and so do language theses.
| C++ is a great example of something that has changed, going from
| "C should have great support for object orientation" to something
| more like "C++ should be the choice for programmers who want
| zero-cost abstractions". Part of the reason for that change is
| that the former thesis is no longer a compelling one, on the
| grounds that "great object orientation support" is now simply
| table stakes for that sort of language. C++ could not drive
| forward on that thesis in 2021.
|
| That is also Perl's _real_ problem right now. It lacks a thesis.
| It has very narrow advantages in text munging still, but for
| almost anything else, I now have an abundance of languages that
| "get it done" just as well or better. For context, I've got about
| 15 years of Perl being my _primary_ language under my belt, so
| that means something; it 's not a secondary or tertiary language
| for me, and I still have plenty of choices to reach for. (Heck,
| I've even come to prefer Go for JSON munging quite a lot of the
| time, because with the right tooling it's really easy to parse
| JSON straight into objects that I can call methods on
| meaningfully, which is actually more convenient and useful to me
| than presenting me with a generic hashtable/array representation
| that I then have to write a lot of code to crawl over from the
| "outside".) The world has moved on, and Perl's problem isn't
| necessarily that it lost but that it _won_. It has successfully
| convinced the world that Getting It Done doesn 't need to come
| with all the drama and paperwork and complexity of its late 1990s
| peers. But that means that just like C++ won and it couldn't
| continue operating on its "good OO" thesis, Perl needs a new
| thesis.
|
| Moreover, it's going to have to be brutally honest in the
| selection of that thesis, because a lot of the obvious ones are
| already covered by Python, and trying to chase Python on its own
| turf is going to be a losing game. Perl 6/Raku also has its own
| thesis, which is now also essentially unavailable to Perl 5.
| Unfortunately, choosing a thesis successfully isn't necessarily
| about what the Perl team "wants" so much as where there is space
| in the programming language market, and in the intervening, gosh,
| _decade_ or so that Perl 5 has been floating along without a
| thesis, a lot of the easy or obvious answers have been fairly
| well covered by other languages.
|
| One thesis option is "Old perl code should degrade gracefully",
| which is the "declare victory and walk off into the sunset"
| option. To be honest, it's one that should be seriously
| considered. I think graceful retirement is a test a lot of
| language committees fail. Here I'd look for improved refactoring
| tools to help automatically translate old code into better code
| to modern standards and other such things being the standard, for
| instance.
|
| But if the Perl 5/7 team wants a different thesis, it's something
| I think they need to decide consciously. I don't have a
| suggestion. But I can offer this word of hope; the space of
| possible theses is really quite large. The point of view where it
| looks like every possible language exists already is a point of
| view that is too narrowly stuck in the details of today. With
| just a bit of change in perspective, there's a lot of untapped
| fields.
|
| Tempering that hope a bit, Perl's new thesis really needs to be
| something that Perl's existing code and community brings
| something powerful to. If you come up with a possible thesis, but
| look at it honestly and say "That's probably something better
| done with a brand new language entirely", it's probably not a
| functional thesis for Perl. And this does cut the space back
| somewhat. But some persistent thought may still find something
| interesting.
|
| Personally, I'd also be looking carefully and honestly at what
| Perl is still doing and consider shedding old use cases/theses.
| For example, while Python is not experiencing a popularity
| crisis, consider a hypothetical world in which the only people
| still using Python were basically NumPy users. It would be a
| valid choice to move forward with Python development in a way
| that privileged such use, at the expense of "general purpose" use
| going forward. I'm not involved enough with Perl to know what
| that would be, just offering a meta-option to consider.
|
| And let me close on what I opened with... this is a good "patch
| the holes" plan that should be all means moved forward with, to
| give space to breathe. I'm positive on the plan, not critical of
| it.
| knbknb wrote:
| You are asking for a "thesis", for a unique proposition.
|
| Well, maybe Perl 5's backwards-compatibility can be marketed,
| (or will emerge anyway, without any marketing), as a key
| advantage.
|
| "These 20 year old Perl 5 scripts still run without any
| modifications on the new machine. Amazing!..."
|
| There are not many languages that have this property of long-
| term stability. One of them is R , see recent Blogpost "Ode to
| R stability" by Dirk Eddelbuttel, one of the R authorities (and
| Debian Maintainer)
|
| http://dirk.eddelbuettel.com/blog/2021/03/20/#ode_to_r_stabi...
___________________________________________________________________
(page generated 2021-03-24 23:01 UTC)