> Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year.
Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.
> Are you saying the language doesn't change much or that it doesn't crash?
Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.
- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly.
- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.
- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.
Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.
#!/usr/bin/env perl
use 5.026;
open my $fh, '<', 'logs1.txt';
while (<$fh>) {
chomp;
say if /\b\w{15}\b/;
}
close $fh;
Python 3.8
#!/usr/bin/env python
import re
with open('logs1.txt', 'r') as fh:
for line in fh:
if re.search(r'\b\w{15}\b', line): print(line, end='')
Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but even there Python relies on external libs.
It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster:
#!/usr/bin/env python3
import re
with open('logs1.txt', 'r') as fh:
regex = re.compile(r'\b\w{15}\b')
for line in fh:
if regex.search(line): print(line, end='')
Perl almost certainly does this by default for regex literals, and that's a fair advantage for the "kitchen sink" style of language design versus orthogonal features (regex library, raw strings) that Python uses.
Python caches patterns, you almost never need to re.compile unless you’re a library or have a specific use case involving lots of unique patterns.
The issue here is that pythons regex engine has overhead, and with lots of sequential calls with small strings like that the overhead adds up.
If you batch lines together in chunks you’ll see a huge improvement in speed, but the point is that it’s not “Python vs Perl” it’s “pythons regex engine vs Perl’s regex engine”. Which is about a contrived Perl-biased benchmark if ever there was one.
With pre-compiled regex the Python version comes down to 1.483s on my machine which is still considerably slower than Perl. I wrote versions of these using substring `index` instead of a regex and Perl was still the clear winner:
time ./index.pl 0.258s
time ./index.py 0.609s
If you factor-in that Python startup time is 0.279s slower than Perl the processing differential comes down to 0.072s.
Well, the two ifs you hedge to qualify Python's parity are pretty damning in themselves, no? Let's stop beating about the bush - if you want to perform a common text-processing job like parsing a log file Perl is hands down faster than Python.
Running a different test the slowest part of the python script is the startup time, otherwise they're identical:
[admin@localhost ~]$ time ./test.py
real 0m0.295s
user 0m0.158s
sys 0m0.138s
[admin@localhost ~]$ time ./test.pl
real 0m0.164s
user 0m0.158s
sys 0m0.006s
#!/usr/bin/env perl
use 5.16.3;
open my $fh, '<', 'logs1.txt';
while (<$fh>) {
chomp;
if (/\b\w{15}\b/) {}
}
close $fh;
#!/usr/bin/env python
import re
regex = re.compile(r'\b\w{15}\b')
with open('logs1.txt', 'r') as fh:
for line in fh:
if regex.search(line):
continue
The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.
> Also, perl is incredibly inefficient: it's even slower than Python.
That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).
Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.
Nodejs is very fast, because it uses an an engine that has had multiple millions of dollars thrown at it to make it fast. Most interpreted languages don't fare well against it.
Perl fares somewhat favorably against Python, Ruby and PHP though. Those are what I would consider equivalent languages to compare against to get a general idea of its speed.
Not just orders of magnitude more money, but more importantly the large number of incredibly talented people working full time on JavaScript, in many different companies and research institutions, collaborating together. JavaScript benefits from an overwhelming network effect and critical mass of tools and developers, that Perl just can't touch, and never will.
Depends on what you mean by "fare well". Even in those benchmarks, Perl seems to have a lower memory footprint than Node.js in most of the results.
It's also worth noting that three of the examples (pidigits, reverse-complement, fasta) don't seem to do any multiprocessing in Perl whereas they do in Node.js. At least for reverse-complement and fasta, it should be possible to rewrite those to use multithreading (like the Node.js versions do).
There’s something fishy about that report. It says it is presenting the fastest programs, but when I click through to “all perl programs”, there are faster (often by 1-2 orders of magnitude) programs / runs:
Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the codebases (old and new) to newer systems and stacks. As you can tell, the SMEs have no interest in learning other things and so any new initiatives that require them to implement it is subject to their preferences.
Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers.
You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way.
So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.
There's no need to rewrite a system that works and that you're not gonna change. While programming languages go out of fashion there will always be people who are capable of writing them. The median age of a cobol programmer has not changed in 20 years because more people keep learning the language.
Demand in this case, will likely create its own supply.
That analogy doesn't really work - software doesn't get worn out from interaction with users. If software is working and in use, then it's age doesn't matter.
Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.
Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be.
And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
Wisdom is in not in spending years and millions rewriting billions of lines of cobol code into a new language and then rewriting that other language into another newer language and so on … what's the problem in maintaining what's already working?!!
the will create a new team to rewrite it badly because now they have no other choice
Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
> and it’s hard to impossible to find Perl programmers
Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon.
That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point.
My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned).
Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.
A former boss was fond of saying "Software is done when nobody is willing to work on it anymore."
New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is.
I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.
Those are all pretty basic Algol-family languages (at least if we're talking vaguely modern Javascript). If you were thrown in to J or Forth or Erlang you might have a different experience.
Funny enough, Erlang is my preferred language (or at least one of them).
I don't know if I'd necessarily call the JS in question "modern", though. It's running on RhinoScript, which needless to say ain't exactly the latest hotness. Still, the platform in question does happen to support/encourage AMD modules (with some special comments for certain components), so I guess it could be worse.
There are plenty of silly reasons to rewrite a piece of code, but language preference has to be one of the worst.
Now that I think about it, that's actually a decent hiring test:
Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them.
It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.
The Amazon retail site is written in perl (at least the presentation layer still is, you can find mason references still in the HTML source if you go looking, don't know how much else behind it is in perl).
The fashion retailer Net-A-Porter has been a Perl shop since 2000. Haven't checked if that's still the case. They used to employ quite a few leading lights in the UK Perl community a few years ago.
I used to work for a company that used Perl as their primary language.
The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste.
They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.
Nothing against the language but I don't know why you wouldn't use literally anything else nowadays. Python or PHP, JavaScript or even Ruby if you're looking for a dynamically typed language. AWS don't even support Perl.
I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all.
To quote myself from a recent discussion:
I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability.
For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.
Strongly agreed. It’s much more about the team, the conventions used, the organization of the codebase, and the coding culture of the team, than it is about a specific language.
True, but the cultures that grow up around a specific language tend to encourage certain conventions, standards of organization, and team coding cultures.
Under that standard it’s true, but it’s also true for virtually any language and is therefore not a good defense of whether or not a language lends itself to unreadable code.
1. You can use virtually any language to write clean code
Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really nearly impossible to write good code in.
2. Perl lends itself to unreadable code
If you stick to Modern Perl you still might end up with things like `wantarray` in your code so I guess this is kind of true. You need to be judicious in your use of code.
Some languages lend themselves more easily to writing clean code, like I feel about Go or if you hate the Go type system, Ruby. Even in Ruby I feel like metaprogramming is ripe for misuse.
It's a tough thing to talk about. I don't feel like I wholeheartedly disagree with your sentiment which seems to be "some languages lend themselves to bad code" and subsequently that Perl lends itself to bad code but there is plenty of ambiguity in these thoughts.
In my 30 years (yes) working with Perl (4->5.32), I have never, once, used wantarray. Perl does not lend itself to bad code. Bad coders, people whom cannot use or articulate good practice in coding or documentation, lend themselves to write bad code, in any language.
I used it for automation of my calculations in grad school. For data analysis. For monitoring.
In my subsequent day jobs, I used it to develop shipping products. No one really should care what language something is written in, if it does the job well.
Most recently (a few weeks ago), I used it as the driver for creating and submitted 10's of thousands of jobs for COVID19 research the team I am working with[1][2].
For the above project, I had to forward port 12 year old C++ code to make use of modern C++ based boost libraries. Took a bit of time to fix this. But the perl code, ran perfectly, and quickly[3].
Anyone trying to portray things otherwise, likely has a longstanding axe they like to grind. Language advocacy can be done without attempting to tear down other languages. Though those who argue against perl often bring up the same, old, tired, and incorrect points.
I'll keep using perl thank you. And Julia. And C. Each has their domain of applicability. Most people know and understand this.
I think a useful concept is that a project will have a "discipline budget", just like the "language strangeness budget". Yes, if you're careful with your self-restraint and code reviews, you can write good, clean, maintainable code in a language that doesn't give you a lot of support for that. But if you do that then you're expending your limited supply of discipline, and will have less to spend on other aspects of the project like not scaling prematurely, not using cool-but-unnecessary tech...
Yeah, I've got a Perl codebase that's conservatively tens of thousands of lines, and it's honestly a struggle to write anything in it that isn't a big ball of mud. There's about 50 different ways to do anything in the language, the syntax is infuriatingly obtuse, and you can't rely on any documentation because it will recommend doing things that experts don't recommend doing.
The system is from like 2013 and still going, but I really wish I could rewrite it in a language I can actually train people on in a reasonable amount of time. It took the one junior I have about 6 months to get to the point where he could read the syntax without tearing his hair out. It's not really built to create maintainable structures.
The libraries and stuff are full of opinionated little "gotchas." As an example, the Test::Simple module will throw errors if you use a number to title a test which is infuriating when you're writing a test which tests all the numbers in the space of acceptable or possible inputs.
Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar.
Compared to Python for example where you'd literally just pass the array to the method like method(array).
As someone who learned python first - the idea that `myfn(@xs)` would call `myfn(1,2,3)` is... unnerving. Implicitly splicing in arguments makes me wonder what other kind of syntactic oddities are going over my head in my code.
Python is "relatively" consistent about * and being used to expand or contract arrays and dicts, respectively.
a, *, b = [1,2,3,4]
def foo(*args):
bar(*[1,2,3])
all do "what you'd expect" from the single concept that "* is sort of pattern-matchy for an array".
But the more important bit is just that you don't have to prefix variables with @ and $. Python is optimized for writing code that acts on variables, while perl is optimized for code that acts on strings. While strings are certainly a common data type, most code isn't modifying strings directly. So optimizing for that case doesn't make a lot of sense.
For many years Perl subroutines didn't even have method signatures so you had to unroll @ on the first line of every sub. I think even today it may still be considered experimental. Jeez!
The reason for the @_ is that it is a simple way to get both pass by value and pass by reference semantics.
The values in @_ are aliased to the values in the subroutine call.
Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.
However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.
Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:
my %args = @_
Making signatures default will be a big improvement, but the power of the simple abstraction @_ provides should not be underestimated. It's actually an elegant solution to a complex problem.
I can say the same thing about a legacy Java codebase that I had to work with at a big "enterprise" software company a few years ago. The code was so convoluted, with some files over 12k lines long. You can write spaghetti code in any language.
Perl used to have one of the most extensive module libraries. One of the things I miss about Perl was it’s more sensible module namespace convention (Eg Net::... for networking related) vs the more hip but confusing and hard to discover naming of node modules.
Yes, the hierarchical namespace for modules was super nice. Migrating to a flattened package structure of npm was a disappointment. I ended up encoding the same type of structure in internal npm package names, e.g. "@myorg/net-aws-.." and "@myorg/file-..."
> There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.
That is true. This alone might be a good reason to look elsewhere for new projects.
However, for existing Perl codebases, PAWS is comprehensive and popular library, and is generated from the official botocore: https://github.com/pplu/aws-sdk-perl
Keep in mind TDD wasn't really invented yet, so it's understandable.
Also, CPAN had better libraries than pip did all the way up until I last used Perl in 2015. Ofc, it depends on what you're doing. My point is, there was a reason to use Perl once upon a time ago.
The alternatives back then were PHP, C, C++ (the old bad kind), BASIC, assembly, FORTRAN, and others like Smalltalk. Seeing this, it's understandable why Java took the world by storm the same way Perl did.
I don't know about TDD specifically but we have the Perl community to thank for setting the bar for rigorous testing back in the ealry 2000s with the numerous Test:: modules on CPAN.
Yes, I manage a set of tools and libraries written in perl that are pretty large and service the whole company. That said we're re-writing them all to Python so more people can contribute... Saddens me a little I like Perl, but I'll get over it.
Yes. You’ll be surprised. Some of the biggest tech companies still use Perl in their critical components in production, and some of the initiatives are in recent years.
The primary use case of Perl is systems automation. Personally I prefer Node.js but most Linux distributions come with a Perl interpreter already installed and not Node. If you are working in an enterprise environment and for security reasons are not allowed to install software, which is common, you can still perform automation with Perl scripts.
> Are there actually people that are still deploying new things in Perl?
My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).
It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.
> The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.
I actually worked for OTRS for some years. It is quite a remarkable company as it is creating an open source line of business software with a nice team of people and is making a sustainable business out of it. There are not much other software companies that managed to do this.
Yes, you can call them open core now. But still many companies are using the community edition and are served well by it.
I worked closely with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl!
I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved...
Also, the technical founder started https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby!
Modern perl5 is ok. But the ecosystem is slowly deteriorating.
What I'm hoping for is that Perl 7 will enforce those "proper code conventions" and mitigate that deterioration. Making a lot of common pragmas the default is a good start there.
Nice, thanks for the link and for your contributions to OTRS, it has improved workflows tremendously on both companies I've set it up on. I've messed around on some of the source and template files for some dirty hacks over the years and did get the impression of it being very well structured and with pretty clear separation of concerns even though I'm not a Perl coder.
Hmm ... don't conflate the presentation UI with the underlying language. I wrote my companies website (2 jobs ago) in Mojolicious (perl web framework), with a responsive UI, based in part upon bootstrap. Very modern (for the time) UI. All backed by a very fast implementation.
IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.
I am not actually talking about the quality of the UI - I am just pointing out that the UI seems to have been the same for years now, and I would think a rewrite from Perl would have changed that. Yes, you can totally swap out the backend, but IMDB codebase is old. HTML and the sprinkled JS (if you look at page source) is probably baked in deep.
I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack.
Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again:
Traceback (most recent call last):
File "/usr/local/bin/pip", line 11, in <module>
sys.exit(main())
File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main
command = create_command(cmd_name, isolated=("--isolated" in cmd_args))
File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/__init__.py", line 96, in create_command
module = importlib.import_module(module_path)
File "/usr/lib/python3.5/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 986, in _gcd_import
File "<frozen importlib._bootstrap>", line 969, in _find_and_load
File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 665, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/search.py", line 18, in <module>
I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it:
While experienced python devs will say, yeah that'd how you should do it. The problem is that python by default isn't using virtualenvs. Consider rust or is where you need to specify global installs.
The reason I use linux and perl (or sometimes bash) - it just works, I get the least number of surprises. Dependencies in perl are handled by my OS same as everything else, I don't need to maintain multiple package managers, I just bash out the script and move on
I don't write software as an end goal, I write software to accomplish my end goal.
My full-time job is working a codebase where the back-end is entirely written in perl. Codebase was started around 2014. This was probably a bad decision, the founder was a perl guy.
Perl is not bad but no new codebases should ever be written in it imo. It's to easy to shoot yourself in the foot unless you know perl REALLY well. Moose is ok but a far-cry from any modern OOP system.
Lots of new things. Perl is an immensely powerful language. If you know how to write code well, it will be fully comprehensible by even casual programmers.
Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today.
It is alive and kicking in the bioinformatics community!
I still think Perl is a much better tool for what some bash and python scripts are doing. Maybe Perl7 will remove some stigma and allow for people to use the tool instead of it being instantly dismissed.
Last year I had to perform date arithmetic in C shell scripts on a locked down server (no way to install or compile programs and obsolete or missing utilities).
I considered Perl, since it was the only scripting language interpreter, but the good enough (on paper) date handling libraries I found on CPAN turned out to require a far newer Perl 5 version that was available.
I'm afraid that the best-case Perl solution would have been more difficult to write than the roundabout but reliable and easy to understand final solution (Oracle SQL functions executed through the command-line SQL*Plus client).
Once this is out, I'll be interested in any well written guides or books, it has always felt like "the one that got away" to me.
Back in 2002 I had to choose between learning between Python and Perl for a project, but "everybody knew" Perl 5 was soon going to be replaced by a new shiny different Perl 6, so I chose Python.
It will be interesting to see where Perl can live and gain new users nowadays. Python has so much become the "default scripting language", and has so many bindings and libraries.
I think you can learn most/all of Perl 5.32 with http://modernperlbooks.com/books/modern_perl_2016/ , and it appears this is, initially, going to be 5.32 with some saner defaults. So you could really start now, given that.
> This beloved guide is now completely updated for Perl 5.22.
I've been working with Perl since about 5.20 and am on 5.31 or 5.32 and haven't noticed many breaking changes FWIW.
The 2016 edition covers most of what's in 5.32; if I were to do an update for Perl 5.32, I'd include postfix dereferencing and the built-in function signature mechanisms now that they're very stable and supported.
The Osborne effect for languages. Now there's no risk in announcing version 7 since effectively everyone who was going to choose Perl already chose Python (or Javascript).
There's also the Ozzy Osbourne effect for programming languages:
I've listened to preachers
I've listened to fools
I've watched all the dropouts
Who make their own rules
One person conditioned to rule and control
The media sells it and you live the role
Mental wounds still screaming
Driving me insane
I'm going off the rails on a crazy train
I'm going off the rails on a crazy train
Great. Perl is not my favorite language, but the things its good at and the body of nifty code out there deserve more recognition than they get. Hopefully this will remove some of the discouragements to curiosity that have kept people from looking harder at perl to see if it fits their problems or their mind better than other tools.
No, there isn't. Perl 6 got renamed to Raku (https://raku.org using the #rakulang tag on social media). There's a weekly blog post should you want to stay up-to-date: https://rakudoweekly.blog
Just to be clear to everyone: this doesn't break anything. If you continue to use Perl version 5, you're fine. If you want to upgrade your major version of Perl, then of course you need to know what that means.
To clarify this: if v5.32 can run your code, you should be safe. There have been various small changes in Perl 5 that might not handle something you wrote in 1995.
I love perl, so I’ll definitely spend some time tonight trying to find out more about the plans. From just this article, it’s hard to see how this is different than just making ‘use v5.34;’ flip some switches. That’s just business as usual in modern perl, even if it changed more things than normal. Still, if bumping the major version gets people to take another look at it, it will be a good thing. And maybe there are bigger plans post-7.0 and this is just to ease the initial move.
They are making some space for (controlled) breaking changes. It also sends a message that Perl has a clear path going forward. I'll consider it for my next projects, especially the automation ones.
This feels like a last ditch attempt to save a dying language. (https://i.imgflip.com/4676mf.jpg)
I wonder what exactly does Perl bring to the table as a language, why would one consider choosing it over other languages.
People are interested in using it and people are interested in developing it, so it continues to be used and developed.
I got my start with Perl; I wrote a book about it, I spoke at every conference, I did training, I maintained the Emacs mode. I started working at Google and, forced to use static languages, found them to be just as productive as Perl. And, they eliminated a lot of problems with Perl -- libraries were resolved at compile-time, and I just ended up with a binary that could be run anywhere (no @INC madness); types were checked at compile-time, so silly errors that required extensive unit testing in Perl could just be automatically underlined by my editor and fixed before I even saved the file.
Something else that bothered me was how much mindshare the dynamic languages were competing for among themselves. I would prefer to write a Perl program over a Java program any day... but Perl did not seem to be fighting with the Javas and C++s of the world, instead it was always trying to take on Python and Ruby. And Python and Ruby were like that too -- every Ruby programmer was out to kill Perl because they didn't like Matt's Script Archive. (Nobody wrote 1990s Perl in the 2000s, so it was kind of a strawman.) You ended up with a bunch of like-minded people fighting for the small attention share of "we don't really care about runtime performance", and all the factions were just too small to take on the larger issue of entrenched static languages. Java and C++ never felt like they had to take features or ideas for Perl, Python, or Ruby. So it all seemed kind of pointless.
With all that in mind, I do think Perl failed to "win". It is a neat programming language, but probably too complicated for beginners and not productive enough for people that have gotten comfy with C++/Java/Go, which are pretty darn productive these days. Meanwhile, Python found its niche pretty much everywhere -- you can program microcontrollers with it, you can write a video sharing website with it, you can do data science with it -- and it's a great introduction to programming for beginners. And, Javascript kind of came out of nowhere to conclusively "win" the dynamic language war (because a dynamic language needs a runtime, and guess what runtime exists on pretty much every computer and phone around these days?)
TL;DR: I kind of agree that the programming language wars have been fought and lost by Perl. That doesn't stop people from wanting to make it better, or to continue to use what they know. You can make lots of great things with it, so people continue to use and improve it.
Perl lost the war because it didn't turn-up for the battle. In the 2000s it went into a kind of COVID19 self-isolation phase. First there was Parrot - a half-assed attempt to create a CLR for dynamic languages. When that failed the MoarVM adventure began. There were about 3 implemetations of Perl6 in development simultaneously (MoarVM, JVM & Rakudo) as Perl5 hemorrhaged mindshare. All-in-all it took 15 years to produce a 1.0 which was so dog-slow for Perl's common use-case it was unusable ... and still is.
Yeah, Perl 6 was certainly A Thing. I am not sure practicing Perl programmers cared much about it. I went to the talks and thought "neat" but it didn't really seem like "welp, this is taking forever, I'm switching to Python." Maybe if everyone working on Perl 6 decided to work on data science tooling instead, Perl would have "beaten" Python in that area and things would be different, but the world doesn't really work that way, so I don't think Perl 6 really mattered in terms of Perl fading away. A lot of people learned a lot of things about language design, and that will no doubt benefit the entire field for many years to come. (Look at "Go 2" versus "Perl 6", for example.)
On some level, everything is like that. Perl was a better awk/grep and was successful in replacing those tools. Then one day, someone decided to use it for CGI, and it got a huge popularity boost. But the people that decided to use it for CGI could have easily used something else, and it would have probably worked fine and Perl never would have been popular. It was just random chance that they picked Perl and made it popular. I feel like everything works that way. Javascript is popular for web UIs because someone decided to add it to a popular web browser. There is always some intrinsic randomness that plays a part in gaining mindshare. A bad tool with a good mindshare can do well, and a great tool with no boost can languish in obscurity. Perl benefited a lot from luck, but rolling the dice doesn't last forever.
If mod_perl had been designed more like mod_php Perl's web frameworks (Catalyst, HTML::Mason, Dancer & Mojolicious) might have had a chance of competing with PHP and Rails. PSGI could have helped Perl compete with Ruby/Rails but PSGI came too late.
Perl 6 is still very much a thing, but it's called Raku now (https://raku.org using the #rakulang tag on social media). It has a weekly blog post https://rakudoweekly.blog should you care to want to stay up-to-date!
To my knowledge, only 2 implementations were ever in development simultaneously: Niecza and Rakudo.
Niecza focused on producing a Perl 6 on the .Net infrastructure. Rakudo is based on NQP (Not Quite Perl) and initially ran on Parrot, then also added the JVM as a backend, and then later added MoarVM as a backend.
Niecza sadly stopped being developed as its main developer developer decided it wouldn't be able to come to a full release (around 2012/2013).
So to say that "about 3 implemetations of Perl6 in development simultaneously" is incorrect, and then to name MoarVM, JVM and Rakudo as the three is even more incorrect.
Perl 6 got renamed to Raku in 2019. Since the first release in December 2015, it has become about two orders of magnitude faster.
You can check out the Rakudo Weekly News should you wish to stay up-to-date on developments in the Rakudo world: https://rakudoweekly.blog
Speed. I moved mostly to Ruby years ago, but when doing lots of text processing, a trivial script in Perl runs a lot faster than a similar trivial script in Ruby.
There used to be a big Python/Perl debate. I'm not sure I could have predicted how well that would turn out for Python, and how poorly for Perl. Readability and ease of use matters?
So it's the Osborne effect? Where you stop using Perl 5 because you're waiting for Perl 6 (announced in 2000, released never? As Raku? As a rolling release? The history appears confusing in Wikipedia.)
Perl 6 was released as language spec and on the Rakudo implementation; the rename to Raku was kind of a backformation from the name of the Rakudo implementation, but it was after the first stable release.
Perl 6 had its first official release in December 2015. It has since been improved, mainly in performance and in async / event driven capabilities. It got renamed to Raku last year (https://raku.org using the #rakulang tag on social media). You can check out the Rakudo Weekly News if you want to stay up-to-date: https://rakudoweekly.blog
> And I guess Perl also never had its Django (or Rails).
It’s got two of them - Catalyst (older still works fine) and Mojo - newer and shinier.
I think python is a better fit for mathematical work. I like to say that python helps you think more like the computer does, and that perl helps the computer think more like you.
rails as far as I understand is opinionated and optimised for CRUD / database type applications. Catalyst is much more agnostic about the model you use. It provides the flexibility and a way of structuring the code and providing debug tooling that makes structuring a decent size app well reasonably easy to do.
In my opinion, those are results of Perl losing mindshare. Numpy is not exactly hard (R has a significant fraction built in, and there's an old standard library for Scheme, of all things, that is very similar). Perl was perhaps the leading language for websites, but the Perl 5/6 situation just confused everybody as it dragged on, which made Python and Ruby libraries seem more attractive.
Universities switched from teaching Java and Scheme to teaching Python.
Probably because Python resembles pseudo-code.
Anecdotally I've heard from a few people who said Python was the first language where ideas just made sense to them. An "easy to learn" language, in other words.
(I can't relate to that and don't know why Python is thought of that way. As far as I can tell, beneath the syntax (which is prettier than Perl), Python is a messy language with even messier standard library.)
I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.
Ok, so I wrote tons of Perl and am to this day a fan, but I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_.
It is flexible and fun and I do miss it.
True story: years of passing functions to other functions and map/greps made the switch to FP Scala (another language I fear will die) a lot easier!
> I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_.
Perl first, then JavaScript.
Did you know JavaScript classes are blessed hashes?
They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
Old JavaScript made the blessing crude and obvious.
Modern JavaScript lets you hide it in a "class" decleration. Which you can also do in Perl if you want (though you'll need to choose a module for this, and people generally prefer a different approach to dressing up objects in Perl.)
There's still a blessed hash under the hood which you can see and kind of have to be aware of... in both languages.
Perl and JavaScript both give you a minimally specified set of tools you can use to build your own more advanced object system.
IMO, that's why both languages have been able to be extended and adapt so much.
If you look at tools like Moo and Moose in Perl and the different coding paradigms that evolved in JS before the "class" keyword was standardized, this is pretty clearly evident.
JS has had the advantage of a standards committee pushing new language features aggressively. Perl has moved more slowly, keeping a majority of functionality in libraries.
Traditional JavaScript has a notoriously poor object system yes. If those are the only two languages you know then I guess Perl's object system doesn't seem so bad, but that shouldn't be a defense of either language.
Very similar story here; I barely write any Perl nowadays but am still very fond of it.
I especially like the sigils - they serve in a way as a primitive type system and actually convey useful information when reading code. I suspect people who complain about them are the same who dislike strong typing.
Interestingly, like you, nowadays I am very fond of Scala.
huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird.
And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.
Perl definitely has a lot of non-patterned arcana. For instance,
$| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0.
In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.
I'm no fan of Perl, but you can use $OUTPUT_AUTOFLUSH instead if you "use English;". So this isn't really a Perl language thing; it's a style thing. Other languages can be made to look really bad with poor style. The question then becomes what is culturally accepted, and what is not.
The problem is that nobody ever tells you these things, the documentation doesn’t cover them and as a result everyone still uses the terrible original syntax.
Sure, it's got lots of historical baggage, but there are more sensible alternatives to $| - like STDOUT->autoflush(1) - it's not like you have to use the obscure versions of every feature.
That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code.
If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.
Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn.
If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
Because perl improved over time, but they didn't want to break people's existing code needlessly.
No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of older, 'worse' things.
The concept of giving functions names spelled out with letters that form words that describe their meaning was invented a long time before Perl figured out that doing that was better than overloading a limited set of ASCII punctuation with random abstract unrelated concepts.
...and how many of them were designed to be sprinkled liberally in the command line?
Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.
Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)
When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.
You are going to end up perpetually unhappy if you always assume that people designed things the way they did just because of stupidity / incompetence. Perhaps instead you should take a while to think about the reasons why they might have chosen their design. Even if you can't immediately think of a good reason, doesn't mean there wasn't one.
For this particular case, I'm not sure what drove the selection, but I would guess (since the decision would have been made many decades ago!) it was probably based around perl trying to operate similarly to other command line tools of that era, like awk, sed, (or even ed?), so that people could switch to perl and have a familiar environment? But I don't know, nor have I researched it. In any case, perhaps give the designers the benefit of the doubt before assuming their incompetence?
You have to bare in mind Perls roots are as an awk-like language for the command line. In those instances weird line noise syntax was the idiom and as Perl grew it moved away from that but without breaking compatibility by default.
This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.
Whatever happened to the neophyte raising him/herself up to level of the master? Programming seems to be the only profession in which the beginner is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? If you want to grok Perl learn Perl ... thoroughly.
> Programming seems to be the only profession in which the neophyte is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"?
The problem isn't merely that notation is easy/hard, but that people will not only pass judgement about a language (or any other idea), they will also work actively to convince others to agree with them, and oh yeah, that programmers are people too.
> "worse, that he/she expects the language to be dumbed down to make it easier to learn."
And why should "simplify" have the connotation "dumbed down, for dumb people"? Everyone benefits from simpler things with fewer warts and fewer hazards.
I suspect that Ruby has almost no usage. I've only ever heard of using it in a handful of startups from the valley and it's only Ruby on Rails.
Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.
Some things are unavoidable though. Perl hijacking a user space variable to do internal sort management? Bizarre to my mind, and utterly confounding the first time one accidentally runs into it.
That's not so much Perl hijacking a user space variable as Perl having some single character globals that have special behavior. Really, you usually learn about those early (sorting is common), and if you're using strict like you should be, if you define them and use them they will work as expected until you use a custom sort, in which case you'll track down the error.
In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.
> utterly confounding the first time one accidentally runs into it.
Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.
I take it you've never done much shell scripting? This part of perl's baggage comes from its roots as a "better" shell/awk/sed. I don't like it any more than you do, but I must say, I wish people would reserve some of the vitriol they have for perl for the shell. Because I gotta tell you Rabbi, perl is a hell of a lot better than shell scripts. And that's even if you compare perl4 (1991-1994 or so?) to the very latest bash or zsh.
edit:
BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)
Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)
Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.
Developers spend most of their time reading other peoples code, so yes, one does have to learn the less sensible alternatives, if you choose this tool. It's called historical baggage for a reason.
The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
In Perl `$` is strictly a scalar variable though this can be a reference to an array, hash or object as they are stored as references. Not to be confused with `$` in PHP which simply denotes a variable of any kind. In Bash `$` denotes the value of a variable.
> You learn perl, and you've learned nothing but Larry Wall.
Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose.
Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)
25 years ago is 1995, and around the release of Windows 95, the first 32-bit version of Windows.
A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.
Windows NT was released in July, 1993. Almost exactly two years before Windows 95.
In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)
My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.
I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.
Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.
It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.
Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.
I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.
Start https://perldoc.perl.org/perlre.html#Extended-Patterns . I was trying to find an article from many years ago, but either my google skills fail me, or it is dead. Perl's regular expressions haven't been regular expressions for a long time. Beyond that, the ergonomics of perl make them much more useful for things like flow control than in other languages. It's similar to how you can do type matching in Java, but it's ugly, versus a language like Haskell where using type matching simplifies the code.
Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.
With which JavaScript version? At the time HOP was written I remember JavaScript still doing all it's for loops in C-style and there was certainly no arrow syntax to make anonymous JS functions manageable.
There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).
Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.
Favorite syntactic sugar feature: the /x modifier which makes the regex ignore spaces and comments, meaning you can break your regex into multiple lines and comment them.
Have you ever read O'Reilly's "Mastering Regular Expressions" by Friedl? He does a deep dive into the weird guts of regex modifiers.
I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
Friedl's masterpiece was my introduction to server-side programming in 2000. I'd been doing front-end for a few years with Dreamweaver and I was looking-up it's find & replace features in "Dreamweaver Bible 8" where regexes were mentioned as the ultimate weapon. "Mastering Regular Expressions" was referenced in a footnote and fortunately my local library had a copy. My mind was blown. Regex symbols were just so powerful and the examples were mainly written in Perl which added even more power to them. The book was part of O'Reilly's Perl bookshelf so in addition to Friedl's book I bought the other Perl classics - "Programming Perl", "Perl Cookbook", "Mastering Algorithms with Perl" and "Learning Perl". With CPAN downloaded to my local disk I felt like a hitch-hiker setting out on a journey around the world needing nothing more than Perl in my backpack. Those were the days. Now I have to download 200Mb of node_modules before I can get started.
Recently I found some old floppy drives at the back of a drawer. I manager to find an usb disk drive, inserted the floppy, what do I find? Sure enough, Perl code I've written back in 2000! Indeed, those were the days :)
If it was back-end website code it probably used Lincoln Stein's CGI.pm module which was used everywhere though it was a bit of a beast with frequent security updates. I later progressed to CGI::Application for an app which ran a business for 12 years before I converted it to Rails. I always thought Mojolicious was a great Perl web framework but unfortunately it landed just as Rails was picking-up steam.
Agreed. Regex is a “part of the language” not a bolt on library like you have in Python. It’s one of those cases where you don’t even know how crap regex is in another language if you’ve never used Perl.
I mentioned Boost's Regex in C++ (boost is essentially a different language), but I didn't bother to mention my experiments with regex in C, for example:
If you're interested in improved regular expressions, I wuold suggest you have a look at Raku's regular expressions and grammars (formerly known as Perl 6): https://docs.raku.org/language/regexes
I do recommend Haskell. (But do not go into regexes first!)
But even though it has a similar powerful set of operations for regular expressions, people mostly don't use it, because there are better ways to deal with text.
> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.
I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks.
The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:
my $bar = foo();
my ($baz) = foo();
I firmly believe that context is one of the worst ideas in Perl. There is a good reason why it was not borrowed by other languages. It is far better to expand arrays like Ruby does with * instead.
This is why Raku doesn't have contexts in that sense. All a subroutine or method can ever return, is a single object. Such an object can be a List or an Array, but it is still a single value.
Whether context is good or bad, a success or a mistake, there's no denying it is either one of the most or the most important idea in Perl.
That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing.
That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).
Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.
The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.
I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.
Things have moved on. Moose is a bit of kitchen sink. These days you would generally choose Moo first unless you really needed the meta object features. Or to get incremental Moo(se) features you’d use Role::Tiny, Class::Method::Modifiers And Type::Tiny
At least one of the inspirations of Moose, was the object system of Perl 6 at the time (now Raku https://raku.org using the #rakulang tag on social media). To create a Point class that has an x and a y attribute, you'd write:
On the subject of transferrable knowledge, Perl was the first language I learned, and I was always a little bit confused about why every language I learned since then didn't have pronouns, until finally magrittr came along in R and made perfect sense to me, since "." in magrittr/dplyr feels a lot like "$_" (or "@_") in Perl.
Perl’s core object system isn’t really an object system, it’s a toolkit for building object systems. Of course this leads to too many ways to do it, so if starting fresh just use Moo
> Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird.
Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.
Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.
I think that criticism that by learning perl one doesn't get any transferable concepts is bit unfair. Though I no longer program in perl, some of the things I learnt using perl has been useful later too. To list here are some of the "concepts" that I learnt using perl: regexes, some aspects of *nix system programming (fork, zombies, signal handling etc.), modular code organisation (writing/using perl modules), code documentation (aka PODs) imbibing importance of documenting the code.
True learning some other language (say Java) would make familiar with other concepts (say OOP) but perl has its fair share of concepts that one can pick by programming using it.
This seems to be a common experience - people say it felt powerful and modern in the 90s, because it was. For those who started programming in the 00s and 10s it looks clunky and weird compared to the other options.
Perl was released in 1987. The languages released in the 90s all stole Perl/Awk's good idea (have an associative array/hash map/dict type as a builtin data type) but had much nicer syntax.
I stuck with Perl even when Ruby came along and offered to be the next best thing because Ruby didn't have a use strict equivalent. Having to declare variables before use is a good thing.
PHP was a reimplementation of Perl by someone who didn't understand why Perl did things the way they did and so ended up creating a vastly inferior language. Other than maintaining some legacy projects, I've not touched PHP in over a decade and I'm glad to avoid it. Perl is a tool I still return to for some tasks (one was a bizarre management request for a spreadsheet of all the Java classes in a large project which took fifteen minutes to create a Perl script to generate and ten of that fifteen minutes was looking at documentation for Perl modules I hadn't used in a long time).
Yes and No. PHP (Perl for Home Pages) main starting point for popularity was that it was easy to make into an Apache module that could be used on shared hosting. Perl's Apache module was a single interpreter for the whole server. Great for business sites and such, not good when you have multiple unrelated users using the same server. PHP was just something that you could turn on and uses on your shared hosting.
According to Wikipedia PHP stands for "Personal Home Page".
Yes, the memory isolation model of mod_php was the crucial factor in beating the competition. With mod_perl you had to write your Perl modules to a specification so that globals were not accessible by other hosts. That was too much of a risk for shared hosting providers. The situation is muddied, however, in that a lot of shared hosts only allow PHP as a cgi which, in theory, puts it on a level playing-field with Perl. However, in practice, Perl only has one PHP-alike templating framework - HTML::Mason - and that requires mod_perl to perform decently. So PHP's other advantage is that its templating engine is simply faster.
To be honest Perl 5 isn't really like Perl 4. They are quite different languages - Perl 4 didn't have objects, and Perl 5 places heavy emphasis on them.
Up to you to decide when you think it started, but I'd say the current language we think of as "Perl" started with the release of Perl 5.
Most Perl 4 runs under Perl 5, and most Perl 5 written in the early years did not place heavy emphasis on objects. When I started in Perl, it was common to write code in such a way that it would run under either because it might have to.
Today, objects are used heavily. And furthermore the way we write those classes has changed a lot since Moose and friends became popular. As a result most Perl code bases written in the last dozen years look less like early Perl 5 than early Perl 5 looked like Perl 4.
Perl 4 and Perl 5 are more of a continuum than different languages.
As far as i know Java and PHP became popular later in the 90s / early 2000s. Javascript was browser only until 2010, Ruby only became popular after Rails came out mid-2000s. There is a decade gap there.
Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)
I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as I wrote a map rendering system in Javascript back in school in 2005.)
True, I played with Rhino, Jack / JSGI early on, and did a couple projects with Aptana Jaxer around 2009. It was not really an option most developers would even consider, though.
Node came out in 2009, and writing server-side JS was still a fringe practice for a couple more years, so 2010 is me being generous to avoid comments on the exact timeline ;) It really picked up mainstream adoption around 2011-2012.
Was Rhino ever anything other than a minefield that you were essentially pigeonholed into using for compatibility reasons or something similar? I have used it before but only because we had specific technical requirements that demanded we run Javascript on a server-side JVM implementation.
At the end of the 90s Javascript was used to write a part of Dreamweaver and I mean the app itself, not the Javascript/HTML interface. So the language as always existed independently of browser implementations.
It does add up because Perl was released in 80's and became popular in the 90s, when the other newer languages you listed were designed and released. In the early-mid 90's, "CGI"/"CGI scripts" was synonymous with Perl - it was the backend tech
While you can FIND Perl jobs, it is effectively dead for most of the hiring market. It will never truly disappear. COBOL is not dead either. Is it really something that we think of when we talk about modern software engineering? Not really.
How much production software is started from scratch every day using the language?
I started my career in Perl and I still have fond memories of working with it up to late 2000's, but by that time the writing was solidly on the wall.
I was on one of several CAD teams at Intel in the 90's and huge parts of pre and post-silicon Itanium simulation flows for timing, layout and verification were written in Perl. (Not even Perl 5.6 so we hit the 2GB file limit often!) ... Not the tools themselves, but the control flows and asset managers. The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.
I also quite enjoyed perl. There are a lot of us that cut their teeth on perl and know it well, even if we are currently working in other languages. We also tend to de-emphasize it on our resumes for obvious reasons. But if I had a contract opportunity to spend months or years on a large perl codebase, refactoring it or porting it to something else, I'd probably snap it up in a heartbeat.
United States District Court filing system for court cases is written in perl. Horrible language filled with one liners that only makes sense in the mind of the now retired and gone programmers. Sadly, I do not know why we cannot pursue other technologies. Perl is a trap... buyers will be stuck for 30 years. Like a mortgage, but without equity or returns.
You might want to go ahead and inform those investors who bought Amazon or Booking.com stock in the early 2000s that their orders of magnitudes of returns were really no such thing.
I hear Perl has weak typing with implicit type conversion. The only other language I know that has a powerful implicit type conversion system is C++. How does implicit type conversion work in Perl?
Conversion is done based on operator, and Perl has different operators for string and numeric operations. For example, == and eq are different operators, with the former doing numeric equivalence comparison, and the latter doing string equivalence comparison. The implicit conversion done to operands in each case is well defined and obvious.
Edit: Whoops, had operators reversed because I explained them after the fact. Fixed!
An operation may be evaluated in list or scalar context. For example, if you evaluate an array in list context, you get the members of the array, however, in scalar context, you get the number of elements in the array.
This idea is generalized to discuss different evaluation contexts for scalars. You might hear people discussing how a value behaves in boolean or string context. It's also common to talk about casting as "-ification", for example casting something to boolean context is "boolification".
By default, undefined values convert to empty string and 0. However, this can be made to generate a warning or even a fatal exception by setting the appropriate pragmas.
Generally in Modern Perl-style programming, strict and warnings are enabled, so implicit type conversion is not used as much these days. Warnings or errors are emitted.
I've found this greatly increases reliability.
An example is that I enabled those on the W3C checkers and a serious latent bug was discovered and fixed, even on code I wasn't familiar with.
I assume you're saying it's a good thing there's no reasonable protobuf support? The problem is I have access to data I'd like to manipulate, but it's in protobuf, so my options are:
a) somehow convince Google to let me access Nest data through a proper API
b) get a different thermostat
c) magically get the perl protobuf libraries to actually work
d) write just enough protobuf parsing (and possibly generating) to read my data, and curse
e) use another language to parse the data (ugh)
(I guess you could like to throw out 20 years of experience)
Perl 6 is basically a totally different language than any other Perl, and it took a very long time to go from announcement (2000) to release (2015). It was renamed to Raku last year.
Raku's big strengths lie, IMO, in the command line scripting capabilities (the MAIN function), parsing with grammars and powerful new regex syntax, and as a glue language. It's relatively easy to bind to external libraries and work with them.
Slow is in the eye of the beholder. Sure, for some applications, Perl blows Raku out of the water. Add in some Moose, and the situation is not so different. YMMV.
On my 4-core i7 Macbook Pro parsing a 20Mb log file with a regex takes 9.4 times longer with Raku than Perl5. That's unacceptable. Adding Moose to Perl5 reduces the differential to 7.1 which is still huge.
Perl 6 had its first release in December 2015. Since then, it has been renamed to Raku (https://raku.org using the #rakulang tag on social media). It has monthly releases and a weekly blog: https://rakudoweekly.blog
It supports an improved regex syntax, grammars, Unicode NFG (Normalization Form Grapheme, think "\r\n" as a single codepoint), a gradual type system, async execution of code, junctions, event driven execution, set operations...
Mostly the last one. It's included by default with most linuxes and cygwin. So even if your boss hates you and doesn't let you install anything you can still write scripts.
Yeah that too! People keep saying perl is a bad language or something and the other languages can't even get implementing closures right.
I've always liked the references syntax, probably the most complained about feature. Its just pointer thinking. You could probably collapse `$array[$x]->{"foo"}->[0]` to `$array[$x]{"foo"}[0]` and save some keystrokes.
You're right! I always preferred the explicit arrow because it reminded me of C. Dammit now I want to write perl. I miss autovivification so much. Most people hate the pointer syntax and call it unreadable. I think there should be a perl tricks page that lists all these tricks.
Just a little note, Perl 5 actually has (in my opinion) excellent coroutines in the form of the "Coro" module hierarchy. Good enough to run a web service on.
It's not my understanding that the "Perl 7" idea suddenly gives license to be backwards incompatible. Instead, features that have been made available and gated in previous releases can be made default in a new major version.
yes, that's how they are starting off perl7, but the mere fact that it is given a different major version number gives them the social license to break stuff.
This is possibly a stupid comment, but I'd love a modern language whose expected lifetime is 100 years. A language whose specification details how it can be run for 100 years on changing hardware + operating systems, and is built with the least amount of, and easiest to perform, maintenance in mind.
Those languages kind of exist, but not expressly written as such. C will outlive us all.
I haven't used it for anything work related yet, but working with it is mind expanding and makes me a better programmer in whatever environment I work in.
The type system, multiple dispatch, literate programming support, and command line scripting features are simply amazing.
I really hope this bumps Perl back into the niches where it excels. Because there are definitely areas where it is the sharpest and best tool for the job.
Any project that runs on a computer (not a microcontroller) that doesn't need a hardware accelerated multimedia. But even if the later you can always use sdl2.
My last three perl projects (not counting throwaway minor scripts): The control interface of a galvanic vestibular stimulator for VR motion sickness. A GUI for doing the required quirky edits to text files for text to speech smoothness. A comment system for a static website.
Much as people complain about Perl, it is the language which I use when I want to have something which will run 10-20 years from now.
I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time (https://github.com/jwr/ccheck).
Thinking about this some more, I now feel really sad for anyone who doesn't use perl (i.e., almost everyone). Its immense power at the command line is something they'll never experience. Nothing today even comes close.
Even sadder that no-one will probably now start their programming career, as I did, with Perl as their first language. I feel honoured. At the time it was a toss-up between Java, which my house-mate was using every day to write banking apps at work, or Perl - that funky linguistic creation which granted you magical powers. No contest.
I don't understand what you mean exactly – couldn't you use any language, even javascript, exactly the same version as you use right now, in 2100? Why not?
Have you tried? :-) Especially in the JavaScript world, things evolve so quickly, that they become obsolete within single years. If you use node and npm, within months.
To put this in contrast, Perl 5.001 was released on March 13, 1995 — that's more than 25 years ago, and code written in it will largely run fine today.
Interesting, I've been moving away from Perl and Python and towards Rust precisely because I'm afraid of bitrot. Perl the language is stable as fuck and takes back-compat extremely seriously. The problem for me was the library ecosystem: Cpan makes it tedious to pin/vendor dependencies, and installs dependencies globally by default.
You might want to look at Carton and cpanfiles as a way of managing dependencies. You can also get really ancient stuff off BackPAN, should your dependencies disappear from CPAN proper.
Yes, dependencies are a bit of a problem (I tried to use as few as possible in ccheck), but I'd say that the general culture of CPAN is to keep things long-term and prevent breakage, so my experience has been fairly good over the last 25 years. Something I can't say for node.js.
Are they still renaming Perl 6? I think it is a tad confusing to have 5 and 7 being so similar, and the 6 in between so radically different. I can't be the only one.
Ah, I am glad the name change happened. I got side tracked before it came to a conclusion. I'm guessing if it didn't happen then, it surely would have to be changed now because of this new version, which looks like far less of a fork in the road.
I know some people aren't fans of Perl5, but it's what I learned and I wasn't all that excited to have to toss everything I knew (and my reference books) just because of a new version number. If Perl6 turns out to be complementary as people were saying/hoping, maybe Perl7 is where we get to see the interplay.
Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). You can run Perl inside of it if you want to, with the Inline::Perl5 module. Check out the Rakudo Weekly News https://rakudoweekly.blog if you want to stay up-to-date!
These would contain Raku code. But as with Perl, the core developers value backward compatibility much. Since many versions of Raku in use do not know of the new .rakumod extension yet, the old extension is used for many modules still.
It's explained in the announcement. Perl 6 was already renamed to Raku, but calling the new Perl version Perl 6 would be confusing, so they are directly jumping to 7. They even show other examples of version jumps.
What's the best way to do that these days? IRC was the most active Perl place back in the day and the best place to get help, where's the best place for people to ask for help these days?
One can write good Perl, and I've written some. It has saved me and others quite a lot of time on assorted projects.
These days I tend to use Python where once I'd have used Perl. This is mostly because I find that the young are far more likely to know Python than to know Perl. I will be retiring one of these days, after all.
I would add that Perl is still the best for one liners since you don't need to "import" key packages to do basic work e.g. you can regexes in a Perl one liner with no imports.
I'm not anywhere retiring yet, but when Python came around the corner, I thought, well it's as well-suited as Perl for larger things (i.e. not one-liners for text processing - those are a reason for keeping Perl around) but with a cleaner structure.
And that was at a time where you still (occasionally) had to write your own string replacement function that a weirdo company-specific BASIC dialect didn't have.
There's never been a language that I thought of as "Python, but with a cleaner structure", even though Go may be something like "Java 1.2 but with a cleaner structure and a fast toolchain"
I don't think it's necessarily generational. Perl and Python differ in a key regard: Perl went all in on TIMTOWTDI, whereas Python went in the complete opposite direction: enforced whitespace, minimal syntax, strong use of conventions and idioms. (When was the last time you heard somebody inquiring about the Perl-ic way to write something?) As a result, a lot of Perl code is an unreadable mess, and many Python programs are intelligible even to non-programmers. It's hard to overstate what a win this is for Python.
Perl 6 with parrot VM was expecting release in 2004, we had some portion of our code in perl. other portions were in php4. chose ruby due to rails announcement in 2004.
will wait for actual release will try on some pet project
Perl 6 actually got released in December 2015. Meanwhile it got renamed to Raku (https://raku.org using the #rakulang tag on social media). You don't have to wait anymore to be able to use it on a pet, or even a business project. Check out the Rakudo Weekly News if you want to stay up-to-date: https://rakudoweekly.blog
I've had to write some Perl in my latest project. Coming back to a language 20 years later at 37 years old was very interesting. I'm not a fan of the language but I can see why people like it.
The largest issue I've had is that even though the ecosystem gives you the ability to write code resembling best practices, I don't see a lot of Perl programmers that do it. Coming onto a project it didn't make sense to catch a whole team up on 20 years of best practices. So I went about writing code that would never be accepted on most of my other teams.
574 comments
[ 3.0 ms ] story [ 461 ms ] thread> Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year.
Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
Ariba isn't a household name, but it has deep and widespread connections to thousands of the largest companies in the world.
See https://news.ycombinator.com/item?id=23593835
Efficient, cheap and stable. Ported to about everywhere.
Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?
It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.
> Are you saying the language doesn't change much or that it doesn't crash?
Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.
- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.
- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.
Edit: perl is still faster, to be clear
The issue here is that pythons regex engine has overhead, and with lots of sequential calls with small strings like that the overhead adds up.
If you batch lines together in chunks you’ll see a huge improvement in speed, but the point is that it’s not “Python vs Perl” it’s “pythons regex engine vs Perl’s regex engine”. Which is about a contrived Perl-biased benchmark if ever there was one.
Perl5 won the dec2bin benchmark.
The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.
It has even less backcompat problems than the native regex.
That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).
Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.
Perl fares somewhat favorably against Python, Ruby and PHP though. Those are what I would consider equivalent languages to compare against to get a general idea of its speed.
I can pretty much assure you the accumulated dollars invested over the years in making JS fast is likely to be closer to multiple billions combined.
It's also worth noting that three of the examples (pidigits, reverse-complement, fasta) don't seem to do any multiprocessing in Perl whereas they do in Node.js. At least for reverse-complement and fasta, it should be possible to rewrite those to use multithreading (like the Node.js versions do).
Until someone does…
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
For instance, the page you linked has “pidigits” at the top, and says node is faster, 2.58s vs 3.61.
2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.
The perl page lists a 1.24 second run for “pidigits 2”.
The reported numbers in the language comparisons don’t seem to be averages.
All the pidigits programs list the same output, so presumably, they’re running with the same ‘N’.
Between the variance and inexplicable stats being applied to the results, I’m not sure what to conclude from these numbers.
No, there really isn't.
> 2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.
Notice column N — 2,000 6,000 10,000.
That's a command line argument passed to each program, controlling how many digits of pi are generated — the workload.
So, 2.58s for 10,000 digits and 1.04s for 6,000.
(And as it says, there can be a cold caches effect on the first measurements.)
You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way.
So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.
Demand in this case, will likely create its own supply.
We shouldn't really be treating software differently. The liability for a mission critical system that works but cannot be repaired climbs over time.
Just because it works doesn't mean it isn't broken.
Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.
And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon.
That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point.
My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned).
Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.
New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is.
I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.
Those are all pretty basic Algol-family languages (at least if we're talking vaguely modern Javascript). If you were thrown in to J or Forth or Erlang you might have a different experience.
I don't know if I'd necessarily call the JS in question "modern", though. It's running on RhinoScript, which needless to say ain't exactly the latest hotness. Still, the platform in question does happen to support/encourage AMD modules (with some special comments for certain components), so I guess it could be worse.
Now that I think about it, that's actually a decent hiring test:
Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them.
It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.
Perl is everywhere, it's just not widely publicised because of the stigma attached to the language.
https://metacpan.org/pod/Mason (if you're not familiar with Mason)
Most of the ad network backend sites are perl, including a lot of Yahoo.
The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste.
They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.
Nothing against the language but I don't know why you wouldn't use literally anything else nowadays. Python or PHP, JavaScript or even Ruby if you're looking for a dynamically typed language. AWS don't even support Perl.
To quote myself from a recent discussion:
I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability.
For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.
1. You can use virtually any language to write clean code
Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really nearly impossible to write good code in.
2. Perl lends itself to unreadable code
If you stick to Modern Perl you still might end up with things like `wantarray` in your code so I guess this is kind of true. You need to be judicious in your use of code.
Some languages lend themselves more easily to writing clean code, like I feel about Go or if you hate the Go type system, Ruby. Even in Ruby I feel like metaprogramming is ripe for misuse.
It's a tough thing to talk about. I don't feel like I wholeheartedly disagree with your sentiment which seems to be "some languages lend themselves to bad code" and subsequently that Perl lends itself to bad code but there is plenty of ambiguity in these thoughts.
I used it for automation of my calculations in grad school. For data analysis. For monitoring.
In my subsequent day jobs, I used it to develop shipping products. No one really should care what language something is written in, if it does the job well.
Most recently (a few weeks ago), I used it as the driver for creating and submitted 10's of thousands of jobs for COVID19 research the team I am working with[1][2].
For the above project, I had to forward port 12 year old C++ code to make use of modern C++ based boost libraries. Took a bit of time to fix this. But the perl code, ran perfectly, and quickly[3].
Anyone trying to portray things otherwise, likely has a longstanding axe they like to grind. Language advocacy can be done without attempting to tear down other languages. Though those who argue against perl often bring up the same, old, tired, and incorrect points.
I'll keep using perl thank you. And Julia. And C. Each has their domain of applicability. Most people know and understand this.
[1] https://community.hpe.com/t5/advantage-ex/how-my-supercomput...
[2] https://community.hpe.com/t5/advantage-ex/the-story-of-how-i...
[3] https://scalability.org/2020/04/fun-and-topical-hpc-project-...
The system is from like 2013 and still going, but I really wish I could rewrite it in a language I can actually train people on in a reasonable amount of time. It took the one junior I have about 6 months to get to the point where he could read the syntax without tearing his hair out. It's not really built to create maintainable structures.
The libraries and stuff are full of opinionated little "gotchas." As an example, the Test::Simple module will throw errors if you use a number to title a test which is infuriating when you're writing a test which tests all the numbers in the space of acceptable or possible inputs.
Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar.
Compared to Python for example where you'd literally just pass the array to the method like method(array).
How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?
In Perl, that's the difference between foo(@bar) and foo(\@bar) or foo(1, 2, 3) vs foo([1, 2, 3]).
With an asterisk: method(*array)
How is that more understandable than @ vs \@ without knowing the language? My guess is it isn't.
But the more important bit is just that you don't have to prefix variables with @ and $. Python is optimized for writing code that acts on variables, while perl is optimized for code that acts on strings. While strings are certainly a common data type, most code isn't modifying strings directly. So optimizing for that case doesn't make a lot of sense.
def f(b):
f(a)f(*a)
The values in @_ are aliased to the values in the subroutine call.
Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.
However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.
Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:
Making signatures default will be a big improvement, but the power of the simple abstraction @_ provides should not be underestimated. It's actually an elegant solution to a complex problem.Since Perl code is often very compact, it probably needs a higher comment to code ratio than most other languages, but you don't see that either.
That is true. This alone might be a good reason to look elsewhere for new projects.
However, for existing Perl codebases, PAWS is comprehensive and popular library, and is generated from the official botocore: https://github.com/pplu/aws-sdk-perl
Also, CPAN had better libraries than pip did all the way up until I last used Perl in 2015. Ofc, it depends on what you're doing. My point is, there was a reason to use Perl once upon a time ago.
The alternatives back then were PHP, C, C++ (the old bad kind), BASIC, assembly, FORTRAN, and others like Smalltalk. Seeing this, it's understandable why Java took the world by storm the same way Perl did.
There's 194,000 modules, which is probably the most of any language:
https://www.cpan.org/
> Nothing against the language but I don't know why you wouldn't use literally anything else nowadays.
Gee, let me see:
- Perl's Mojolicious web framework is probably the most powerful today.
https://mojolicious.org/
- Perl has moderate static typing with use strict;
- Perl allows forward references, unlike Javascript or Python.
The question is why would I use anything but Perl?
Anecdote: I found this Perl image-hosting package a couple years ago as a self-hosted alternative to sites like Imgur, and I think it's great: https://framagit.org/fiat-tux/hat-softwares/lutim/tree/maste...
https://marc.info/?l=openbsd-misc&m=159041121804486&w=2
My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).
It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.
> The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.
[0] - https://github.com/OTRS/otrs
[1] - https://otrs.com/
Yes, you can call them open core now. But still many companies are using the community edition and are served well by it.
I worked closely with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl!
I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved...
Also, the technical founder started https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby!
Modern perl5 is ok. But the ecosystem is slowly deteriorating.
I'd imagine a bigger rewrite effort would have led to a more slick iteration on the UI, and it seems the legacy HTML templates are still baked in.
IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.
Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again:
I don't write software as an end goal, I write software to accomplish my end goal.
Perl is not bad but no new codebases should ever be written in it imo. It's to easy to shoot yourself in the foot unless you know perl REALLY well. Moose is ok but a far-cry from any modern OOP system.
Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today.
My own github[1] has a plethora of perl projects.
[1] https://github.com/joelandman
I still think Perl is a much better tool for what some bash and python scripts are doing. Maybe Perl7 will remove some stigma and allow for people to use the tool instead of it being instantly dismissed.
I considered Perl, since it was the only scripting language interpreter, but the good enough (on paper) date handling libraries I found on CPAN turned out to require a far newer Perl 5 version that was available.
I'm afraid that the best-case Perl solution would have been more difficult to write than the roundabout but reliable and easy to understand final solution (Oracle SQL functions executed through the command-line SQL*Plus client).
Back in 2002 I had to choose between learning between Python and Perl for a project, but "everybody knew" Perl 5 was soon going to be replaced by a new shiny different Perl 6, so I chose Python.
It will be interesting to see where Perl can live and gain new users nowadays. Python has so much become the "default scripting language", and has so many bindings and libraries.
> This beloved guide is now completely updated for Perl 5.22.
I've been working with Perl since about 5.20 and am on 5.31 or 5.32 and haven't noticed many breaking changes FWIW.
https://en.wikipedia.org/wiki/Osborne_effect
:D
I got my start with Perl; I wrote a book about it, I spoke at every conference, I did training, I maintained the Emacs mode. I started working at Google and, forced to use static languages, found them to be just as productive as Perl. And, they eliminated a lot of problems with Perl -- libraries were resolved at compile-time, and I just ended up with a binary that could be run anywhere (no @INC madness); types were checked at compile-time, so silly errors that required extensive unit testing in Perl could just be automatically underlined by my editor and fixed before I even saved the file.
Something else that bothered me was how much mindshare the dynamic languages were competing for among themselves. I would prefer to write a Perl program over a Java program any day... but Perl did not seem to be fighting with the Javas and C++s of the world, instead it was always trying to take on Python and Ruby. And Python and Ruby were like that too -- every Ruby programmer was out to kill Perl because they didn't like Matt's Script Archive. (Nobody wrote 1990s Perl in the 2000s, so it was kind of a strawman.) You ended up with a bunch of like-minded people fighting for the small attention share of "we don't really care about runtime performance", and all the factions were just too small to take on the larger issue of entrenched static languages. Java and C++ never felt like they had to take features or ideas for Perl, Python, or Ruby. So it all seemed kind of pointless.
With all that in mind, I do think Perl failed to "win". It is a neat programming language, but probably too complicated for beginners and not productive enough for people that have gotten comfy with C++/Java/Go, which are pretty darn productive these days. Meanwhile, Python found its niche pretty much everywhere -- you can program microcontrollers with it, you can write a video sharing website with it, you can do data science with it -- and it's a great introduction to programming for beginners. And, Javascript kind of came out of nowhere to conclusively "win" the dynamic language war (because a dynamic language needs a runtime, and guess what runtime exists on pretty much every computer and phone around these days?)
TL;DR: I kind of agree that the programming language wars have been fought and lost by Perl. That doesn't stop people from wanting to make it better, or to continue to use what they know. You can make lots of great things with it, so people continue to use and improve it.
On some level, everything is like that. Perl was a better awk/grep and was successful in replacing those tools. Then one day, someone decided to use it for CGI, and it got a huge popularity boost. But the people that decided to use it for CGI could have easily used something else, and it would have probably worked fine and Perl never would have been popular. It was just random chance that they picked Perl and made it popular. I feel like everything works that way. Javascript is popular for web UIs because someone decided to add it to a popular web browser. There is always some intrinsic randomness that plays a part in gaining mindshare. A bad tool with a good mindshare can do well, and a great tool with no boost can languish in obscurity. Perl benefited a lot from luck, but rolling the dice doesn't last forever.
Niecza focused on producing a Perl 6 on the .Net infrastructure. Rakudo is based on NQP (Not Quite Perl) and initially ran on Parrot, then also added the JVM as a backend, and then later added MoarVM as a backend.
Niecza sadly stopped being developed as its main developer developer decided it wouldn't be able to come to a full release (around 2012/2013).
So to say that "about 3 implemetations of Perl6 in development simultaneously" is incorrect, and then to name MoarVM, JVM and Rakudo as the three is even more incorrect.
Perl 6 got renamed to Raku in 2019. Since the first release in December 2015, it has become about two orders of magnitude faster.
You can check out the Rakudo Weekly News should you wish to stay up-to-date on developments in the Rakudo world: https://rakudoweekly.blog
https://en.wikipedia.org/wiki/Osborne_effect
And I guess Perl also never had its Django (or Rails).
It’s got two of them - Catalyst (older still works fine) and Mojo - newer and shinier.
I think python is a better fit for mathematical work. I like to say that python helps you think more like the computer does, and that perl helps the computer think more like you.
Probably because Python resembles pseudo-code.
Anecdotally I've heard from a few people who said Python was the first language where ideas just made sense to them. An "easy to learn" language, in other words.
(I can't relate to that and don't know why Python is thought of that way. As far as I can tell, beneath the syntax (which is prettier than Perl), Python is a messy language with even messier standard library.)
It is flexible and fun and I do miss it.
True story: years of passing functions to other functions and map/greps made the switch to FP Scala (another language I fear will die) a lot easier!
> I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented.
Perl first, then JavaScript.
Did you know JavaScript classes are blessed hashes?
They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
Old JavaScript made the blessing crude and obvious.
Modern JavaScript lets you hide it in a "class" decleration. Which you can also do in Perl if you want (though you'll need to choose a module for this, and people generally prefer a different approach to dressing up objects in Perl.)
There's still a blessed hash under the hood which you can see and kind of have to be aware of... in both languages.
IMO, that's why both languages have been able to be extended and adapt so much.
If you look at tools like Moo and Moose in Perl and the different coding paradigms that evolved in JS before the "class" keyword was standardized, this is pretty clearly evident.
JS has had the advantage of a standards committee pushing new language features aggressively. Perl has moved more slowly, keeping a majority of functionality in libraries.
> They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
omg, I totally forgot that (I left day-to-day JS use a good decade ago, sorry!).
I especially like the sigils - they serve in a way as a primitive type system and actually convey useful information when reading code. I suspect people who complain about them are the same who dislike strong typing.
Interestingly, like you, nowadays I am very fond of Scala.
And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.
$| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0.
In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.
Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.
https://perldoc.perl.org/perlvar.html#SPECIAL-VARIABLES
(for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)
"There’s more than one way to do it, but sometimes consistency is not a bad thing either."
If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.
Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn.
If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of older, 'worse' things.
Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.
Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)
When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.
For this particular case, I'm not sure what drove the selection, but I would guess (since the decision would have been made many decades ago!) it was probably based around perl trying to operate similarly to other command line tools of that era, like awk, sed, (or even ed?), so that people could switch to perl and have a familiar environment? But I don't know, nor have I researched it. In any case, perhaps give the designers the benefit of the doubt before assuming their incompetence?
This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.
So you can absolutely stop people from using $|
The point of Perl 7 is to have sane defaults.
You mean like string instrument tab coloured by finger instead of sheet music? Yes, exactly like that.
Restrict scale to pentatonic even for professionals (remove physical keys, holes etc). They would absolutely mess up otherwise.
Yes. Yes I can[1]
[1]: https://how-to-play-electric-guitar.net/tab-symbols.html
The problem isn't merely that notation is easy/hard, but that people will not only pass judgement about a language (or any other idea), they will also work actively to convince others to agree with them, and oh yeah, that programmers are people too.
Are we really?
Yes, of course I can: https://en.wikipedia.org/wiki/Simplified_music_notation and from the linked website "is designed for learners in general".
> "worse, that he/she expects the language to be dumbed down to make it easier to learn."
And why should "simplify" have the connotation "dumbed down, for dumb people"? Everyone benefits from simpler things with fewer warts and fewer hazards.
"If hard-to-read-and-remember syntax exists, people WILL use it"
This statement doesn't appear to hold up under scrutiny.
Not with the sigil names, are they?
Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.
>This statement doesn't appear to hold up under scrutiny.
What scrutiny? I don't see any scrutiny. You just said that, without scrutinizing.
Just like every human language that ever existed. And last time I checked, programming languages aren't used or written by AI's or aliens.
[0] https://stackoverflow.com/questions/26127617/what-exactly-ar...
In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.
> utterly confounding the first time one accidentally runs into it.
Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.
edit:
BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)
Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)
Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.
The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose.
Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)
(The first version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)
My limited experience with Swift suggests that even 25 hours ago could be a tall order...
A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.
Windows NT was released in July, 1993. Almost exactly two years before Windows 95.
In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)
My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.
I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.
Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.
It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.
Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.
I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.
That's not true since v5.10 (2007). Here's a sample that matches a subset of LaTeX markup:
It's nowhere near as advanced as Raku grammars (not much is), but it's there, and it's built-in.Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.
There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).
I only used Ruby briefly over 20 years ago so I can't comment.
I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
http://web.archive.org/web/20160308115653/http://peope.net/o...
I mean, you can do it, it just lacks elegance. And TBH, I still prefer C for lots of things.
But even though it has a similar powerful set of operations for regular expressions, people mostly don't use it, because there are better ways to deal with text.
https://en.wikipedia.org/wiki/Pugs_(programming)
That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.
The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:
I firmly believe that context is one of the worst ideas in Perl. There is a good reason why it was not borrowed by other languages. It is far better to expand arrays like Ruby does with * instead.That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing.
That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).
Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.
Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.
Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.
Yes, the memory isolation model of mod_php was the crucial factor in beating the competition. With mod_perl you had to write your Perl modules to a specification so that globals were not accessible by other hosts. That was too much of a risk for shared hosting providers. The situation is muddied, however, in that a lot of shared hosts only allow PHP as a cgi which, in theory, puts it on a level playing-field with Perl. However, in practice, Perl only has one PHP-alike templating framework - HTML::Mason - and that requires mod_perl to perform decently. So PHP's other advantage is that its templating engine is simply faster.
Python 1.2 was released in 1995.
The first public release of Java as 1.0 was in 1996.
JavaScript appeared in 1995 as well, but the first ECMAScript standard didn't appear until 1997.
First release of PHP was in 1995, same with Ruby.
Perl pre-dates the initial release of all those languages and was already up to its fifth major version by that time.
Up to you to decide when you think it started, but I'd say the current language we think of as "Perl" started with the release of Perl 5.
Today, objects are used heavily. And furthermore the way we write those classes has changed a lot since Moose and friends became popular. As a result most Perl code bases written in the last dozen years look less like early Perl 5 than early Perl 5 looked like Perl 4.
Perl 4 and Perl 5 are more of a continuum than different languages.
Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)
I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as I wrote a map rendering system in Javascript back in school in 2005.)
Node came out in 2009, and writing server-side JS was still a fringe practice for a couple more years, so 2010 is me being generous to avoid comments on the exact timeline ;) It really picked up mainstream adoption around 2011-2012.
It died a noble, honorable death. RIP.
How much production software is started from scratch every day using the language?
I started my career in Perl and I still have fond memories of working with it up to late 2000's, but by that time the writing was solidly on the wall.
Dead in this context means "niche".
I would agree, but I don't think you meant it the same way I would: I prefer nice cold sheets when I sleep, and I much prefer Tcl to Perl!
Edit: Whoops, had operators reversed because I explained them after the fact. Fixed!
An operation may be evaluated in list or scalar context. For example, if you evaluate an array in list context, you get the members of the array, however, in scalar context, you get the number of elements in the array.
This idea is generalized to discuss different evaluation contexts for scalars. You might hear people discussing how a value behaves in boolean or string context. It's also common to talk about casting as "-ification", for example casting something to boolean context is "boolification".
By default, undefined values convert to empty string and 0. However, this can be made to generate a warning or even a fatal exception by setting the appropriate pragmas.
I've found this greatly increases reliability.
An example is that I enabled those on the W3C checkers and a serious latent bug was discovered and fixed, even on code I wasn't familiar with.
Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?
The only thing I've noticed that's lacking is decent protobuf support.
a) somehow convince Google to let me access Nest data through a proper API
b) get a different thermostat
c) magically get the perl protobuf libraries to actually work
d) write just enough protobuf parsing (and possibly generating) to read my data, and curse
e) use another language to parse the data (ugh)
(I guess you could like to throw out 20 years of experience)
Look at how easily raku binds to a python charting module in this article: https://www.perl.com/article/plotting-with-perl-6/
It supports an improved regex syntax, grammars, Unicode NFG (Normalization Form Grapheme, think "\r\n" as a single codepoint), a gradual type system, async execution of code, junctions, event driven execution, set operations...
Hope this was short enough.
* Compatibility
* Quality
* Usability
* Scalability
* Availability
https://pragprog.com/titles/swperl/
1. Improve threads
2. Improve C API support
3. Give local::lib, cpanm by default ... multiple perl versions by default
4. Give direct support for coroutines / async await
5. Mark experimental features as non-experimental (attributes, signatures)
6. Pick an OO system, package system
7. Make switch cool again
8. Get more core modules or remove some. Give more visibility to cool perl modules. like PDL or something.
9. Improve GUI toolkit, Web Deployment and Web Assembly support
10. Improve look and feel of community sites
Heck break some backwards compatibility with Perl4, get rid of format.
I've always liked the references syntax, probably the most complained about feature. Its just pointer thinking. You could probably collapse `$array[$x]->{"foo"}->[0]` to `$array[$x]{"foo"}[0]` and save some keystrokes.
Yup, one's been able to collapse exactly like that for more than twenty years.
https://metacpan.org/source/LWALL/perl5.002b3/pod/perlref.po...
That's from 5.002, from last century, and it wasn't introduced on 5.002.
Beginning from v5.20, one's also been able to use the postfix dereference syntax, turning:
say join "\t", @{ $foo->{bar}[0]{quux} }
into:
say join "\t", $foo->{bar}[0]{quux}->@*;
Whether that's better or worse, it's debatable.
You shut your mouth. I can't even count th number of my scripts that'd break. I like format for output.
Those languages kind of exist, but not expressly written as such. C will outlive us all.
sub foolTwice() { return perl5(); }
I haven't used it for anything work related yet, but working with it is mind expanding and makes me a better programmer in whatever environment I work in.
The type system, multiple dispatch, literate programming support, and command line scripting features are simply amazing.
I really hope this bumps Perl back into the niches where it excels. Because there are definitely areas where it is the sharpest and best tool for the job.
My last three perl projects (not counting throwaway minor scripts): The control interface of a galvanic vestibular stimulator for VR motion sickness. A GUI for doing the required quirky edits to text files for text to speech smoothness. A comment system for a static website.
I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time (https://github.com/jwr/ccheck).
Very happy to see a path forward for Perl 5.32.
Edit: nice tool, by the way!
To put this in contrast, Perl 5.001 was released on March 13, 1995 — that's more than 25 years ago, and code written in it will largely run fine today.
https://metacpan.org/pod/Carton#Tracking-the-dependencies
http://backpan.perl.org/authors/id/
I know some people aren't fans of Perl5, but it's what I learned and I wasn't all that excited to have to toss everything I knew (and my reference books) just because of a new version number. If Perl6 turns out to be complementary as people were saying/hoping, maybe Perl7 is where we get to see the interplay.
This is probably going to change in the next language revision of Raku. See https://github.com/Raku/problem-solving/blob/master/solution... for the nitty gritty.
If your Perl is old-school, that's OK. Use Perl 5 and we'll keeping supporting you.
If you your Perl isn't old-school, use Perl 7 and get new features.
If you're not sure, ask us and we'll hold your hand to help you understand.
We're here to make sure you're OK.
What's the best way to do that these days? IRC was the most active Perl place back in the day and the best place to get help, where's the best place for people to ask for help these days?
One can write bad Perl, and I've written a lot.
One can write good Perl, and I've written some. It has saved me and others quite a lot of time on assorted projects.
These days I tend to use Python where once I'd have used Perl. This is mostly because I find that the young are far more likely to know Python than to know Perl. I will be retiring one of these days, after all.
I would add that Perl is still the best for one liners since you don't need to "import" key packages to do basic work e.g. you can regexes in a Perl one liner with no imports.
And that was at a time where you still (occasionally) had to write your own string replacement function that a weirdo company-specific BASIC dialect didn't have.
There's never been a language that I thought of as "Python, but with a cleaner structure", even though Go may be something like "Java 1.2 but with a cleaner structure and a fast toolchain"
will wait for actual release will try on some pet project
The largest issue I've had is that even though the ecosystem gives you the ability to write code resembling best practices, I don't see a lot of Perl programmers that do it. Coming onto a project it didn't make sense to catch a whole team up on 20 years of best practices. So I went about writing code that would never be accepted on most of my other teams.