The Perl Foundation will now be known as The Perl and Raku Foundation

https://news.perlfoundation.org/post/announcements

by Amorymeltzer • 4 years ago

89 129 4 years ago

news.perlfoundation.org

Kelteseth• 4 years ago

Honest question: Is anybody using perl for new projects? We have a medium (~100k) codebase written in perl and are actively working to convert it to python.

rrwo9• 4 years ago

Yes.

At my $work, most of our code is in Perl, roughly a half-million lines of it dating back to the mid-1990s.

There's no point in rewriting it in something else, since the cost in resources to do that would outweigh the potential salary savings by hiring cheaper programmers who know Python or C# or whatever. (My experience with some other companies is that they want to move away from Perl because Perl programmers are more expensive, not because it's a worse language.)

Likewise, there's no point in starting new projects in another language since we'd then have to hire people people competent in both of those languages.

My experience is that people who turn their nose up at "old" tech like Perl are not worth hiring. If they don't care to learn about the technology you are using, then they won't care to learn about your industry or your company's business logic.

chrisseaton11• 4 years ago

Aren't you missing advances in programming language technology (performance, tooling, instrumentation) by sticking with such an old interpreter?

vultour2• 4 years ago

I worked at a place like this and it was a nightmare. We had a few dedicated Perl programmers who swore there was nothing better since sliced bread, but there were so many legacy Perl programs it spilled into everyone's responsibilities. I know for a fact everybody else absolutely hated having to go in and decipher decades old Perl code.

josephcsible• 4 years ago

people who turn their nose up at "old" tech like Perl

The problem with Perl isn't that it's old. It's bad in ways that other old languages aren't. Consider all the people who like C but not Perl, even though C is older.

jstanley4• 4 years ago

I have been using Perl (5) for new projects until very recently (and, realistically, I might still use it in the future). I also did some contracting until very recently for a company whose product makes extensive use of Perl. I've been writing Perl professionally for over 10 years.

The backend of my network programming challenge[0] is all Perl daemons, including the web API, the solution checker, leaderboard calculation, and new problem announcement mailing. (The frontend is Next.js, but it's not using any server-side JavaScript, it's delivered as a static site).

Perl is good because it is very quick to write. Common idioms are very terse, first-class support for regexes is a superpower, and the TIMTOWTDI philosophy ("there is more than one way to do it" - polar opposite to Python) means you can often find a quick and succinct way to make most small code changes you want to make.

I am personally looking to move away from Perl for new projects for the following reasons:

1. Perl doesn't have sensible support for multi-threading.

There's "use threads", which is quite heavyweight because (as I understand it) every time you make a new thread with "use threads" it creates a memcpy() of the entire interpreter.

There's "use forks", which is the same as "use threads" except it uses fork() so that the "copy" is less expensive (because Linux gives us copy-on-write). "use forks" is still bad because inter-thread communication still involves serialising your data and passing it over a pipe, and you don't necessarily notice where you're doing it.

Then there's Coro[1], which is actually very very good, for what it is. Coro allows you to write code in a straight-line synchronous style, but allows you to cede control to other threads when you need to wait for a result to become available. Coro calls itself "the only read threads in Perl", but it's still not real threads in Perl because it still doesn't let you take advantage of more than 1 CPU. In my experience Coro also interacts poorly with XS (i.e. native code) modules that aren't reentrant, and it's difficult to predict when you might be using such a module, and sometimes your Perl scripts will segfault or leak memory through no obvious fault of your own. But Coro is a really neat hack.

If you actually want to make use of multiple CPUs, the best option (IMO) is to fork() manually and keep inter-process communication to a minimum.

2. Further than multi-threading, Perl doesn't even have sensible support for async/await style concurrency.

The closest thing to async/await style concurrency is AnyEvent[2]. AnyEvent is quite good, and I think is the best way to write asynchronous code in Perl. But it still doesn't hold a candle to basically any modern programming language, because you still have the "callback hell" style of passing closures as an argument to anything that has to be asynchronous. This is extremely annoying and results in enormous, complicated, and error-prone refactors if you ever have to change a component deep in your stack from synchronous to asynchronous. For example, if you are moving away from a hash table "database" to an actual RDBMS, and you don't want your database queries blocking your entire application, this is extremely painful, because everything that lives higher up the stack needs to be rewritten in "callback hell" style. See "What color is your function?" for more on this.[3]

3. Lots of things that should be caught statically don't actually cause problems until runtime.

This is mainly because Perl is dynamically typed and isn't compiled, but it is annoying, and avoidable in other languages.

What language am I moving to? I don't know yet. Probably Go. I don't like how opinionated Go is about a lot of things that Perl doesn't give a shit about, but it is at least quite small.

I don't like Rust because it seems overly bloated (the recommended way to parse command-line arguments - "clap" - involves downloading 140 megabytes of dependencies off crates.io, which just seems unreasonable), although the borrow checker is a very interesting idea.

I'm also interested in Zig, but I think the Zig community is possibly too small at the moment, and not being fully memory-safe seems overly risky. But I haven't written enough Zig yet to know whether or not I like it.

[0] https://protohackers.com/

[1] https://metacpan.org/pod/Coro

[2] https://metacpan.org/pod/AnyEvent

[3] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

return_to_monke• 4 years ago

I don't like Rust because it seems overly bloated (the recommended way to parse command-line arguments - "clap" - involves downloading 400 megabytes of dependencies off crates.io, which just seems unreasonable), although the borrow checker is a very interesting idea.

Where do you get that from? https://lib.rs/crates/clap states that the code itself is 1MB, and the maximal amount of dependency code is 7mb, with all optional features enabled.

sekia• 4 years ago

2. Further than multi-threading, Perl doesn't even have sensible support for async/await style concurrency.

I've never thought so. With Coro's rouse_cb/rouse_wait, you can use almost every callback-style methods in async/await manner.

rrwo9• 4 years ago

A better question is: is anyone planning on moving from Perl to Raku, or from Perl to another language?

At $work, we're sticking with Perl [reasons elsewhere in this thread]. But if we were going start projects in other languages, it would probably be Python or Node.

For personal projects, I'm more interested in Rust than Raku.

b112• 4 years ago

Python is fairly stable, node is prone to fast change.

That is, if python isn't using external dependencies.

If you are writing an app for decades long usage, node is probably a bad choice.

Perl, python, will be around... well, I dunno, decades more at least.

But perl? As someone else said, the code you write now, will work 30 years from now. That's its thing, its happy smile.

Imagine, just imagine writing code that doesn't vanish 2 months after you leave a place. Imagine code your great grandkids might tough.

mfontani5• 4 years ago

I'm working at an all-Perl place, and I'm about to move to another all-Perl place.

Neither has any plans to move off it. The opposite, actually.

Like them, there's likely dozens of others. Dozens, I say!

thatwasunusual2• 4 years ago

Where in the world is this? I would actually fancy working with Perl, but here in Norway there's nothing to find. :(

forgotmypw172• 4 years ago

I started a new project in Perl, which I've commented on before a couple of times in response to a similar question.

One of the main reasons I chose Perl is it's commitment to not introducing breaking changes.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://news.ycombinator.com/item?id=31261071

shubhamjain3• 4 years ago

You're doing God's work. Last I used Perl was ten years ago. I decided to give it another shot for small scripting needs. The ability to write one-liners to do stuff is exciting at first, but my brain isn't used to a language with such a complex grammar. Just the number of ways you can write loops is crazy. Oh btw, is there any other language for which writing BNF isn't impossible? [1]

It doesn't help that most of the times, Perl fails with a very confusing error message that can leave you scratching your head. And it seems all the Perl wisdom has gradually vanished with very few answers to your questions. It wasn't a bad language for its time, but with the number of alternatives, I just don't see a valid reason to use it.

[1] https://stackoverflow.com/questions/4625408/where-can-i-find...

rurban• 4 years ago

I'm using perl as glue tool for a lot of my projects. I could write it in python, but then it would turn into a big hairy monster, and I rather want to keep my tools as tools.

tasty_freeze• 4 years ago

I have a side project at work that I'm doing on evenings/weekends that I've written in perl. One part of it parses verilog source code and builds an AST. It is a recursive descent parser that was written in the most straight-forward way and no time has been spent optimizing it for speed. The AST builder and some auxiliary routines that make interfacing to the AST simpler to manipulate is less than 2500 lines of code and took a couple weekends to write and get working.

Surprisingly, I timed the parser part and it took only 0.06 seconds to process a 2500 line file. Yes, perl is 30x slower than C, but computers are so fast that performance (for my needs) doesn't matter too much.

To be fair, it is only the subset of verilog that one would typically synthesize (so no events and forks/joins, no timing annotation, etc). Doing the whole language would make the code larger but not much slower.

antiquark• 4 years ago

Sad how perl self-destructed with perl6.

chrisseaton11• 4 years ago

I think it was the victim of changing tastes and fashions more than anything else. People used to appreciate that kind of wackiness and linguistic whimsy. I think these days people want more straightforward and simple tools

rrwo9• 4 years ago

Also, there are many more new languages and newer development framework that have appeared in the last 20+ years.

KingOfCoders• 4 years ago

I never liked Perl and had to kill two large Perl projects in the 90s because no one could manage them anymore.

I do think before Python there was no real alternative. We tried C for web development but it was a huge pain. The Python CGI module changed everything for us (Reading about it in the German iX magazine)

ivix• 4 years ago

These days when perl enthusiasts say things like 'its terse' and 'there's more than one way to do it' and 'you can find a quick and short way to do interesting things' the reaction is more of faint nausea than anything else. Probably not what they were going for.

dale_glass4• 4 years ago

It wasn't so much that as bad project management.

In 2000-ish, they announced Perl 6 with great fanfare. People started working on something called "Parrot" which was supposed to be awesome in every way. Quickly it came out that Larry Wall was going to do a serious redesign of the language. It wouldn't just be Perl 5 on a VM, but have a significantly different syntax.

A lot of people then became very reticent to start new big projects. Because Perl 5 was evidently about to be dead, and Perl 6 was some new incompatible thing, so why spend all this effort on writing code now that'll probably need rewriting later? Python suddenly became more interesting.

It turned out that project management was lacking. Perl 6 attracted lots of theorists and fans of experimentation and few people interested in getting out something usable in a timely manner. Multiple VMs and varieties came and went. It took until 2015 until something was released. By then, Perl was already moribund.

It quickly became even more clear than Perl 6 and Perl 5 were different things entirely. Perl 6 didn't share the architecture of the Perl 5 interpreter, so XS wasn't a thing, and XS was a huge part of many prominent modules which meant that a lot of the Perl 5 CPAN modules would be a lot of work to port. The fact that Perl 6 was presenting itself as the successor while Perl 5 still existed and was being worked on didn't help.

In the end Perl 6 was renamed to Raku to make this more explicit -- it's not Perl 5's direct successor, but a new language built from a similar philosophy but otherwise an entirely new creation. But I think by then it was already too late, it'd have been better to do the renaming way before 2015.

The 15 year long development cycle also didn't help -- it created all sorts of confusion and uncertainty about the future. Meanwhile, the upcoming Perl 6 project just wasn't suitable for almost anything other than working on the interpreter itself, and that excluded a lot of Perl programmers who were used to writing in Perl, and not working with the actual guts of the interpreter.

CJefferson2• 4 years ago

I definately think it was Perl 6, it's a small sample, but around 2002 me and some friends needed to learn a scripting language -- the obvious choices were Perl 5, Ruby or Python (2 at that point). If you searched for Perl, you just found things that said "Perl 6, ground up rewrite, coming soon!". I honestly assumed I'd pick up Perl 6 when it came out, and started with Python in the mean time.

debacle• 4 years ago

Agreed. Not only did perl6 completely fail to deliver (far too much deviation from perl's heart), but it took the air out of the sails of perl5 development for years.

geerlingguy2• 4 years ago

Honest question: what is Raku?

mfontani5• 4 years ago

The Language Formerly Known As Perl6 - see https://raku.org/

geerlingguy2• 4 years ago

Thanks! Interesting that in all the time I've done web and infra dev work (mostly Python, PHP, and Go, sometimes Ruby), I've never heard of Raku, nor knew what happened to Perl after the Perl 5-to-7 thing (also similar with PHP 5-7... though no PHP 6 ever got resurrected).

StayTrue• 4 years ago

I miss Perl. I managed a startup that built in Perl and C++ simultaneously. The Perl MVP allowed us to get into customer premises right away and we fed that learning back into the C++ version (on which our acquisition was based). In retrospect we would not have succeeded without Perl.

I used it recently to generate reports from analytics and it felt good. If there are remote jobs calling for Perl, send them my way.

mfontani5• 4 years ago

Look at https://perl.careers and/or search for Perl on LinkedIn, or look at https://jobs.perl.org.

Plenty jobs for Perl developers.

nousermane• 4 years ago

Perl has some weird quirks - dollar-variables vs. percent-variables vs. at-variables (and sometimes you can "cast" one into other), round-brackets where most others have squiggly (and vice-versa)...

But once you get over that, it's a great language. First-class regex, -pine options. A lot to love about it.

bitexploder• 4 years ago

Many a Unix environment and production system were held together by Perl glue in the late 90s/early 00s :)

darrenwestall2• 4 years ago

I’m hiring - email in my profile if you were serious :)

codeflo3• 4 years ago

There’s one common criticism that I don’t get: That Perl 5 is hard to learn. I have a theory about this, but warning, rant incoming.

People used to read programming books. I learned both Perl and C from books; for me Perl wasn’t any harder. Yes, the syntax is unique — but you learned to read weirder things, C++ certainly isn’t any more intuitive in a vacuum.

But of course, few people read books anymore, so where do people learn languages? I guess universities and blog posts. (And increasingly YouTube videos, which have even less content density.)

Universities only teach old versions of Java. Blog posts are limited in size. Sad conclusion: any language that has more than a blog post’s worth of differences to Java 1.x will find it hard to reach very broad adoption.

rrwo9• 4 years ago

I don't think Perl is/was any harder to learn than C. Easier, in fact, since you don't have to worry about making a mistake with pointers.

I've not found colleagues who learned Java or C# first have had trouble learning Perl. When they've learned "modern" Perl with Moose/Moo, they've been happy with it.

7thaccount• 4 years ago

Perl is a scripting language. To me it's very similar to Python and a Lot easier to learn than something low level like C that doesn't have everything built-in and just available for you.

woodrowbarlow• 4 years ago

people conflate "easy to learn" with "familiar" and it's a shame.

a-dub• 4 years ago

i think that's right. perl is ridiculously easy to learn, it just hasn't been as popular in the stack overflow era.

also, i think there's a lot of very old and rotted code out there now that is probably very confusing to try to learn from.

verelo• 4 years ago

Interesting, not sure I agree but i think you're onto something.

I have been frustrated by framework walkthroughs that fail to explain the expected prior knowledge. Recently I've been using Laravel, and something as simple as "You need to include the following 'use' statements" would have saved me tens of minutes several times over by now. They just launch into code, with no context. I fear they know that if they make the content long, no one will read it.

I'm left frustrated by the experience and I suspect long term anyone that cannot be bothered learning half a page of content isnt going to make anything long lasting anyway.

efficax• 4 years ago

and yet rust is very complicated and plenty of people read the rust book to learn it.

my first paid software gig was writing perl and i still use it for text processing quick jobs and such but the truth is it’s just a weird language full of bizarre conventions that is a bad choice for building large systems. better languages replaced it

codeflo3• 4 years ago

You're right, Rust is an interesting counterexample to this trend I'm ranting against in years. I'm a fan of it. Whether it ever reaches adoption beyond the tiny fragment of people who dive deeply into technologies anyway remains to be seen, however. I've noticed that the backlash that it's too complex is already starting to build up.

Roark66• 4 years ago

Indeed, people used to read programming books (I still have two C++ Builder and a "Complete Java Reference" bricks on my bookshelf), but IMO the problem is not that people don't read books, but that a good written reference documentation are very rarely written(or are hard to find) for today's new languages.

It seems all classes of content from video, to blog posts and books suffer from various con-people publishing lots of crap with catchy titles and ordinary people just loose hope browsing through them. In such environment the cost of time spent on a crappy video or blog article is negligible, but if one buys books that are badly written or auto generated one can waste hours and hours before one realises.

So I can't blame today's wannabe programmers for choosing videos and blog articles instead.

toast03• 4 years ago

but IMO the problem is not that people don't read books, but that a good written reference documentation are very rarely written(or are hard to find) for today's new languages.

Ok, but you can get most of Perl5 from 25 year old books at this point. (Wasn't the version number changed to 5 for a book anyway? or was that Perl4?). A little modernization help might be nice, use bytes vs use chars?, less emphasis on mod_perl which doesn't seem widely used anymore, maybe some coverage of Moose, etc. But if you got the basics from a old book, you'd be fine to learn the rest.

On the topic of new languages, I just started somewhere where they use Rust, and read the O'Reilly Rust book and seem to have done ok; lots of style comments on my first diff, and I'm slower than in other languages I already knew, but otherwise seems fine.

I forget what book I read to pick up Erlang; may have been Joe's or the O'Reilly; but that's an older language... It was public for ten years prior to me picking it up, and private for 15ish before then.

CJefferson2• 4 years ago

I think you are in the right direction -- the problem with perl is it's hard to find high-quality internet articles about it. There are many excellent articles about (picking a random example I care about) the borrow checker, or async, in Rust. There might be even better books, but the articles give me something to be inspired by and start investigating.

I think Perl's decline started 15-20 years ago, as that's when Perl 6 was "coming soon", and people didn't bother learning Perl 5 because of that. I can't remember ever seeing an interesting article about programming in Perl, either here or on Twitter.

oalders• 4 years ago

The Perl Advent calendar is back this year. We'll have plenty of high quality posts to read there this December.

sateesh• 4 years ago

Had to disagree that there aren't high quality posts on perl. For example the articles from perl by MJD https://www.plover.com/~mjd/perl/ are top notch. Similarly the articles from Randall Schwartz are quite good. But all these articles were written long ago. Since perl has fallen out of favour these days, probably there are less posts covering Perl and consequently fewer high quality articles that are recent.

midoridensha• 4 years ago

I think Perl's decline started 15-20 years ago, as that's when Perl 6 was "coming soon", and people didn't bother learning Perl 5 because of that.

Reminds me of the Osborne Effect. https://en.wikipedia.org/wiki/Osborne_effect

agumonkey• 4 years ago

I agree with some of these. There's a change in pace and depth about how information is spread and digested.

coldpie• 4 years ago

I feel kind of bad for Perl. I never learned it. I'm no foreigner to "hard" languages. I know Bash, I know Makefiles, I can write a "sed" script with a little effort. Of course I know Python and C and I even put in the effort to learn Rust. But Perl never bubbled up the priority list. We used it a little bit for internal scripts at my previous job, but I rarely had to interact with those, so I never took the time to actually learn it. I'm certain there's a good language in there, but it's so rarely used during my time in the industry (I'm in my mid-30s), that it's just never been worth the effort. I'm sorry, Perl.

kingaillas• 4 years ago

I'm certain there's a good language in there, but it's so rarely used during my time in the industry (I'm in my mid-30s), that it's just never been worth the effort. I'm sorry, Perl.

No apology needed, I'm sure even Perl realizes it was a little stagnant while the rest of the industry zoomed by.

I used Perl in the mid 90's, so I suspect I'm ~20 years older than you. ;) Back then it was a jack-of-all-trades language, good at parsing logs or text files, pinched hit for php if you needed add scripting to websites, etc.

Over time, javascript improved, python gathered mind-share, and perl still worked but wasn't keeping up with new libraries.

I'd like to see Raku do well, although I doubt I'll use it professionally - seeing as how I've got around ~8 years left until I retire.

b2gills• 4 years ago

I don't think Perl is really that hard to learn. It does have a few traps for people new to the language though.

Raku on the other hand is easy to learn. Of course it is so easy to learn that knowing another language, any other language, can make it more difficult to fully grasp. That is because Raku is strangely consistent.

Most languages have a set of syntaxes for different actions. Raku has a set of features, and the syntax mostly just falls out from that.

When someone who knows another language tries to learn Raku they naturally translate what they already know to Raku features. That will only get you a surface level understanding of the language. No other language is really comparable.

Raku also has a new view of regexes. In Raku a regex is just a DSL for matching text. So rather than bolt on feature after feature like other languages have done it allows you to embed regular Raku code for situations where that is easier. You can also combine them using grammars (a type of class) to get a full parser out of several parts.

In fact the grammar feature in Raku is the only one that is powerful enough to parse Raku easily. Part of that has to do with the ability to mutate the language.

It has been said that the best way to solve a programming problem is to create a language in which solving the problem is easy. Raku, using that ability, allows you to do that easily.

em-bee• 4 years ago

learning to use perl is not hard. any language is easy when you only learn and use a subset of it. and perl is very powerful. you don't need to learn all of it in order to write code.

what makes perl hard is to learn all of it and deal with code that uses features that you haven't learned yet.

perl is like english. easy to get started with, but the more you learn the more complex and more difficult it gets

alexpotato• 4 years ago

As someone who used Perl for years in FinTech, I originally learned most of what I used from Robert's Perl Tutorial: http://www.physics.rutgers.edu/~kotliar/perltut.html

You could literally start at the top, work your way down and learn all of the useful functions and data structures.

thatwasunusual2• 4 years ago

"This tutorial is copyright 1997, 1998, 1999 by Robert Pepper."

wtf?

That's like going back to the 1600s and learn astronomy.

IAmNotACellist• 4 years ago

I also grew up learning programming via textbooks--there wasn't really a choice for me, pre-Internet. It had its pros and cons, but what I miss the most is being able to have a single well-written textbook that, when you were finished, you will have gained a solid understanding of the foundation and reasonable approaches on how to use the language.

These days information is so much more readily available for free, but it feels so often I have to resort to reading StackOverflow, shitty YouTube videos, and even shittier OFFICIAL documentation from developers who obviously don't care about technical writing. Machine Learning is especially bad about this.

eduction2• 4 years ago

I read both the Camel book (Programming Perl) and the slimmer one (Learning Perl) but I still found perl 5's split between by-value data structures (@foo/$foo[0], %foo/$foo{"bar"}) and by-reference data structures ($foo->[0], $foo->{"bar"}) really confusing. Ruby and Python managed to avoid needing to differentiate these cases, they would just silently dereference things as needed, and from what I can tell Perl basically had this split for backward compatibility with perl 4 which didn't even support nested data structures. Steve Yegge has a whole section of his Perl rant talking about this (https://sites.google.com/site/steveyegge2/ancient-languages-...). The sigils only make it more confusing because they really don't help you here. $foo is either a reference to @foo or a reference to an element of @foo depending on whether it is immediately followed by an index ("[0]") or if there is a dereference operator ("->") in between. And you only need the dereference operator if you're going to need to get a nested data structure. So like you can't just do $foo[2][4] (as I recall, it's been years) you have to do $foo->[2][4]. If you just need to go one level in you can do either $foo[2] or $foo->[2] depending on your whims. It's kind of madness.

codeflo3• 4 years ago

First, I agree that using Perl today feels like using something from a different era. Having sigils at all feels so antiquated to me now.

But the mechanics of the sigil thing never confused me. Either because it was explained to me very well, or possibly -- Larry Wall is a linguist, after all -- because there's an analogy to grammatical cases, which English largely doesn't have anymore, but my native language does.

The sigil depends on what you want to get out of the expression, not what you put in. So @foo would name the whole array, while $foo[2] would name a single element from it.

If you just need to go one level in you can do either $foo[2] or $foo->[2] depending on your whims. It's kind of madness.

You misremember, but I don't blame you, it's a very unorthodox rule. These are very different expressions.

$foo[2] accesses the second (third depending on how you count) element of @foo. @foo is a "value array", whenever possible, I tended to use those because I found them more convenient and intuitive.

For programmers coming from JavaScript or Python, and people building more complex data structures, using a reference array might be more intuitive. Those are stored in scalar variables, like $foo, but to disambiguate with the syntax for accessing @foo, you have to explicitly dereference it with $foo->[2].

rfreiberger• 4 years ago

I learned a bit of Perl from authors who focused only in Perl, great videos and books that allowed me to understand Perl how it worked differently from Python (at the time was taking over learning media).

But using Perl in the real world was much more difficult. Posting to Perl Mongers about a simple question of some block was often met with equally difficult answers. Many Perl scripts used at my past work places were written by very well versed Perl developers, using every possible shortcut to make the code smaller (and more confusing).

dmckeon• 4 years ago

Code golf is an enemy of clarity, and clear Perl has been a victim of that.

saghm• 4 years ago

I was with you up until the last paragraph. I don't know how typical my experience was, but when I was in college (class of 2016) we also had to write a lot of C, and a smattering of other languages (e.g. one early class in OCaml, AI/ML classes in Python, etc.). I think you may be on to something with the idea that Perl is less known now due to not being taught in college due to other languages being focused, but I think you conclusion that Java is the only thing people will find familiar might be a bit too strong.

melagonster• 4 years ago

my professor said perl is easier to learn, but everyone use python now haha.

shubhamjain3• 4 years ago

I am surprised by the number of people here praising Perl. I understand it was useful for its time, but the reason why programmers aren't using it is because it's a crap of a language. Fine, it's pretty crazy how much you can do in Perl with just few lines of code, but who cares about that except you? It's an active struggle to make Perl code readable and it not turning into a mess.

Perl not only makes it the syntax difficult with all the absurdities (special variables, so many prefixes $,@,%, terse function names, tens of ways to do one thing), it also makes it impossible to Google. Imagine spending your whole afternoon trying to dig what "($fc) = /^(.)/" does; a maintainer's nightmare. I am not that old but from a little searching, it seems to me Perl always had a bad reputation, and for good reasons.

dale_glass4• 4 years ago

Imagine spending your whole afternoon trying to dig what "($fc) = /^(.)/" does

The issue with that is that it's a core part of the language's syntax so how are you going to search for something like that? It's a bit like trying to search what the `Obj foo{3};` means in C++, nothing in the text is a keyword, so it will vary from one program to the next and therefore won't be searchable.

shubhamjain3• 4 years ago

Conventional languages follow a pattern and you can get somewhere because the syntax will seem vaguely familiar if the paradigm is the same. I can guess the code you mentioned is some sort of declaration. Perl deviates too much at times and the numbers of choices is seriously high, which makes the job considerably difficult.

kazinator• 4 years ago

I'm guessing that it's a compound assignment.

/^(.)/ is a regex match with a capture group. Perhaps this produces a list or tuple like ("a") if the buffer starts with "a", and that becomes the value of $fc.

So that is to say, maybe ($x, $y, $z) = /(\d+)-(\d+)-(\d+)/ breaks down a string like 123-334-559 such that $x gets "123", $b gets "334" and $z gets "559".

I did a very small amount of Perl 4 programming in the mid-to-late 1990s.

tadzik_• 4 years ago

Imagine spending your whole afternoon trying to dig what "($fc) = /^(.)/" does; a maintainer's nightmare

Why are you maintaining Perl code without knowing any Perl though? This syntax is obvious to anyone who went through the trouble of following the basic tutorial.

It's a language you need to learn before using it. It's unfamiliar, but not unreadable.

It's an active struggle to make Perl code readable and it not turning into a mess

Are you speaking from experience? I don't find that to be the case.

I don't understand Haskell, but that's because I never bothered to learn it. Should I say it's a crap language just because I do not understand the basic bits right off the bat?

There are good reasons to dislike Perl (I have my own good reasons, having worked with Perl professionally for close to 10 years), but the syntax is really not one of its real problems.

chris1993• 4 years ago

That's an example of poorly written Perl code to grab the first character from $_, and bad code can be written in any language. More conventionally it would be written as "$fc=substr($_,0,1)" which seems reasonably clear and obvious.

photochemsyn2• 4 years ago

As someone who started off with Python / C++ (don't blame me, blame current CS teaching programs), Perl's syntax is a bit off-putting. However, learning simpler Unix tools - i.e. grep, sed and awk - is worth the trouble, as those are very useful tools for command line tasks, and work with pipes.

Also, that's where Perl seem to have got its syntax from, so if you ever do have to dig into Perl code, it won't be as difficult:

http://www.wellho.net/mouth/3902_Shell-Grep-Sed-Awk-Perl-Pyt...

However, using Python's re module for regular expression matching results in far more readable code than any of the predecessors, particularly as expressions get more complex.

kamaal4• 4 years ago

>Perl's syntax is a bit off-putting.

Not sure which parts of Perl syntax you find off putting, but I could guess.

1. Sigils: Why is this bad? Perl has symbols do represent lists(@), associative arrays(%), scalars($). This is actually more readable than Python's approach where there is no symbol to indicate things. The only place where symbol pollution gets out of hand is where you need nested structures. But even there having explicit indication of what's what is better than leaving programmer guessing. Note how this is a program design problem, than a problem with the language itself. To me the only time I deal with this when I'm parsing XMLs and JSONs. Nothing much can be done there because XMLs and JSONs themselves are nested structures.

2. Regular expressions: How else would you represent regular expressions? Do you want Java style

    string.matchAtStart('x')
          .matchAtEnd('.')
          .dontMatchImmediatelyStart(...)
          .noAlphaNumericChars(...)
          .exceptChars(...)
          ...
          ...

See how verbose this gets and very hard to read, it's really the equivalent attempting to do math in words than symbols.

3. References: There are places where you are better of passing a reference to some data, than passing the data itself, for obvious performance and efficiency reasons.

4. Quote words, expressions: Very useful for rapid scripting, and adding data without having it to massage it to a program's syntax.

5. Text utilities: Like chomp, tr, grep. Make it very easy for Unixy work. Why are these even issues?

Perl also contains your regular list manipulation utilities, and OO features. Overall very useful. Not sure where this 'hard to read syntax' thing comes from.

>However, learning simpler Unix tools - i.e. grep, sed and awk - is worth the trouble, as those are very useful tools for command line tasks, and work with pipes.

There are lots of limitation with those tools, you can't do work with several files. You don't get error handling. You are stuck with a paradigm of working on line/block at a time. You can't do other stuff like make Rest API calls. You can't do XML/JSON stuff, the list goes endless because they are not by definition regular programming languages. In fact Perl exists to address these limitations.

>However, using Python's re module for regular expression matching results in far more readable code than any of the predecessors, particularly as expressions get more complex.

No Python got famous, because its users never worked with messy early internet work. Like having to deal with multiple data formats, log files, API responses, database work with no standard data exchange formats. Perl lost a lot of its utility when JSON and XMLs became ubiquitous.

And yeah Python was never big in Unix world either. Its main use was for developing web apps(Django, Twisted Matrix etc).

For that even today Python is bad at anything which has non trivial data work.

darrenf3• 4 years ago

I'm a Perl coder of almost 30 years standing and I find the defence of its readability a bit of a stretch, tbh. Even though I don't personally struggle with it, I've worked with enough very good software engineers who have been able to eloquently describe the problems they have grasping the sigils that I can't discard their opinions, and in good conscience support the argument it's objectively more readable. It might suit the way some people's brains work - mine included! - but that doesn't extend to everyone. And that's OK. I don't feel compelled to defend it. I'm happy doing Perl, they're happy doing their stuff. Whatever :)

photochemsyn2• 4 years ago

Just in terms of readability, not functionality, sometimes "attempting to do math in words than symbols" is not such a bad idea. Also, explicit comments within regular expressions are nice (I notice Perl has this capability too, but perhaps not used as much as it could be)? Such as:

a = re.compile(r"""\d + # the integral part

                   \.    # the decimal point

                   \d \*  # some fractional digits""", re.VERBOSE)

Also, the Python re basic functions - match, search, fullmatch, finditer - return match objects which are not so bad to process, and the other functions - findall, split, sub, subn - are well-documented and easy to interpret. The pattern being used is also clearly separate from the functions that use it, making it easier to understand.

In contrast, Perl regex tutorials are a bit more complex... such as:

https://perldoc.perl.org/perlre

Basically, it seems you can get the same functionality with Python but with a less steep learning curve, and it's easier to read and maintain than Perl.

cesarb3• 4 years ago

Perl has symbols do represent lists(@), associative arrays(%), scalars($).

It's been a long time since I last programmed in Perl, but as I recall the confusing part was that for instance a list might use @ or $ depending on what you're doing with it, and the same for associative arrays, which might use % or $ depending on what you're doing with it; the same variable might use different sigils in different parts of your code, instead of staying with the same sigil for its whole lifetime.

jcranmer2• 4 years ago

1. Sigils: Why is this bad?

You know how people in languages without grammatical gender (like English) complain about grammatical gender when they encounter them in other languages (like most other Indo-European languages)? It's the same basic thing: if you come from an environment where it's not present, it seems unnecessarily fussy to have to specify it all the time.

2. Regular expressions: How else would you represent regular expressions?

Actually, my big problem with Perl is its use of regexes. It's not that the regex syntax is bad (and Perl actually tends to let you make regexes more readable than other languages). It's that Perl code tends to be written so that basic string operations are all replaced with regexes, so figuring out what you're actually doing becomes somewhat annoying. "if !key.startswith("TARGET")" is much easier to read than "if $key !~ m/^TARGET/"

For that even today Python is bad at anything which has non trivial data work.

Honestly, I've found that Python does a better job than any other language I've used at doing the basic drudgery of getting data from one format to another--I've even used it to get JSON-like dumping of binary formats!

apple4ever2• 4 years ago

See how verbose this gets and very hard to read

No I think its easier to read. But I prefer verbosity over cleverness.

flomo• 4 years ago

However, learning simpler Unix tools - i.e. grep, sed and awk - is worth the trouble

The deeper issue is .. maybe not. I never have any interesting data lying around in text files, it's all in SQL databases or behind JSON APIs or maybe in XML or even Excel files. So if one doesn't need sed/awk/grep/etc, then they are never going to reach for perl.

fipar• 4 years ago

Perl has a fond place in my heart, though I don't use it for new things, but I still like it (some 20+ years ago I proudly wore a t-shirt with a square block of perl code in the back that, should you type it and run it, would print a quote by Larry Wall. This shirt: https://www.flickr.com/photos/codepo8/489597488 - not my pic).

That said, having had to deal with perl professionally a few times in the last 10 years, the biggest drawbacks I find in it for larger-scale projects are:

- A lot of people are perl programmers, not programmers. I'm not tied to any language, believe in using the best tool for a job, and believe in using a language I'm not a big fan of if that makes it easier for a wider team. A lot of perl programmers I met don't feel the same and (wrongly, IMHO) think perl is the best language for every use case out there.

- It's lacking in instrumentation when compared to other languages and VMs. It's more challenging to debug production problems with perl than with, say, C (and that should say a lot...)

- There's no reliable way to limit resource usage of programs, which can be very bad when running on servers. Even worse if your perl code shares the server with other code. I think that's one of the reasons new Percona Toolkit tools are written in Go and not perl (but I could be wrong). It can be dangerous to run some perl scripts on a database server, for example. I suppose cgroups/containers/etc can help there, but only in a circuit-breaker way: I don't think there's an easy way for one to write perl code that can keep its resource usage under a predefined limit and still continue to work when the limit is reached.

- Kind of like lisp, a lot of the power in perl also means that if a team is not tight and some coding standards are agreed upon, you end up with multiple custom languages sharing a codebase. Something like python takes care of this because there's usually a single way to do something. That also makes it more boring from a programming language perspective (to some people, to any extent) but as engineers our role is not to do cool, fun, and interesting things; we need to solve problems in a reliable and predictable way. Think of the people who carry a pager and will be waken up when there's a problem involving your code, even if that's you (your 3 AM self will thank your 2 PM self for not being clever with the hacks, trust me).

That said, I'm happy the ecosystem seems healthy, I'm glad we have languages like perl that let you take a 25 year old script and run it today without changes. And reading all the people on this thread that work on perl, if it works for you and you get to make a living off of the language you love: cheers to you, and I'm sure there'll be job openings for perl programmers for at least another 2 to 3 decades.

psadri• 4 years ago

Perl shines once you start using all its thoughtful but quirky features and shortcuts. Eg iirmc, how $_’s value always makes sense given the the surrounding context. Those people who get there tend to become Perl diehard fans.

You only get to appreciate that once you invest a fair bit of time writing Perl code. In the heyday of Perl, a lot of people got there because frankly there few other options. Today, there are lots of scripting language options that are arguable easier to pick up so far fewer people reach Perl Nirvana.

I do have to say I miss how Perl modules have sensible names that at least try to describe what they generally do.

bachmeier• 4 years ago

I don't mind Perl, and I like that it's installed on every Linux distribution I'd ever use by default. The problem I have is that I find it unpleasant to work with text files. Examples:

https://perlmaven.com/open-and-read-from-files

https://stackoverflow.com/questions/1045792/how-can-i-list-a...

I simply cannot remember that stuff, and frankly it's too much hassle. I want to make one call to a simple, built-in function to load a text file, and similarly for looping over the files in a directory. I find Bash plus other Linux tools to be easier than Perl, even though most everything else is easier in Perl.

Zhyl• 4 years ago

I actually find this one of the easier things with Perl. Just add one `while` loop over the diamond operator and then pass the files to it via bash globbing.

BaseballPhysics5• 4 years ago

Agreed, I find the GP comment kind of bizarre. Like, the thing Perl is truly great at is processing text files. Hell, it's one of the main reasons I use it (that and as a general replacement for shell scripting when I need to do anything moderately complex).

And if you really wanna deal with files and directories, IO::File and IO::Dir are easier interfaces to work with and there's plenty of other helper modules out there. I'd never use the base primitives as described in that article.

Mix in File::Find or equivalent and Perl is incredible for file handling.

darrenf3• 4 years ago

Path::Tiny really is your friend here.

https://metacpan.org/pod/Path::Tiny

The Perl Foundation will now be known as The Perl and Raku Foundation

Related Stories