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.
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.
> 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.
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.
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].
my @foo = (1,2);
$foo[1]; #2
my $foo_r = \@foo
$foo_r->[1]; #2
my @bar = (1,2,$foo_r);
$bar[2]->[1]; #2
Re the sigils, you're right, I would just add, $ is for scalar and a scalar iirc can be /either/ a value or a reference, that's why $foo_r and $foo[1] above both start with $. That's what I found unhelpful, it would have been nice to have a distinct sigil for refs (but presumably Larry was out of available symbols at that point!).
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
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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
Most other "popular" languages share a pretty good chunk of their syntax. You can dig through PHP/Java/C#/Go/Javascript/C++/Python pretty easily if you already know one of them. Perl and its magic variables are absolutely undecipherable if you haven't worked with the language before (or in a long time).
>>Perl and its magic variables are absolutely undecipherable if you haven't worked with the language before (or in a long time).
Yeah, either the language gives you magic variables, or you make your own one's in the programs you write. Programming isn't sorcery. Somebody has to write the code for features a language doesn't give you. That the is whole problem in essence, the more minimal your syntax goes, the more code you will write for features the language doesn't give you.
Good part about the Perl magic variables is at least they are documented.
> I know for a fact everybody else absolutely hated having to go in and decipher decades old Perl code.
There's genuinely nothing I enjoy more at work than deciphering, debugging, documenting, and ultimately refactoring Perl code. Even if I'm improving it to extinction e.g. turning parts of a legacy stack into a service with an API, ready for a replacement in some other language to be swapped in.
> 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.
Perl gets new releases on a yearly cadence. We're now at 5.36 IIRC. A far cry from 5.8 or even 5.10.
The new releases usually come with bug fixes, speed-ups, additions to the core language, optional syntax features, etc.
The only way one gets to use an "old" interpreter is if they're stuck on an old OS release (i.e. RHEL?) and/or they don't build their own version and use the "system" Perl.
There's quite a bit of legacy running in our industry. Most of it is not even Perl. Think Java, Jquery, and even Python(2.x) these days.
Most shops don't have the budgets for total rewrites, or even partial and gradual rewrites.
The way old things die, is that new projects don't get started in those languages. To that end, Perl is something of the past already. It is still a very useful technology for a lot of Unixy work on adhoc tasks. But I doubt people learn Perl the way, they learn Python these days. Older people(including me), call upon Perl for lots of work even till date. This is similar to how people continue to use vim/emacs despite things like vscode. There is always going to be a audience for these tools. But the crowd moves on.
The Perl interpreter has been regular updated and improved. There's a new release of Perl every six months, and the libraries on CPAN provide access to various other kinds of technology and tooling.
Python (or at least, the implementation used 99% of the time in the real world) doesn’t have a JIT either, so this property isn’t limited to niche, dying languages.
Well yeah compare to Python - Python has multiple alternative implementations, an active academic and industrial research community coming up with new ways to improve performance and add tooling, including revolutionary work such as meta-tracing, has new GC work, has a couple of JITs depending on what tradeoffs you want, new explorations into specialising interpretation.
Perl doesn't seem to have anyone making this kind of effort? You're stuck with the tech from decades ago.
The implementation is open source and not owned by a for-profit company that could decide to kill it off in the future.
This is a good thing, because it means that we don't have to worry about a program running on one implementation vs another.
Also, one of the things that Perl is great for (unlike many other scripting languages) is backwards compatibility. A program written in the 1990s for Perl 5.004 will probably run with minimal modifications on Perl v5.36.
> Doesn't even have a basic JIT does it? Still using a 90s-era basic interpreter and GC architecture.
So?
> And there's only one implementation. Doesn't seem very healthy.
LOL, okay, this is just hunting for complaints. I could list a half dozen languages that don't have multiple implementations (Rust, Java, Scala, C#, PHP, Go) and yet I've never seen anyone raise that as a concern.
> I could list a half dozen languages that don't have multiple implementations (Rust, Java, Scala, C#, PHP, Go) and yet I've never seen anyone raise that as a concern.
That's because you're misinformed! These languages all have multiple implementations (Scala's is just multiple backends), so yeah people don't complain about it.
But hey, why not, I'll give you that one (tbh, I knew including Java on that list was a bit of a stretch).
Care to try with any of the others?
Wanna try to convince me, next, that HHVM qualifies as a reimplementation of PHP despite no one outside of Facebook using it?
But you know what, no, I have a different question: Why does this actually matter? You've positioned this as some sort of objective downside to Perl without explaining why anyone should care. So why don't we start there, rather than my taking your objection as being somehow relevant.
Please, explain to me: Why should I care that Perl (like so many other languages) only has one real implementation?
Because it fosters innovation. Perl isn't innovating as an implementation. Why's that bad? Because you don't get better performance or capabilities, and you're spending more to run it, and spending more to manage it.
> Care to try with any of the others?
For example Mono is a full clean-room implementation of .NET including C#.
> tbh, I knew including Java on that list was a bit of a stretch
This is partially wrong. Perl compiles the program to its own internal representation in one go, which is then run in a VM. It also uses reference counting, it does not have a GC.
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.
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.
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.
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.
> 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.
`du -h` of a project that did nothing but use clap was 380 megabytes or there abouts.
EDIT: A blank "cargo new" project plus a clap dependency weighs 143 megabytes, not 400. Maybe the 400 megabyte project had another dependency as well, I can't remember. I've edited the comment to say 140 instead of 400.
> Finished dev [unoptimized + debuginfo] target(s) in 36.61s
As anyone who is used to languages like C or C++ knows, debuginfo tends to be huge. It's not surprising that your "target" directory (where both the intermediate and final objects are stored) is that big.
> Downloaded 11 crates (1.4 MB) in 3.71s
Here, you see that 11 of your dependencies together (including clap) were a download of only 1.4 megabytes.
And you won't see these 1.4 megabytes in your "du" output, since the downloaded crates are stored in ~/.cargo instead of within your project directory.
> It's not surprising that your "target" directory (where both the intermediate and final objects are stored) is that big.
Actually this is surprising to me. All it does is parse command-line arguments. I am surprised that this creates 143 million bytes of information.
I accept that I was wrong to say this data is "downloaded" off crates.io, since it is in fact created locally.
> 11 of your dependencies together (including clap)
This is obviously a matter of taste, but to me, this is too many. In the event that sensible command line parsing is not part of the core language, it could at least only be a single dependency.
1. Unoptimized builds tend to be excessively large. LLVM's opt binary (citing this because it's something I have easy access to) is 30x larger on an unoptimized build than an optimized build. [I think Rust is even worse than C++ at the unoptimized/optimized size ratio]
2. Debugging information is also excessively large. It's not counted in the above statistics I gave because I use split debug information (which keeps it out of the final executable for easier linking), but you're looking at debug information being a significant fraction of code size--maybe half of the total binary size could be debug information.
3. Because you include the build directory, you're carrying two copies of everything, minimum--both the .o files and the executable they link into.
For a rough comparison of LLVM, the llvm source directory I have is 1.5G, the optimized release build I have is 15G (of which 1.7G is the actual binary executables), and the unoptimized debug build I have is 86G. Of course LLVM is unusual in producing a very large number of statically linked executables.
4. One of the dependencies inside clap is the procedural macros stuff (specifically, quote/syn crates), which basically requires building your own copy of the Rust parser. If you drop that dependency, the build directory sizes should be far, far smaller.
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.
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.
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:
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.
> 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.
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
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.
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 :)
It could entirely in someone's mind. People use brackets like {{{ }}} in C based languages all the time, when they have to deal with ((( ))) in Lisp suddenly they become unreadable. The thing is people want to spend little effort to learn something new, even if it can help them. Programming in the modern context is reduced to familiarity of syntax, and a small set of easily learnable and usable patterns.
Problems related to bad programming, programming practices, bad program design, syntax bloat etc etc. Today exist with Python too. Python 3.x series is really how we do Perl stuff the Python way.
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!
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:
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.
> 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.
The sigil represents the type of the thing you're accessing, not the type of where it comss from.
$ means a scalar (number, string, reference)
@ means an array/list
% means a hash (also known in other languages as a map, associative array, etc)
A list item and hash keys and values are all scalars. So the array is @foo, but the items are $foo[0], etc. References get a bit ugly if you need to access a whole container whose reference is stored in another container, and also if references are used gratiutously: I've worked in code where no arrays or hashes were used, only ArrayRefs and HashRefs, ugh.
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:
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.
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.
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.
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).
> (also similar with PHP 5-7... though no PHP 6 ever got resurrected)
There's a profound difference: PHP 6 was never released (it was abandoned before its official release), but Perl 6 was released under the "Perl 6" name (https://developers.slashdot.org/story/15/12/26/0354235/perl-... is one reference, you have to use the web archive to look further since the release history became somewhat hidden after the rename).
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
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.
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.
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.
Imagine explaining to someone that the object system is based on a pun-name about priests. You'd feel like an idiot. Nobody's got time for that kind of wackiness these days.
You mean the 'bless' keyword? Yeah, that's a bit quirky, but lots of programming language keywords are kinda metaphorical anyway. The heck is a "void"?
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)
I prefer something that's been around for 20+ years without breaking changes to something newer that's already introduced breaking changes multiple times.
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.
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.
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.
> 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.
> 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.
/^(.)/ 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.
We're doing a regexp match, capturing the first character of a string. This is an usage of the implicit $_ magic variable. The () in the regexp means we want to capture this part, and the "." matches any character. ^ is the start of the string.
We're doing ($fc) rather than $fc because regular expression matches work differently depending on context. In array context they return a list of matches. In scalar context they return a match count. So the ($fc) forces an array context to return the actual match.
So, TL;DR in a more traditional language this would be:
firstChar = left(someString, 1)
And actually in Perl you could do:
$fc = substr($var, 0, 1);
as well, which would be far more understandable to a less Perl-inclined person, but with regexes being such a core part of the language they tend to show up for purposes users of other languages may not expect.
This is indeed a pretty good demonstration of some of Perl's quirkiness. If you like it, it's nice and flexible, if you don't, then it's annoying as hell.
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.
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.
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.