[HN Gopher] The reports of Perl's death have been greatly exagge...
___________________________________________________________________
The reports of Perl's death have been greatly exaggerated
Author : zdw
Score : 87 points
Date : 2021-10-19 16:20 UTC (1 days ago)
(HTM) web link (phoenixtrap.com)
(TXT) w3m dump (phoenixtrap.com)
| jerf wrote:
| The real problem with these kinds of posts is the equivocation in
| the word "dead".
|
| People wanting to defend languages (also APL lately) want to
| implicitly use a definition something like "0 people are using it
| and no work is being done in it", but by that standard you can't
| ever declare anything dead. That doesn't make the definition
| "wrong" but it does make it not useful. The purpose of a
| definition is to split the relevant set of possibly values into
| at least two non-empty sets.
|
| Other people are looking at the first and second derivatives of
| how many people are using it, how popular it is now compared to
| its height (in the programming language world it's already a
| problem if your "height" of usage isn't _right now_ ), and the
| likelihood of it ever coming back.
|
| From that point of view, Perl 5 is, if not _dead_ , certainly
| very close. To me, most tellingly, Perl 5 has no plausible path
| that I've heard for acquiring some unique value proposition that
| can give it a new lease on life. As I said in
| https://news.ycombinator.com/item?id=26567151 , in a lot of ways
| Perl's biggest problem right now is that it _won_. It convinced
| people that its way was good, and as a result, Perl 's previous
| value proposition has been incorporated wide and far in other
| languages. The only time I pick up Perl now is when I have the
| need for a seriously heavy-duty string munging task that fits
| into about 200 lines, and I get _huge_ wins from the RE syntax in
| Perl. And by time-of-use, Perl is probably my "best" language,
| the one I've used for more clock time than any other. Even so,
| that's where I am in 2021.
|
| I would encourage the community to either decide that it's OK
| just continuing on as it is, or decide that it wants to try to
| find that new unique value proposition that will give it some
| sort of unique value in 2023 or 2024. But there isn't an option
| where Perl continues along as it is and it experiences some sort
| of burst in growth. You have to pick one, you can't get the
| advantages of both.
| notreallyserio wrote:
| This sort of absolutism is so frustrating. If the term doesn't
| describe something 100.00% right, someone's going to nitpick.
| Analogies suffer the same fate.
| [deleted]
| justinator wrote:
| _> I would encourage the community to either decide that it 's
| OK just continuing on as it is, or decide that it wants to try
| to find that new unique value proposition that will give it
| some sort of unique value in 2023 or 2024_
|
| But that's what Perl 6/Raku was supposed to be, right? And that
| turned out to be a disaster.
| jerf wrote:
| I don't guarantee the _success_ of an effort to find a new
| value proposition! It is necessary, not sufficient.
|
| And it broke away so far from Perl 5 that it is no longer
| Perl 5's new value proposition. The Perl 5 community will
| need to come up with one of their own.
| justinator wrote:
| In time it broke away but ~20 years ago, the promise was
| backwards compatibility. Looking back, that's madness, but
| it's one of the decisions that totally grounded development
| of Perl 5.
| newaccount2021 wrote:
| if people want to try to quantify "dead", a good place to look
| at is activity on cpan
|
| https://metacpan.org/recent
|
| many packages I rely on have weekly updates
| chefandy wrote:
| The _only_ reasons I could think to use perl over Python are
| regex execution speed and 'maybe' infeasibility of accessing
| PyPI so you'd need more built-ins, but still have plenty of disk
| space... though I haven't done any feature parity comparisons
| there.
|
| Am I missing anything?
|
| I liked Perl back in the day and used it a lot but even my old
| sweet-jesus-what-was-I-thinking Python code is a LOT more
| readable than my _cleanest_ old Perl code.
|
| I'd be curious to hear from folks who've also been deep in Python
| and Perl but stuck with Perl rather than Python-- different use
| cases? Coding styles?
| extortionist wrote:
| My job is split between maintaining a giant legacy perl
| codebase and doing new dev work in python. I vastly prefer
| python overall, but perl's still the best when you need quick
| one-off scripts to tear through log files or do some quick
| regex subs on a bunch of files.
|
| I don't think python has an equivalent of 'perl -p -i.bak -e
| 's/foo/bar/g' *', for example (which will do in-place regex
| substitutions on whichever files are passed in, additionally
| copying the original files to 'original.ext.bak').
|
| The regex syntax is also bit more streamlined in perl, so I
| find it quicker and easier to throw together a script that's
| just doing regex stuff in it. A simple example:
|
| >> $string =~ m/(pattern)/i;
|
| >> my $match_text = $1 || '';
|
| >> $string =~ s/pattern//gi;
|
| >> import re
|
| >> match_obj = re.find(r'(pattern)', string, flags=re.I)
|
| >> match_text = ''
|
| >> if match_obj is not None:
|
| >> match_text = match.group(1)
|
| >> string = re.sub(r'pattern', '', string, flags=re.I)
|
| Of course, the same magic that makes perl great for those one-
| off kinds of scripts makes it less than ideal for complex or
| long-living scripts that need to be maintained by multiple
| people, in my opinion.
| chefandy wrote:
| No doubt: the regex syntax in Perl is most efficient. I can
| envision using Perl more if I ever got back into a command
| line focused text manipulation workflow. I tend to use
| lighter-weight tools for things like your one-liner-- I
| believe `sed -i '.bak' "s/foo/bar/" *` is equivalent, but I
| disagree with the neckbeard purists who say you should always
| use the lightest-weight tool possible. If you're using Perl
| anyway and Perl can get the job done with the smallest
| cognitive load, that's the correct tool.
| sethammons wrote:
| We managed a several thousands node cluster of perl services. We
| took several years, but we recently finished migrated all of this
| off from stateful Perl to stateless Go all the while growing rps
| volume 40% yoy and migrating datastores as we scaled those too,
| continually improving stability and availability, adding
| features, and scaling the org from a few hundred people to a few
| thousand. We are now 100% off perl for our critical path.
|
| Perl is not on my resume :)
| alexeiz wrote:
| I haven't used Perl in ages. Seeing all these new features in
| Perl 5, I want to use it again. I've looked at Raku and didn't
| like it. I think it went astray and it doesn't fit the spirit of
| Perl (being practical).
| Animats wrote:
| There should be a convention where the APL people, the LISP
| people, the Perl people, and the Pascal people get together and
| talk about the good old days.
| manbart wrote:
| Include Tcl and I'm there!
| int_19h wrote:
| I miss Algol 68. ~
|
| (Seriously, though - in retrospect, it feels like most of the
| complexity that the language was criticized for is standard
| fare in PLs of today, often in the same shape.)
| justin66 wrote:
| I'm a little freaked out by the prospect of any crowd where the
| Perl people are the youngest ones.
| bachmeier wrote:
| What I wish would die is discussions of the death of languages.
| It's as useful as classifying people as good and bad athletes.
| Everyone is better or worse at some sports, and the threshold for
| switching from good to bad is purely arbitrary.
|
| It's better to have discussions with substance. "Perl job
| advertisements are down 34% in the last five years" might be
| useful. "Perl lacks libraries to do [task]" might be useful.
| "Perl is dying" isn't.
| pugworthy wrote:
| It's not dead until I retire my canvas bag from the first
| O'Reilly Perl Conference.
| bloblaw wrote:
| Perl is simply a tool. I still use it all the time for small
| scripts and automation.
|
| I know Python, Go, C#, and a bunch more....but I reach for Perl
| when the task calls for processing lots of text, or quick
| automation. Others might reach for Python or Ruby or Go.
|
| For me it's a better bash script, a better grep, a better awk, a
| better sed. That's what Perl was designed to be, and I don't
| think any other scripting language matches it for _that_ purpose.
|
| It is not a tool to build desktop applications or the first
| choice for web applications in 2021.
|
| But it _is_ still extremely useful for its niche...processing
| data /logs/text, or system administration tasks. It really shines
| there and that's how I use it.
|
| It's another tool in my toolbox, and learning Perl has made me
| more productive and I still reach for it today.
| davidw wrote:
| If you have to write forceful "It's not dead! Really!" blog
| posts, it kind of gives away the Weekend at Bernie's game.
|
| Snark aside, to try and add something more useful, having seen
| languages rise and fall, it seems that "not growing" or
| "gradually losing ground" are kind of what people label as
| "dead". If lots of people aren't regularly starting new projects
| with it... it's not healthy.
|
| I wrote something similar about Tcl years ago:
| https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
| forgotpwd16 wrote:
| >If you have to write forceful "It's not dead! Really!" blog
| posts
|
| How is this different from modern languages making similar
| posts about how they're very active?
| justinator wrote:
| Saying, "we're very active" is a different framing than
| saying, "Reports of my death have been greatly exaggerated".
| coldtea wrote:
| Because "we're active" is something you want to see in a
| language - even if the language has little adoption, being
| active is positive.
|
| "We're not dead" on the other hand is defensive. Even if the
| language has a big community still, it means people are
| leaving.
|
| And the thing is new users seldom go to big but dying
| languages. They'd rather go to small but growing languages
| (which at least are more exciting), but even more probably,
| they'll go to medium to big but growing languages.
| acemarke wrote:
| Heh, I wrote "Redux - Not Dead Yet!" in 2018 [0] to counteract
| FUD from the Twitterati, and updated it again in 2020. If
| nothing else, it's saved me from having to rewrite the exact
| same answer hundreds of times in separate replies.
|
| Happily, threads like this recent "Redux Toolkit is awesome!"
| Reddit thread [1] show that our efforts to keep improving Redux
| and let people know about "Modern Redux" (the combo of Redux
| Toolkit + React-Redux hooks) [2] have been bearing fruit.
|
| [0] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-
| yet...
|
| [1]
| https://www.reddit.com/r/reactjs/comments/px6kxy/redux_toolk...
|
| [2] https://redux.js.org/tutorials/essentials/part-2-app-
| structu...
| hasperdi wrote:
| I had a look at those links. No thanks, not much changed.
| Still too much boilerplate and nightmare to refactor.
| acemarke wrote:
| I'm genuinely curious - what _specific_ things would you
| point to, in our recommended usage patterns, as
| "boilerplate" and "nightmare"?
| newaccount2021 wrote:
| I love perl and simultaneously totally at-peace with it being
| "dead"...but it really isn't. Packages I care about are updated
| regularly. The core release is deployed regularly. There are
| numerous meaningful improvements discussed on p5p.
|
| Fastmail, my email provider, runs on perl. You can get perl
| jobs in 2021.
|
| The community is smaller now but more dedicated - not growing,
| but not dead either.
|
| In any case, none of the moderately popular languages will die
| anytime soon...between the platforms that still run on them,
| and the geezers who have the time in retirement to volunteer,
| tools will survive
| davidw wrote:
| > none of the moderately popular languages will die anytime
| soon
|
| Correct. As long as people are using stuff in production, the
| high costs of switching ensure that some maintenance will
| keep happening. That's why we still have things like COBOL,
| even though I don't think much of anyone is all that
| enthusiastic about it.
| 0xbadcafebee wrote:
| I still use Perl all the time for random tasks. It is exceedingly
| fast and simple to create very powerful programs using stable
| libraries, and all the legacy code still works. It's the most
| handy general purpose scripting language, period. And you can run
| it anywhere.
|
| I don't use it for "portable" things, which is funny because it's
| more portable than any language I can think of. I write things in
| Python if anyone other than me has to support it or run it, and
| Bash if it's just going to be embedded in a system where I don't
| want to make Perl a dependency. But to do something powerful and
| fast just for myself? It's Perl, baby.
| pram wrote:
| The only reason I know Perl is because I'm old enough to have
| started in the 90s when it was the new hotness. Starting today
| I'd obviously have learned JS or Go or Java or Rust or Python
| instead. Perl in 2021 probably seems like some curious antique
| like AWK, if they've even heard of it.
|
| That is the real problem I think. There is just no good reason to
| use it, and thus learn it. It doesn't do anything better than the
| alternatives. It's not "dead" but there is very little new blood
| entering the scene. It's a retirement home.
| bluedino wrote:
| >> The only reason I know Perl is because I'm old enough to
| have started in the 90s when it was the new hotness.
|
| It was _the_ choice to use to write web pages in at one point.
| I remember installing RedHat Linux, writing a support 'forum'
| message board thing in Perl, then chucking it away as everyone
| was starting to use ColdFusion, PHP and .NET
| cyberge99 wrote:
| CGI was the way back then (still is in a way).
| tyingq wrote:
| I imagine the old "Command Line Tools can be 235x faster than
| your Hadoop Cluster" story still applies. That is, there's
| probably a fair amount of data processing that could be done
| well with Perl (or awk, etc).
| oneweekwonder wrote:
| > Perl in 2021 probably seems like some curious antique like
| AWK
|
| Sure you can call awk an antique tool being 44 years old, but
| its available on almost all unix-like systems even on router
| running busybox or bare minimum containers using alphine.
|
| So its definitely a personal nitpick of mine calling a very
| relevant tool an antique.
| mixmastamyk wrote:
| It's mature; i.e. done.
| shagie wrote:
| Somewhere, I've got a book for programming awk. It's got some
| _really_ neat things in there that are non-trivial awk
| scripts from yesteryear.
|
| I could see that being useful in the 70s or 80s... but not
| today. No-one writes awk more than a line or two today that's
| nestled in some ci script that is never looked at again.
|
| Yes, the tool is ubiquitous - its everywhere. It also happens
| to be part of the standard of what is on a machine which
| keeps it being used for those two liners.
|
| However, people aren't writing applications in awk anymore.
|
| Similarly, perl is going to go the same way. It's going to be
| useful for those 10-20 line data transformations that are in
| some data pipeline for munging data. But its not something
| that's continuing to grow and find its way as a first choice.
|
| Writing a new application in awk is something that people do
| for the exercise - much like going and doing your own
| primitive photography with a cyanotype. It's done as a "yes,
| I understand it enough to do this complex thing." Perl is a
| bit further back... it's developing your own film. There are
| still some people who do that as a matter of their business -
| but its not a first choice anymore.
|
| Cyanotypes and doing your own darkroom work are things of
| antiques in today's age. They're not gone - but doing things
| in them is more like going to the pioneer town and seeing how
| it used to be done rather than a practical choice for today.
| mywittyname wrote:
| Applications in awk? No.
|
| It's still a popular tool in the data processing realm.
| It's crazy to think that bash scripts using pipes is still
| one of the most memory efficient ways of processing file-
| based data. Even tools like Apache Airflow just went ahead
| and incorporated bash for this exact reason.
| shagie wrote:
| In the back of this 80s book that I've got somewhere
| there's a set of programs that are 5-7 printed pages
| long... and written entirely in awk.
|
| A short example of that type of thing -
| https://people.sc.fsu.edu/~sshanbhag/awk-
| shell/histogram.awk
|
| For the time, that was likely a very reasonable solution.
| But for today's world, there are better solutions.
| jamal-kumar wrote:
| AWK is sweet for big/streaming data analysis operations
| because by default awk/sed handle data without allocating
| memory. They're still highly used in these use cases just
| because it's typically easier to munge a gargantuan CSV file
| using command line tools that zip fast as fuck through it to
| get to the data. These tools come from days when malloc
| wasn't just an expensive bottleneck computationally, but
| expensive in terms of like 32MB of RAM or way less. If I need
| an application to get to data that huge (And there is PLENTY
| OF IT and more to come in these days, so it's pretty dope and
| groovy that this tool from the 70s is one of my best friends
| still -- care for your elders), I will get all modern or
| whatever and write one in go.
| mywittyname wrote:
| Awk is handy for bash programming. It's one of those weird
| tools in the box that is extremely useful in a very few
| specific scenarios, and that's what is keeping it alive.
|
| No sane person is going to write an entire application in Awk
| anymore. But there are certainly 20 years old there who will
| encounter Awk while doing some command line data munging via
| SO and it will slowly become a tool in their toolbox.
|
| Perl doesn't really have that. Sure you can ` | perl -e
| "..."` but honestly, I can do that with python/PHP too. I
| haven't encountered an SO answer for command line data
| processing hacks that have used perl in ages.
| kevin_thibedeau wrote:
| I wrote an Awk script a few weeks ago precisely because I
| needed to filter some text. Python would be more verbose
| than I needed, Sed would become a write-only mess, but Awk
| in a Bash wrapper was just right.
| mongol wrote:
| There is a book, "Minimal Perl", that is entirely about
| that usecase. I found it convincing, 15 years ago, and the
| only Perl I use are those terse command line snippets it
| teached, when others might use some combination of grep,
| sed and awk. I don't know if it is the best tool for the
| job, but it has worked for me.
| netcraft wrote:
| What I would like to see in posts like this is a description of
| the kinds of programs the author thinks are great candidates for
| this language over others, maybe with an acknowledgement of the
| other options and a comparison of why (in this case) Perl might
| be a better choice. I see a lot of the things listed that they
| think are strengths, but many of them are shared by other
| languages that don't have the negatives (even if a lot of those
| negatives are just perceived) - so why should I choose Perl in
| 2021?
|
| I have professionally written a few languages in my life that the
| zeitgeist would consider "dead" - what I always see in those
| communities is a lot of people crying that they aren't dead like
| something out of monty python - and that its "actually a great
| language", but no real pitch about _how_ that would apply to the
| prospective people who might pick it up. These conversations
| always come across as delusional, fan-boyish, and the opinions of
| people who feel pot committed to the language they've spent so
| much time in and are not willing or able to pivot, begging people
| not to think that they chose poorly.
|
| I truly don't know if this applies to Perl, I certainly have
| opinions long held and maybe things have changed over the years,
| but in a world with so many great options today, to make a dent
| you have to paint a picture for people to convince them to give
| it a shot.
| streamofdigits wrote:
| Billion dollar companies have been built on perl[0]. So let us
| not seek to fix the blame for the past, let us accept our own
| responsibility for the future.
|
| Seriously though, how large a collection of programming language
| ecosystems does the world want or need? How many equivalent
| stacks, all solving the same problems with more or less the same
| patterns and concepts?
|
| Just a thought: Open source communities could benefit from less
| dispersion of energy and talent, less endless re-invention of the
| wheel, less endless "not-invented here syndrome"...
|
| [0] https://www.slideshare.net/cmnunes/bookingcom-perl
| Hermitian909 wrote:
| The open source ecosystem _is_ concentrated. There are far more
| OSS packages for javascript or C++ than, say, Rust.
|
| Less popular programming languages are talked about much more
| than they are contributed to, but they're talked about
| precisely because they're often solving problems that are major
| pain points in people's lives.
|
| I'm personally rooting for OCaml, assuming some current efforts
| bear fruit I'd love a language with the following properties:
|
| - An extremely expressive type system with type inference
|
| - Incremental builds so compiling is fast
|
| - Good compile to JS story so frontend/backend share types as
| well as serializers and deserializers
|
| - Only slightly slower than C (think Java perf)
|
| - Good multicore, perhaps even with typed effects
|
| - Can be run in a unikernel so I can ship my program as a
| simple image
|
| Any language with this feature list would solve a lot of
| personal and organizational problems for me and many other
| programmers I know. None of the really popular languages I'm
| familiar with _can_ achieve these goals due to backward
| compatibility requirements.
| dreyfan wrote:
| There's far more venture capital than innovative ideas and the
| business problems are rarely hard to solve. Engineers get bored
| so we have a constant flow of new languages, frameworks, and
| lately, an overwhelming focus on tooling and infrastructure.
|
| At the end of the day, most companies are just generating
| dynamic HTML after performing some rudimentary CRUD database
| operations. It's disappointing so much time and money is spent
| only to arrive at the same place that /cgi-bin/ and a perl
| script solved over two decades ago.
| mywittyname wrote:
| >how large a collection of programming language ecosystems does
| the world want or need?
|
| There are many problem domains that can be solved by computers,
| and having a language specific or well suited to that niche can
| be a productivity boon.
|
| As long as humans continue to discover new problem domains in
| computing, they will continue to develop new programming
| languages to work in them more efficiently (and existing
| languages will expand to try and fill that niche).
| streamofdigits wrote:
| yes, I am not arguing for a single language. But many of the
| domains you mention are actually intrinsically similar once
| you map them to the underlying information flows. This
| explains for example the extreme ubiquity and longevity of
| things like relational databases and SQL.
|
| There are several genuine and orthogonal domain "dimensions",
| e.g real time systems or parallel processing etc, but I would
| say that is a handful, not the multiple dozens even hundreds
| of idioms we use to program digital devices...
| xdfgh1112 wrote:
| Weird timing considering the community is actually dying right
| now - lots of talented people have left recently and many of my
| pro-Perl friends have stopped using for good.
| oblib wrote:
| I rewrote all my Perl app code in JS to run entirely on the
| client side years ago but Perl is still my go to server side
| tool. For example, I used to use HTML:Template, now I use
| Mustache.js.
|
| I'm quite sure I could do most anything I do with Perl with
| Python instead but since that would be pretty much the only thing
| I'd use Python for I'd spend more time learning how to do it than
| is necessary.
|
| I still use CGI.pm for a lot of what I do on the server side,
| which is not very much anymore. But for what I do use it for it's
| very good at and I've never had a problem with it.
| cafard wrote:
| I don't often write Perl these days, but I did this week. I was
| amused to find that I was using "def" rather than "sub" to
| declare functions.
| chipuni wrote:
| A good measurement of whether a language is "dead" or not is the
| TIOBE index: https://www.tiobe.com/tiobe-index/
|
| Is Perl dead? No, it's still among the top-20 programming
| languages.
|
| Is Perl dying? Yes; it dropped 8 places among the top-20
| programming languages.
| justinator wrote:
| Oh so Perl is owned by Schrodinger?
| Hjfrf wrote:
| The list is based on search engine hits for "x programming".
|
| That's probably fine for comparing c to c++ or perl. Searches
| for "scripting" or "coding" instead are not counted, which
| probably explains shell scripting below languages 20x less
| popular if you search by the name alone.
|
| Powershell at ~40, bash not even top 50. You'd assume both are
| dead from this list.
| uxp100 wrote:
| What's the replacement for Perl based Verilog metaprogramming in
| the Intel (I think) style?
|
| I'm being a little cheeky, but that is a use-case for perl at a
| few of the places that make the processors that the web-
| frameworks that no longer use perl run on. I no longer work at a
| semiconductor company, maybe they're moving away from that, but
| I'm not sure what would replace the in-line perl in verilog files
| that use perl as a pre-processor.
| coldtea wrote:
| Nope, they're accurate. But I guess hope is eternal.
| MarkusWandel wrote:
| On my Linux system I could, if I wanted to, write programs in
| (the subset of bash that is) Bourne shell, awk, plain old 1970s
| vintage C, implement text filters in sed... all these are antique
| things that don't need a vibrant user community. They just need
| to work well enough to support existing stuff written in them,
| and for an occasional quickie script by old farts who know how to
| use them.
|
| Why should Perl be any different? It'll be decades before a
| practical system won't have a Perl 5 compatible /bin/perl on it.
| So if I know Perl well enough that I can hack something up in 5
| minutes, and Perl is there and works, how is it alive or dead? It
| just is. And that suits me just fine.
| mongol wrote:
| Good point. The alive / dead metaphor is not so useful to
| descibe the language itself. Perhaps it is the community that
| should be described as alive or dead. The language itself is
| just a tool. It never was alive, but as long as it works, it is
| useful for those that choose to use it. Just like a hammer can
| be useful long after the toolsmith that made it died.
| bloak wrote:
| I use Perl all the time for short programs, up to a few hundred
| lines. The main advantages of Perl are that it's already
| installed on all the systems I use and the language itself is not
| changing: Perl scripts I wrote 20 years ago still work, and I
| have a vague hope that Perl scripts I write today will still work
| in 20 years' time.
|
| Maybe Python is now stable enough for me to consider it as an
| alternative to Perl but I've bad experiences trying to run Python
| scripts from 20 years ago. In any case, Python is less concise
| for the sort of programs I write, and although Perl has a
| reputation for being unreadable it really depends on who's
| writing it. I write in a subset of Perl, with "use strict", that
| I find to be readable. I find Perl stops being convenient at
| about the point where you need complex data structures and
| modules.
| htrp wrote:
| I think the business life cycle is also a useful analogy for
| languages
|
| at some point no new software should be developed in a given
| language and you should just be maintaining existing code bases
| corresponding to managed .decline
| moedersmooiste wrote:
| Booking.com is the only big website I know that still uses
| Perl...
| vajrabum wrote:
| Craigslist.com also still uses perl.
| jzawodn wrote:
| s/\\.com/.org/
| G3rn0ti wrote:
| Eventually every technology will age and die after some time.
| Today, you may be proud of your intimate knowledge of Python,
| Golang, C++ or even JavaScript. But in 20 years from now people
| will have gone on and you might be left behind. So to all young
| and smug whippersnappers here: Memento mori!
| justinator wrote:
| What you need to find is a willing host to totally monopolize.
| JavaScript just isn't going away from the browser in my
| lifetime and JavaScript started out as a completely hobbled
| language that still has major warts.
|
| Perl doesn't have that. Reads in strings, do stuff, outputs
| strings? Welcome to Unix!
| Thaxll wrote:
| Perl is pretty much dead, actually I've never seen or touch or
| heard new project being built in Perl for the last 10 years.
|
| Python took over.
| stevekemp wrote:
| Perl is used in the background for lots of glue, and
| integrations.
|
| But I don't think it was python that took over from Perl. When
| I think of the kinda web-applications I was writing they got
| replaced by Rails, PHP, and similar.
| rektide wrote:
| I would love to see more innovation in scripting languages.
| Nothing (I've seen) comes as close to perl for swizzling together
| a decent, capable, handy programming language with a variety of
| system binaries & other shell scripts.
|
| There's a couple efforts like shell.js[1] or the far
| simpler/more-contemporary zx[2] to give shell-scripting like ease
| to js. zx's core is just at tagged template string for running
| system() calls, basically, ex: $`echo 2+2`. I still find the
| experience pretty sub-par compared to how shell & scripting first
| languages like Perl are.
|
| Perl is just super powerful, keeping a foot in a more user-land
| like environment, versus the totalizing experience of libraries.
| Why do you need to pick a http client library to use when
| everyone is already quite intimate with curl & it's already on
| the system? Somehow coding keeps taking more turf, but I feel
| like Perl's scripting was extremely glorious & largely un-
| reproduced. Perl is still some of the best "glue" the planet has
| seen. And glue, as we've read a couple times on HN[3][4], & which
| I agree with, is really important, dominates what we build.
|
| To the topic itself, as a Debian user, I appreciate Perl, but I
| wish it weren't on my OS taking up ~20MB of space & being more &
| more offbeat, but it's probably never going away. Not sure why it
| irks me that my computers will all need that ~20MB of Perl +
| Debian perl libraries. And it is pretty cool how debuggable &
| visible the Debian tools often are, because they're scripts, not
| compiled programs, by & large. But there's a lot of operators to
| lookup & a lot of implicit variables to remember in Perl
| programs, and it's a reminder how offbeat Perl is, every time I
| poke my head in.
|
| [1] https://github.com/shelljs/shelljs
|
| [2] https://github.com/google/zx
|
| [3] https://news.ycombinator.com/item?id=27486706
| https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft...
|
| [4] https://news.ycombinator.com/item?id=27880183
| https://www.oreilly.com/radar/thinking-about-glue/
| giantrobot wrote:
| Perl isn't _dead_ but its usage is not growing and I don 't see
| any reason it will ever grow again. Unless you're an old school
| Perl hacker there's little reason to start a green field project
| with it today.
|
| I say that as someone that has written a lot of Perl over the
| years. It turned out to be an awesome language for CGI apps in
| the early days of the web (the reason I learned it). It was also
| a better system administration/automation language than some
| bash/awk/sed/grep amalgamation.
|
| For me at least it fell down once you got over a few hundred
| lines. The TMTOWTDOI led to your own (or at least my) code being
| internally inconsistent and the lure of its shorthand meant
| coming back to old code took some effort to understand.
|
| I moved from Perl to Python and it helped immensely with both
| those problems. Once I grokked Python's regex I could do
| everything in Python I used to do in Perl with the same speed but
| half the effort.
|
| I don't see any attraction of going _back_ to Perl. It was a nice
| tool for a time but now there 's better tools (IMO). So once old
| deployments of Perl apps/tools are replaced I really don't think
| they're going to be replaced with Perl.
| CodeWriter23 wrote:
| I've coded in Perl since the late 90's up until about 3 years
| ago. Thought Dancer and Dancer2 were awesome web frameworks.
| Especially loved making my own app-specific DSL.
|
| Then I took a consulting gig and the framework server side was
| Laravel. I switched and never looked back. I'm even porting one
| of my Dancer2 backends to Laravel.
|
| My main reasons:
|
| 1. Laravel has so much momentum, the tooling is so superior to
| Dancer2 that the Dancer2 crew will never catch up. The schema
| migration management alone is a killer app that will drive
| switching. And tons more.
|
| 2. In patio11's post about selling Bingo Card Creator, he
| indicated implementation language is a key consideration for a
| buyer. They want to be able to draw from a larger and possibly
| less expensive talent pool for maintaining and extending the
| software. PHP wins on both of those metrics.
|
| 3. I've reached the point in my life where I want to do stuff
| WITH as opposed to do stuff TO my applications. Size and cost of
| the Talent pool is relevant in this way to me for the simple
| reason I know there aren't enough hours in the day to do it solo.
|
| I always wanted Perl to make it back into the mainstream. It will
| never die. But to me at this point, Perl is as impractical as
| some of my crazy ex-girlfriends. I bid it the same affectionate
| farewell.
| debacle wrote:
| I still love Perl. If I had the opportunity to work on an
| existing Perl project, I would relish the nostalgia.
|
| I would never, ever use Perl for a greenfield project unless
| there was a library that was absolutely crucial to the
| development, for many reasons.
|
| Perl 6 was so disastrous to the ecosystem that it effectively
| killed the language. If 20% of the effort that went into Perl 6
| had gone into keeping the language fresh, I think Perl would
| still be part of the conversation today.
| 1024core wrote:
| I believe Numpy/Scipy really put some wind behind Python's sails.
|
| Are there equivalents for Perl?
|
| Perl was my first love, but I rarely reach for it now, since I
| spend most of my time data munging and doing Tensorflow.
| cjm42 wrote:
| I believe https://metacpan.org/pod/PDL would be the closest
| Perl equivalent, but it's not my field and I haven't used it.
| edgyquant wrote:
| Numpy/Scipi/Pandas/tensorflow etc all did for
| scientific/analytics but web frameworks also helped. Today what
| makes python so easy to use is the fact that there is multiple
| modules for everything.
| mywittyname wrote:
| Yet, deployment/versioning of python remains a shit show.
| Just the other day, I ran into an issue with the setproctitle
| package where certain implementations exposed a method via
| CPython while others didn't. So not only did it matter which
| version of python you used, but it mattered how it was
| compiled. The kicker is, the official OSX build from
| python.org doesn't work, you have to use a version that comes
| with OSX.
|
| Only Python would have such a ridiculous problem in 2021.
|
| I love Python, but it's best left in the data science space.
| Maybe the odd micro-service in Flask.
| [deleted]
| forgotpwd16 wrote:
| PDL (http://pdl.perl.org). And it's pretty old too, having
| started in late 90s.
| mmaunder wrote:
| While the authors accusation audit is impressive, I can assure
| you, as a CPAN contributor and someone who has launched some very
| successful Perl web apps, that Perl is in fact, completely and
| utterly dead. It died well over a decade ago when all focus moved
| to Perl 6 which didn't emerge until recently. Everyone moved on
| except a hardcore group of advocates. They aren't coming back. If
| a new language and community emerges that happens to have the
| same name, I'll certainly take a look. That hasn't happened yet.
| And it's a damn shame because the mod_perl list and community had
| some killer talent in it that was creating the most innovative
| and heigh performance web applications out there. I created
| WorkZoo in Perl which was a very high performance job meta search
| engine and was one of Time Magazines top 50 sites in 2005.
|
| What happened to Perl is a damn shame. Many of us went over to
| PHP which is vibrant, keeps getting faster and better and is as
| practical as Perl was and hasn't stalled.
| forgotpwd16 wrote:
| >Many of us went over to PHP which is vibrant, keeps getting
| faster and better and is as practical as Perl was and hasn't
| stalled.
|
| Funny as, quite similar to Perl, it took about a decade for a
| new major version (v. 7) and in the meantime there was a failed
| experiment (v. 6). And, quite similar to Perl, people were
| saying PHP is a dying language only alive thanks to some old
| major projects (WordPress, ...) that are written in it.
| Moreover, exactly like this very blog post, there were articles
| written saying that PHP is not dead.
| xav0989 wrote:
| You also had facebook pumping resources into PHP with HPHPc,
| HHVM, trying to compile a spec, etc.
|
| That definitely would have helped keep PHP alive through the
| period between PHP 5 and PHP 7.
|
| Additionally, PHP's releases of 5.3, 5.4, and 5.5 introduced
| enough new functionality that the bump was more than
| incremental. It had backwards-breaking changes, which should
| have warranted a new major release if PHP followed semver.
| tkinom wrote:
| Old Programming Languages never die, they just fade away.
| handrous wrote:
| What's missing from Perl 5, would you say, that's holding it
| back? Performance? Language features? The "line noise" stigma?
| (yet, Haskell is trendy and it's _at least_ as "line noise"
| looking to me, in typical use, as typical Perl is...) Package
| management and other tools?
| Sohcahtoa82 wrote:
| > The "line noise" stigma?
|
| This is what kills it for me more than anything else.
|
| Perl's syntax is incredibly unintuitive. People joke about it
| being the only "write-only" language because you can write
| some code and 6 months later come back to it and have no idea
| how any of it works.
|
| Code is read far more often than it is written, so
| readability is important, and Perl lacks it.
| munificent wrote:
| This is a bit like asking what's wrong with your ranch by
| describing the grass. The problem is there's no cows on it.
|
| You might argue that sufficiently appealing grass might
| persuade cows on other ranches to jump the fence and come
| over, but the reality is that the grass on those other
| ranches is _very_ nice at this point and getting greener
| faster than the grass on Perl Ranch.
|
| The users are gone and aren't coming back. Without those, you
| don't have a language.
| steveklabnik wrote:
| I have a tattoo of a Perl camel, and of a Ruby ruby. I
| loved Perl, but to me anyway, Ruby was 95% of the good
| stuff of Perl, with 5% of the downsides. Some of that last
| 5% of good stuff was things that you could even argue isn't
| actually good stuff, but I like it anyway. ($_ is my go-to
| example for this.)
|
| "Why not {Ruby,Python,PHP,JavaScript}?" is imho the
| question that Perl has to answer, and hasn't found one that
| enough folks find compelling, it seems.
|
| This thread is making me so nostalgic... it's hard to
| overstate how influential Perl was on me.
| mmaunder wrote:
| Release cadence. Trendy isn't a factor for a productive dev.
| handrous wrote:
| > Trendy isn't a factor for a productive dev.
|
| It _can_ matter, since companies want to see experience
| with what they 're using, when they hire, so developers
| don't want to get stuck in something that's declining. Hype
| and _perceived_ popularity-trajectory definitely matter for
| keeping a language alive, and for hiring (devs will tend
| not to want to take your job if they 'll be working with
| things they consider to be legacy and trending downward).
| cuddlybacon wrote:
| I think Perl 6 killed Perl 5.
|
| Perl spent almost 20 years with a new version looming over
| its head. It was known from the start that Perl 6 would be
| incompatible. This meant it always seemed to be a bad time to
| get into Perl. You were committing to having to do a partial
| re-write whenever Perl 6 happened to come.
|
| As more time passed and the differences between 5 and 6
| became bigger, companies that had been holding out for Perl 6
| started to ask "If I'm going to have to do a re-write, why
| not re-write in something else?". Which is what we ended up
| doing.
|
| I think there are various other warts in Perl compared to
| other languages in its niche, but I don't think they killed
| the language.
| dkarl wrote:
| I think you are absolutely right. The warts only
| exacerbated the process you describe, because when
| potential new users checked out Perl and saw the warts, it
| seemed a lot easier to wait for the new version that was
| supposed to address many of them. So new users as well as
| existing users put off investing in Perl until the next
| version. In the early 2000s, it didn't make sense to learn
| Perl 5 unless you had an pressing need, because Perl 6
| would be out soon and would have a much easier learning
| curve.
|
| Perl 6 has to be one of the most destructive failures ever
| committed by the stewards of a popular programming
| language.
| selestify wrote:
| Why didn't Python 3 kill off Python in the same way?
| jeramey wrote:
| It feels like it almost did. There was a pretty
| frustrating couple of years there where it wasn't clear
| if 2.x or 3.x was going to be the winning version and the
| Python community seemed to have a lot of disagreement on
| that subject. My team invested heavily in alternatives
| like Node.js at the time to hedge against Python dying.
|
| However, Python 3 did at least eventually have a
| reasonable backwards compatibility story which Perl 6
| never really seemed to have. It's a bit harder to do now
| since Python 3 has marched on while Python 2 is formally
| unsupported now, but for a while in the 2.7/3.3 days, it
| was relatively straightforward--if a bit icky at times--
| to have a single code base that would support either
| version of Python, and many library and app developers
| took advantage of that to allow as-seamless-as-possible
| transitions, rather than the whole community having to
| immediately spend a ton of effort porting their entire
| code bases to an incompatible language. Mechanical code
| rewriting tools which were introduced during that period
| like 2to3 also helped ease the transition for many use
| cases and code bases, too.
|
| The downside of all that is related: Since source
| compatibility was possible, the package distribution
| method remained the same, and at the same time for all
| the usual reasons, some useful packages never got updated
| with Python 3 compatibility changes. Today, there are
| still libraries in PyPI which can be pip installed with
| Python 3, but you can't actually use them because they
| never got the attention needed to be compatible with it.
| If the package is a pure Python code base, you might not
| even find out until you try to import the library or call
| a function, class, or method. Then you get to spend time
| in your favorite search engine trying to hunt down an
| alternative. Very annoying.
| benbristow wrote:
| A reasonable syntax, try/catch/finally built in, subroutine
| signatures as a default feature (not 'experimental') and a
| sane class system would be a start.
| chris1993 wrote:
| I think that describes Perl v7 pretty well.
| natch wrote:
| Too many ways to do things. TIMTOWTDI.
|
| If you went looking for the best practices, you would find a
| few things but mostly you would find garden path tutorials
| leading you through many suboptimal ways of doing things and
| then finally recommending a final, also suboptimal, way.
| There was a book on Perl best practices that was full of
| recommendations on how to do things, and after not too long
| many of the techniques were deprecated. In other words the
| book was wrong yet it was the go-to book when it came out.
| Sure it's normal for tech books to get outdated but this
| seemed to be a different level.
|
| Then you hop over to the Python docs and see this phrase,
| paraphrasing here, "there should (generally) be one preferred
| way to do it."
___________________________________________________________________
(page generated 2021-10-20 23:01 UTC)