On the Decline of Perl – external factors
nntp.perl.org
nntp.perl.org
Why did that happen? In my opinion, PHP had two major advantages over Perl:
1. mod_php for Apache could safely be run in a shared hosting environment, so hosting for PHP was cheap and ubiquitous. mod_perl couldn’t be run in shared hosting, so anyone doing web development in Perl was stuck with either using CGI, or paying for more expensive dedicated hosting.
2. PHP’s approach made it easier to get started for people who were new to web development, or new to programming entirely. This was important in the late 90s and early 2000s as a huge number of people started doing web development for the first time.
By 2000, PHP was already the dominant “scripting language for the web”. If the Perl community had focused on improving web development, then maybe Perl could have caught up, but they focused on Perl 6 instead, and PHP continued its growth without much serious competition from Perl for web development mindshare. MediaWiki was written in PHP in 2002, and both Facebook and Wordpress were written in PHP in 2003.
The article focuses on Python, but during the relevant time period (roughly 1995-2005) Python was a niche and unorthodox choice for web development. Python finally started to gain traction for web dev in 2005 (Django, Pylons, TurboGears, and web.py were all released that year), but by that point Python was mostly competing with PHP, and Perl was already much less relevant.
In summary - the article focuses on how Perl lost the market for scripting, but scripting was always a smaller and less important market than web development, and PHP killed Perl in the web development market. If Perl had stayed relevant for web development, it likely would have stayed relevant in scripting as well, because programmers like to use languages they already know (see: JavaScript). Perl 6 was the nail in the coffin that ensured Perl wouldn’t catch up in the web dev race that it was already losing.
The most interesting counterfactual is “What if someone had written something like Rails for Perl before 2005?” It was definitely technically possible, and it might have made Perl take back off (Ruby usage grew from basically nothing due to Rails), but the community’s focus on Perl 6 at the time made it much less likely.
Catalyst was released in 2005 (so still after Rails), and definitely didn’t provide Rails-like productivity.
If Mojolicious had been available in ~2003 or earlier, it’s entirely possible Ruby never takes off, because developers could get similar productivity in a more “known”/“mainstream” language.
Even today PHP still has that advantage over many other languages. To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go.
That being said these days the other languages become their own http server and are usually fronted by a reverse proxy or two. But still that is like an order of magnitude harder to stand up than PHP.
With some juggling of what the script that was the .cgi, it would have been trivial to make it launch Java and consume the data... but Java wasn't set up for that (and the startup times for a Java cgi would have been nightmarish).
Doesn't that just depend on Apache settings? You can set up Apache to serve all requests ending in .py as CGI. As long as these scripts emit HTML the situation is the same as PHP.
* Read a file containing an integer
* Increment the integer in memory
* Emit a .gif with the new value
* Write the new value back to the file
There is a huge window while emitting the .gif during which other visitors may appear. At best a new visitor appearing during another visitor's "emit gif" phase does not increment the counter, at worst a visitor on a very slow line causes the cgi instance for this visitor to run for a long time and then write back a very old value to the file, making the counter run backwards.
For things that matter, the counter reading+increasing should be an atomic read-modify-write. But since this is just a web counter, I guess it's sufficient if you at least keep the hazardous window very small (by not doing the write-back at the end).
"A widely shared myth" would be more accurate.
By the way, I'm totally aware that those counters didn't matter, but I thought it's worth discussing anyway. Someone might read this and apply it to things that matter.
Chmod'ing over FTP isn't straight forward in most clients, so it was much more complicated for beginners to get things to run than "upload those files, go to your browser".
https://thenewstack.io/php-creator-rasmus-lerdorf-shares-les...
I think he thought it would be Perl:
"And Lerdorf tells an only-in-the-1990s story about the day when Perl finally also released its own optional embeddable module for Apache web servers — mod_perl. “They’d made it way too powerful… If you were on the virtual host on an Apache server, and you had mod_perl access, you could steal the requests from every other virtual host if you wanted to…” Because of this vulnerability, ISPs wouldn’t offer mod_perl alongside other clients in a single Apache instance.
“So if you came to an ISP and said ‘I would like mod_perl‘, they would say, ‘Okay, that’ll be $600 a month,’ because back then, we also didn’t have VMs, containers, anything like that. So you had to have a separate, physical bare metal box for mod_perl. Whereas on PHP, you could put 3,000 customers on one machine, versus one mod_perl customer.”
the 25 year php talk: https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s
Even if one could convince themself mod_php was safe, it was so unstable version-wise syntactically and every webapp wanted its own snowflake combination of version and configuration and versions of dependencies like imagemagick/gd, it was simply impossible to satisfy all customers on a given host sharing a single apache+mod_php instance.
By the time I left that role we had what must have been nearly 100 different php cgi builds in a global repository maintained on behalf of customers. Whenever a vulnerability came out we'd have to go revisit all these snowflakes and push fixes out. At least the pushing out was mostly automated since we had all the hashes, but the maintaining of the variously configured source trees and backporting of fixes was always a largely manual nuisance. In retrospect we spoiled our customers, and I learned PHP was a damn disaster area.
At one point we forced all customers to migrate IIRC from php3 to php4 and in that transition we learned the previous version was ignoring such glaring syntactic problems as mismatched curly braces ambiguously delimiting blocks of code. What a nightmare that week was, before that we could largely ignore the contents of customers' scripts. But with so much broken we had to start looking at what they were doing and automating counting of open vs. close curly braces in php scripts across the fleet. What a horror show.
Edit: forgot to mention shared hosting providers generally relied on suexec which only works w/cgi processes anyways. Nobody in the shared webhosting space cared about the subtle differences of mod_php vs. mod_perl, they were both irrelevant to anyone trying to isolate web customers sharing a single host.
Internally the Perl community fought with each other over how to implement OO. A Meta Object Protocal (MOP) was hotly debtated but the main implementation remained just a library. Likewise with Perl's main OO library Moose which spawned lightweight offspring such as Moo. TIMTOWTDI became a liability as competing scripting languages with built-in OOP (Ruby, Python & PHP5) ate Perl's lunch.
Perl also lost a lot of mindshare to Python in the an area it had dominated for many years - system administration.
Catalyst (released 2005), Mojolicious (2008), and Dancer (2009) were all released too late to matter.
PHP's documentation was always excellent, available and was always a quick Google search away from finding the relevant materials. It was tangibly superior at the time.
Coding with other languages at the time always involved some kind of physical reference book (or some closed off "compiled" walled "context sensitive" help system whose search capability and discoverability was little-to-none).
Although I had sooo many O'Reilly reference books, I don't think I ever had an O'Reilly PHP reference book... (Not sure there ever even was one because it would be totally unnecessary)
Think how brittle limited and fuzzy php was for so long, yet it's a major thing in IT now.
At launch Google Sheets was worse than Excel in so many ways, but the online collaboration made it 10x better for all but the most specialized users.
Imagine how different things would be in the alternate reality where the server-side JavaScript support of Netscape Server morphed into a mod_javascript module for Apache.
The launch in fanfare of Perl6 in 2000 had a general chilling effect on Perl: many people considered from that point that there was no point learning and using Perl 5, because Perl6 was "just around the corner" and was "the future of perl".
It's just last year that people finally came to their mind : Perl6 became Raku and is a different language, period. And Perl 5 is supposed to get out of its 20-years of maintenance cycle by becoming perl 7 and changing some defaults it should have done back in 2007 or so...
Well. That's life.
People dont choose Perl because it's too flexible in how to do things ie what is idiomatic in Perl...well it depends on how well you know Perl. This hurts readability and adoption. It also has warts like any other language but thats hard to detect when reading code is an issue.
The best parts of Perl have already been adopted by other languages. No reason to use Perl that I can see.
Edit: the Python REPL approach was also much better for debugging scripts than how I had to do things in Perl.
The one thing that stood out to me, was what happened when I had to show somebody else what a script did. (I was always showing somebody with some programming experience, but not always with the matching language).
It didn't matter what language they had experience with, Python was always easy to walk them through the code. I know this sounds scary to most, but when you are low on people and even lower on resources, you do what you can.
When I needed to explain Perl to somebody without Perl experience, the eyes would glaze over as soon as @ and $ and % characters started showing up (re: immediately).
It's not that Perl isn't a great or powerful language. It is. I use Perl style regex almost every day. Perl taught me hashmaps.
But Python code looks familiar to a lot more people. No mystery symbols. No needing to explain that the @ symbol is an array, except when reading from it. Then you use $.
When I explain Python code to someone who doesn't know Python, they ask me about the actual code. Why I made certain decisions regarding the design or functionality.
When I explain Perl code to someone who doesn't know Perl, they tell me it looks like gibberish.
I had a very brief experience with Perl in school around 2001-ish.
All those concepts you brought up made me never want to touch it again. The language just comes across as a tool made out of necessity in the 1980s / 1990s, but then better tools came around.
But, more importantly, I will never apply for a job that lists Perl. It's just a relic from the past.
Good. More Perl jobs for me then. Although I kind of got bored with Perl and would probably enjoy coding in Ruby or D or even Crystal.
The bigger issue is avoiding jobs where the management chose an "impossible" stack. IE, a stack where the technology choices actively impede productivity.
Unless the job basically involves modernizing something that's been around for a few decades, why would anyone do new development in an outdated language?
So it could have been the language, but it could have been the culture too.
Please stop the ^$%@#$%#@^@$%^&( nonsense, Perl hackers. That's not flexibility, it's childish bravado. Write code that people can read. If some of that precious "flexibility" is lost in the process, that's a net gain actually.
Perl is stuffed with unforced errors like this. Lack of named parameters! Reading from filehandles by putting angle brackets around them! Filehandles being a distinct type from scalars! Hashes and arrays not being usable in the same way scalars are (can't put them inside an array or a hash, have to use a reference)! Even at the time, this stuff was distinctively bad. I wrote loads of Perl in the late '90s, and as soon as Python became viable, i leapt at it, because the language was so much simpler and more uniform.
All this is particularly wild considered in the light of the fact that awk, an explicit precursor to Perl, has a significantly simpler syntax. How did Larry Wall look at awk and think "i know, what i need to do is take out the named parameters, and add some more sigils!".
I do wonder if, it hadn't been for Perl, there might have been room for awk to grow into something more general. Probably not. But i don't see any technical reason why not.
However, named parameters have been a thing for ages. It's extremely common to call functions using an anonymous hash like so:
$sock = IO::Socket::INET->new(PeerAddr => 'www.perl.org',
PeerPort => 'http(80)',
Proto => 'tcp'); sub double($value) {
return $value * 2;
}
sub double {
my $value = shift(@_);
return $value * 2;
}
Perl does not have pass by reference, you have to use pointers if you want to do it. It will even go so far as to duplicate an entire array or hash you pass to a function, which can surprise novice Perl programmers when they build a giant data structure and start passing it around only to discover their program running slowly. Or worse, finding their changes to the structure being undone when the function exits.
Nope, just parameter declarations. I also kind of doubt the by-value semantics will surprise anyone the way you describe: If you pass things by value without explicitly taking a reference, the structure (arrays and hashes, specifically) will be flattened into the argument list. If you're unaware of this, things will probably go wrong long before you've had time to be surprised by stuff getting copied...
I learned Perl first and used it professionally for a number of years but switched to PHP and Python more or less for this reason. Perl had a great package manager, performed well, etc. but no matter whose code it was, it required more work to read code and even seasoned developers would waste time on bugs which turned out to be some magic syntax quirk which was too easy to miss. perltidy helped a lot but why not start with a language where many of these problems can't exist?
The other big reason was error handling: Python's reliance on exceptions is a huge win for stability & avoiding certain security bugs. Perl code was harder to read with all of those return code checks and even seasoned developers would mess up more complex scenarios.
For that reason I always disliked Perl, quite strongly, and from the beginning (I've first seen it in the '90s).
Bad, naive language design, that's all. The prevalence of Python nowadays is a sign of maturity.
The only place really shines comparatively is in CLI one-liners. But even there, awk is usually a better tool.
Perl's built-in OO, without Moose, works fine, and isn't substantially different from python's.
What is different is that "everything is an object" in python. That's not true for Perl. So Perl OO is a bit saddled with references (pointer like things) and sigils ($this, @that, %theother) and therefore intimidating looking data structures, dereferencing, etc. To me, that's what makes OO Perl painful. To be fair, it's also one reason why Perl is often a lot faster than Python...basic types don't have the same amount of overhead.
Personally, I love Perl and still use it often. But I can see why Python sucked away the user base.
However I also found Perl’s OO to be painful. I’d call it a cruel joke. I could never comfortably wrap my head around its implementation because it always felt like a horrible kludge on top of the module system. Is it a module? Is it a class? Is it an object? Are they normal functions? Are they class methods? Or are they member methods? The answer to all for these questions is a resounding yes! TIMTOWTDI bites us once again.
Perl is great for its primary use case of being the thinking person’s BASH, and it has the greatest regexp and stdio support for any language I’ve used, but I wouldn’t build anything OO with it.
As for wrapping your head around Perl OO, really it's just bless(). Bless($thing,'namespace') says "this $thing is an object, in this namespace". You can make an object without adding a namespace beyond the default main namespace...
Like:
sub test {print "whee\n";}
my $foo={};
bless($foo,'main');
$foo->test();
So OO in Perl is just mapping a namespace to a blessed reference via bless($ref,'namespace'). Then $ref->call($arg) runs the "namespace::call" sub, but as if you did namespace::call($ref,$arg).
I think lack of syntactic support for nested data structures comes from its origin as a better bash script.
It doesn't seem right to ignore the increased popularity of better and more user-friendly interpreted languages such as python, which has since became ubiquitous even in spite of the python2-python3 transition.
Also, there was the inception of node, which brought javascript front and center.
In fact, among the interpreted languages that were popular 20 years ago, which ones besides python still hold some relevance?
Perl, whether v5 or v6, can't exactly compete with javascript or python in terms of ubiquity and user-friendlyness.
If Perl's learning experience is harsher, and in the end there's less demand and job prospects, why would anyone pick Perl over any alternative?
That said, I did pick up PHP and Laravel out of curiosity. It truly is nothing like the PHP I learned in 2001.
e: a word
I’ve also seen a lot of job postings in that field. Seems like Laravel has a substantial following in the way that Rails does.
It's more remarkable that Python is still relevant, which is a testimony to the overall quality of its design and its usefulness in a large number of different areas. Had Python been only a web scripting language, it would have been eclipsed by PHP just like Perl.
Are you basing this claim on something like not having a special literal syntax? Python has had regular expression support for ages and it works quite well: https://docs.python.org/3/library/re.html
$foo =~ s/foo/bar/
foo = re.sub("foo", "bar", foo)
Personally, if I were advocating Perl I'd probably go with angles like the extended capabilities or more complete Unicode support which Python users need to get from the regex module (https://pypi.org/project/regex/).
It's about as much of a problem as not having built-in linear algebra operators.
Also, it wasn't a first mover in scientific computing--Matlab and Maple were around long before numpy. Matlab dates from the early 80s; numpy from 2005. Python has stolen a lot of mindshare from Matlab with numpy and scipy and Jupyter. Even today I help PhDs switch from Matlab to scipy.
Personally, I've always liked the ethic of Python that there's only one way to to do it, normally. It means the boilerplate code looks the same everywhere, and when you break the "rules" of that one way, you do it with a reason, a conscious justification, rather than as a stylistic flourish or an idiosyncratic preference.
Python is obviously not "a first mover in the scientific world" as Matlab precedes Python for over a decade and is still the de facto tool of the trade pretty much everywhere except ML.
And please don't misrepresent UX as "dumbing down". If anything, Python does right far more things that other languages do blatantly wrong and even in a user-hostile way.
> Python has no built-in regex support
This argument reads like a blatantly desperate attempt to find any thing at all to try to get Perl's leg over Python.
Meanwhile, no one ever complained about Python's re module not doing its job, and Python is extensively used pretty much everywhere, involving regex or not.
The first is Larry Wall's basic personality. He is a really nice guy, all the way through. Along with that, I think he's fairly passive. Years ago, I read a comment from him where he noted that of all of the things he's posted online, the vast majority were replies. He rarely directly initiated.
Clearly he initiated Perl, as well as https://en.wikipedia.org/wiki/Patch_(Unix) (for those who might not know, this was basically the reverse of 'diff', and is effectively the spiritual ancestor of MANY of the tools and technologies we use today.)
But the genesis of Perl was really small; like Linux and many other projects, it was done to solve very specific problems, and also for the fun of it. Perl utterly exploded, effectively dragging Larry Wall along with it.
All that to say: even as Larry was able to put forward technical direction, as seen in the creation of Perl6 and subsequent design/development processes, I don't think he ever felt very comfortable being a community leader.
The second major factor early in Perl6 was that Larry had some substantial medical problems at really key, important times.
I don't know if these and other factors, if different, might have allowed Perl6(Raku) to become successful. It's possible that the sheer, awesome scope of Perl6 was just too big.
One way or another, what ended up happening was a damn shame. In retrospect, I think it's clear that Larry should have, in 2000, announced the creation of a new language, a language that shared many/most of the broad goals and ideas of Perl.
But 21 years ago, such an announcement would have been almost impossible. The total amount of hurt and divisiveness that ended up coming about due to Perl6 might have been minimized with such an action, but it would have been strongly front-loaded, with an unbearable amount of community pain concentrated into a single point.
yet the world still does not have half the features Perl 5 already had for 20 years :)
... from scoping to support for every major programming paradigm
But perl had become successful not by being a perfect embodiment of TMTOWTDI or whatever but by being a simply amazing practical language for practical problems. And without the support for the practice of perl, perl 5 rapidly withered as new problems became more practically solved in Python or Ruby.
It's worth noting that Python almost did exactly the same thing to itself, too. But it was saved because Python 3 wasn't nearly as incompatible as Perl 6, and that it actually shipped reasonably promptly. But IMHO it's no accident that the explosion of node.js happened just as Python broke the world with their incompatible upgrade.
Not totally sure that I agree here.
I wrote backend Javascript code when Node was beginning to become popular instead of Python because I needed to write a multiplexed socket server that was much better server by the JS asynchronous paradigm over Python. Socket.io was a much better experience than much larger, complex Python equivalents which performed worse, so I kept around most of my Python code and used Node for multiplexing.
At the time Python 3 wasn't even a question. There was no push to upgrade seriously, just patiently waiting for the libraries and frameworks to be ported.
To this day Node.JS and Python server fairly different purposes in most stacks, and although they can do the same job, for each domain generally one is better than the other.
The thing about perl6 was it over promised and... well... never delivered. It was to be a from scratch rewrite. It was gonna have all these space-age feature like a VM to host other languages like what .net or Java does. It was gonna try to fix years of baggage. It was gonna be super hot. But it never shipped in time.
Meanwhile python was an excellent alternative. Ruby on Rails was just coming around. C# was becoming a real contender (c# remains one of my favorite languages...).
All those languages were getting tons of community support. Perl’s community was starting to slow. It’s top devs were busy with v6. V5 was not getting any cool new features. And it was made quite clear that v6 had many breaking changes from v5.
I dunno. I file perl6 in the same bucket I file Netscape and Winamp. Proof that doing ground up “from scratch” rewrites are great ways to kill forward momentum on your product. Rewrites take much longer than any estimate. To pull it off you need to have unlimited budget and the ability to support and improve the current version while also building a brand new version whose scope constantly creeps to maintain parity with your current version. The second you stop maintaining and improving what you have in the market today, your competitors will eat your lunch.
It is what killed Netscape to a large extent.
It killed Winamp to a large extent.
And it put a couple nails in perl’s coffin too.
Yup, the Osborne effect: https://en.wikipedia.org/wiki/Osborne_effect
I loved Perl back in the day, when it seemed like a great alternative to constructing unix pipelines of awk, sed, etc.
Although I mostly used Perl for interactive use, I also found it helpful for quite a few short programs, say in the 20 to 200 loc category. But I noticed a problem: these programs were tricky to understand a year later. Perl was still useful, mind you, but just not as pleasant at the edit stage as it was at the writing stage.
And then Python came along. It soon became clear that Python programs would "age well". For quite a while, Python and Perl coexisted in my toolbox.
And then Perl started to drift into it's present state. All the new goodness (and I'm sure it is good) just seemed to come at a cost of more complexity. But why should I learn the new way of doing Perl, when Python was already filling the gap for that sort of work?
Gradually, my use of Perl decreased, from every hour to every week, to ... well, never.
I wish Perl had just gone into bug-fix mode long ago, so that it could have remained a reliable and understandable tool for a certain set of tasks. And then I'd still use it for pipelines, as I use awk, sed and the rest.
I'm sure python has had several improvements in this regard since, but it just seems to me like it comes at a cost of more complexity (virtualenvs and whatnot.)
This. Exactly.
I had to start bringing printed out Perl code to my job interviews in order so that the interviewer was in my subset of Perl. And then the interviewer was lost, but that was better than him thinking that I didn't know Perl.
That was a giant red flag that I needed to be using a better language. I jumped to Python in 1996, arguably at the height of Perl's popularity, and never looked back.
That was 20+ years ago, and Python filled this space with its easy definition of classes and candy syntax. Where Perl overdid on hackery, Python may have overdone on sugar -- but it clearly won the love of the masses.
Now, 25 years later, the ship has probably sailed for Perl, and -- while I still prefer it to sed/grep/awk and Python for simpler tasks, I don't see it conquering Python space for more complicated processing.
Instead it took way too long, had confusing naming with the various implementations and frankly some features that are not very useful for anyone but linguists. I mean, why would you want to redefine your language from within the language? To confuse your co-workers? To win the obfuscated perl contest?
Perl 6 also has some real innovation like its new regular expressions. I'm afraid they will never get widely adopted.
FWIW i never had a problem with nested data structures in perl. I found the perl documentation ("perldoc perldata") to be fantastic.
Keep the exact same name and a perfectly straight face, then recursively retronymonically redefine it to mean something completely different: the opposite of what it initially meant!
"Yet Another Markup Language" => "YAML Ain't Markup Language"
So "PERL 5" is to "Practical Extraction and Reporting Language 6", as "PERL 6" is a "PERL E___ R___ L___ 6".
(Pattern matching and filling in the blanks is left as an exercise for GTP-3.)
Python 3 was announced in 2006, committed to as the future in 2008, and the last significant release of Python 2 was in 2010. There was a hard deprecation deadline of the Python 2 in 2015, which was postponed in 2014 to 2020. It wasn't fantastic and there was some pain and some poor decisions but everybody knew where the language was going and how to stay in front of it.
Perl 6 was announced in 2000 and there were only 2 releases of Perl 5 for 7 years. Then in the 2007-2010 timeframe regular releases of Perl 5 resumed. Eventually everyone kind of realized that Perl6 was DOA as the next major release of Perl, but that process happened gradually over the course of nearly 20 years, by which time most of the rest of the world had written off Perl as a significant entity.
Then Larry Wall announced Perl6 and focusing on Python while awaiting P6 was an easy call.
Haven't used Perl often, but that's sort of my impression as well. And that Python sugar feels mostly pretty well reasoned about. And fairly usable and readable as well. Whereas in Perl I sometimes had the impression a bunch of people with CS degrees made something they thought out while on LSD and just decided to add it. Cool at the moment, but not too usable by sober minds afterwards.
Perl was designed by a linguist along the principles of "what would English look like if it was a programming language?"
Not in the superficial syntactic sense, but the underlying grammar. What is the implicit "it"? What can we derive from context and decision so we don't have to spell it out? And so on.
This makes it very convenient to express common things in different ways (just like English, there is no one true way to say something) but it also creates some peculiar constructs that make sense but you'd go "who says this?" (again, much like in English.)
The tired old "Perl was designed by a linguist" cliché is endlessly Parroted (pardon the pun!), but doesn't actually necessitate or imply good programming language design. But look at the actual factual source of that folklore -- it would be more accurate to say "Perl was designed by a wanna-be missionary", and that certainly shows ("Exegesis", "Apocalypse", "bless", etc):
https://en.wikipedia.org/wiki/Larry_Wall
>While in graduate school at the University of California, Berkeley, Wall and his wife were studying linguistics with the intention of finding an unwritten language, perhaps in Africa, and creating a writing system for it. They would then use this new writing system to translate various texts into the language, among them the Bible. Due to health reasons these plans were cancelled, and they remained in the United States, where Wall instead joined the NASA Jet Propulsion Laboratory after he finished graduate school. Wall is an active member of the New Life, Church of the Nazarene.
Going on a missionary expedition in Africa to invent and teach illiterate people of color a written language to read the Bible in certainly sounds to me more like religious and linguistic imperialism than a sound motivation for programming language design.
https://en.wikipedia.org/wiki/Linguistic_imperialism
>Linguistic imperialism or language imperialism is occasionally defined as "the transfer of a dominant language to other people". This language "transfer" (or rather unilateral imposition) comes about because of imperialism. The transfer is considered to be a sign of power; traditionally military power but also, in the modern world, economic power. Aspects of the dominant culture are usually transferred along with the language.
Translating CS literary classics like the "Pascal Users Manual and Report" and Anders Hejlsberg's "Turbo Pascal Reference Manual", or even textbooks about sustainable farming techniques, nutrition, medicine, sex ed, and birth control, into their invented written language would do more economic and life sustaining good for those poor Africans than translating the Bible.
kqr> "people with CS degrees adding things that sound cool"
People with CS degrees add cool things that are sound, not things that sound cool.
Do you really believe that programming languages should be intentionally designed to be MORE like religions, MORE imperialistic, MORE evangelical, instead of less?
Compare Larry Wall's contributions to this otherwise deep fascinating conversation about language design, versus the contributions of less religiously motivated, more scientifically trained programming language creators with CS degrees, like Guido van Rossum, James Gosling, and Anders Hejlsberg:
A Language Creators' Conversation: Guido van Rossum, James Gosling, Larry Wall & Anders Hejlsberg
https://news.ycombinator.com/item?id=19568378
https://www.youtube.com/watch?v=csL8DLXGNlU&t=49m41s
James was literally taken aback by Larry's macho IDE shaming:
https://news.ycombinator.com/item?id=19568381
"I think IDEs make language developers lazy." -Larry Wall
"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling
Not Python -- it has Zen-like practical suggestions about what matters, instead of ideological doctrine about how to do it:
https://www.python.org/dev/peps/pep-0020/
>There should be one-- and preferably only one --obvious way to do it.
>Although that way may not be obvious at first unless you're Dutch.
Does The Zen of Python really sound "imperialistic" to you?
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!Anyway, the closest I’ve experienced is Go, to answer your question.
https://en.wikipedia.org/wiki/Christianity_and_colonialism
>Christianity and colonialism
>Christianity and colonialism are often closely associated with each other because Protestantism and Catholicism participated as the state religions of the European colonial powers and in many ways they acted as the "religious arms" of those powers. According to Edward Andrews, Christian missionaries were initially portrayed as "visible saints, exemplars of ideal piety in a sea of persistent savagery". However, by the time the colonial era drew to a close in the last half of the twentieth century, missionaries became viewed as "ideological shock troops for colonial invasion whose zealotry blinded them", colonialism's "agent, scribe and moral alibi."
>In some areas, almost all of the colony's population were removed from their traditional belief systems and were turned into the Christian faith, which the colonizers used as a reason to destroy other faiths, enslave the natives, and exploit the lands and seas.
>"Colonialism is a form of imperialism based on a divine mandate and designed to bring liberation – spiritual, cultural, economic and political – by sharing the blessings of the Christ-inspired civilization of the West with a people suffering under satanic oppression, ignorance and disease, effected by a combination of political, economic and religious forces that cooperate under a regime seeking the benefit of both ruler and ruled." -Jan H. Boer of the Sudan United Mission
Also, the end of slavery was pushed by conscientious Christian evangelists like John Newton and William Wilberforce in the UK. It is easy to argue against slavery in Christianity owing to the Imago Dei doctrine. I suspect it is less easy to argue against slavery in other religions and cultures; many of which still practice forms of it today.
Spreading your religion while separating your culture is difficult. The same way it is difficult for a migrant to fully adapt the customs of any host culture. I think the relationships between these ideas are more complex than the evil catch-all of 'Imperialism!'.
This always felt like an excessive over-reaction to Perl's "there's more than one way to do it" motto and never struck me as desirable or true.
In the earlier days of Python I remember reading StackOverflow questions which attracted differing solutions and Python advocates (who were a bit abrasive at the time) would reconcile this with the above by saying some answers weren't sufficiently "pythonic". It all seemed rather strange.
It's fascinating to learn that Larry Wall might have become a missionary had his life gone a different direction, but I don't think one can make a compelling case that Wall's religiosity had a major effect on Perl's language design. Don Knuth is a devout Lutheran who played church organ, taught Sunday school, and wrote a book about the Bible -- but it just doesn't seem likely we should be concerned that typesetting our work with TeX subtly infuses it with Christian apologia.
Honestly, this could only be said by someone who had never met anyone whose spoken language hadn't been written. I personally know people who have recently done exactly this: Developed a writing system for a tribe of people who previously had no writing system for their own language. The people themselves are amazed to see their language written down. They have generally internalized the negative attitudes of the larger culture they live in toward their own language; they'll say things like (and this is going to be offensive, but again, it's them saying it about their own language, having internalized it from the larger African language groups around them), "I thought our language was just a monkey language". Seeing it written down gives them a sense of value and pride toward their own culture they've never had before. This is exactly the opposite of "the transfer of a dominant language to other people". On the contrary, it gives people a powerful tool to fight linguistic imperialism.
0: https://en.wikipedia.org/wiki/Canadian_Aboriginal_syllabics
This isn't 'Temple OS'. By this line of reasoning we should all only use strongly-typed FP since it's the only 'rational enough' language family.
Yet HN mods have the gall to claim that "reflexive," combative commenting is not allowed, and "reflective," truth-seeking comments are what's required: https://news.ycombinator.com/item?id=26548649
Clearly, certain users are allowed to say whatever they want on HN. If HN were honest, it would go ahead and give them orange checkmarks.
It would also not be allowed if it were against any religion other than Christianity.
(You mention exactly one thing about Perl's design, namely the "bless" keyword. That's a bit quirky, but it's not a terrible name for what it does and nothing obviously better occurs to me.)
> Going on a missionary expedition [...] sounds to me more like [...] than a sound motivation for programming language design.
In what way were Larry Wall's missionary ambitions a "motivation for programming language design" at all? I don't see any sign that they were.
(I do remember, from many years ago, something in Perl's licence or readme file along the lines of "I make Perl because I think it pleases the Author of my story. If you have a problem with that, your notion of Authorship needs some revision :-)", but I think that means not "I wrote Perl to help me convert the heathen" but "Everything I do is for the greater glory of God". So far as I can see, that doesn't imply any particular language-design choices.)
[EDITED to add: I looked it up. The above doesn't misquote too badly, but one place where it diverges from the original is that he actually wrote "nice things like this", not "Perl" specifically. I think this makes it even clearer that the Perl language design as such is not what LW is saying was religiously motivated. You can find the actual text at https://github.com/Perl/perl5 if you care.]
I listened to as much as I could bear to of that language design conversation. (The audio is incredibly bad for almost all of it, unfortunately.) I didn't notice Larry Wall's contributions being notably less insightful, more dogmatic, more ignorant, or whatever it is you're gesturing towards. The one example you give is that Larry Wall doesn't like IDEs and James Gosling does, which doesn't seem like good evidence of anything.
So, please, if you're going to make this sort of claim, make it explicit enough to engage with properly. What about Perl is the way it is becaues of Larry's "religious fanaticism"?
(As it happens I'm an atheist and don't like Perl very much. There's plenty I dislike a lot about both Christianity and Perl. It's the alleged connection you're trying to draw between them that I don't see at all.)
This story has been told for decades, but it just isn't true. What is particularly convenient to express in Perl? The only thing i can think of is the implicit use of $_. Everything else is no better than or worse than in a more conventional language.
Things like sigil's are useful in this regard because they provide hints that allow extending the language w/ irregular syntax, like with autovivification. Perl wasn't designed; it slowly accreted features as use cases emerged, moderated by implementation constraints, and that was intentional.
Python code today is nowhere near as simple as 20 years ago. Python, Java, and similarly aged languages are ending up w/ a cornucopia of mismatched language syntax and semantics much like Perl, except Perl was never blind to the inevitable. Lua is one of the few exceptions, but that's because Lua has gone through a couple top-down redesigns in addition to its more regular backward compatibility breaks.
1) Natural language doesn't have to worry about backward compatibility in the same way. The exact meaning of older phrases don't have to coexist with those of new phrases.
2) Natural language doesn't have to recruit new users in the same way. I think Spanish is one of the easiest commonly spoken languages - if a random person speaking no commonly-spoken-in-the-world language had to choose languages, Spanish would be ideal. English is weird in saying things with idioms, Chinese has tones and complex characters, etc. English has evolved in a perl-like fashion and if it was a programming
3) No children learn perl or any programming language as their "first language". Everyone learning perl had to wade through it's modes and variable names like "_" and translate them to their internal concept language. (should add: verbs like "be", "do", "have" etc are very fuzzy in English as well as proposition "like" "to", "from", at etc but this fuzziness is incorporated as a person learns the language. But adding an equivalent weirdness to a language someone is just learning isn't necessarily going to be appreciated).
4) Communicating with other humans is arguably a key function of computer languages as well as natural languages. But computer language do also have to communicate exact to descriptions to the very dumb devices known as computers. So "getting the gist" and "getting it exactly" have to be somewhat close and makes "there's more than one way to do things" more problematic, especially as ways to do things multiply.
https://news.ycombinator.com/item?id=24083738
https://www.mondo2000.com/2018/06/18/the-inspiration-for-hyp...
"In 1985 I swallowed a tiny fleck of gelatin containing a medium dose of LSD, and I spent most of the night sitting on a concrete park bench outside my home in Los Gatos, California." -Bill Atkinson
I think that you are right about the nested data structures. I was favorably impressed by the little I saw of Moose, but by the time that came along, all the young seemed to know Python and not Perl.
It is not just flat files Perl handles nicely, either. One can do fixed-format munging in Python via the struct module, but I've never found it as handy as Perl's pack/unpack, something I used as far back as the Perl 4 days.
$foo="bar"; #scalar/string
%hash = { "key" => "value", "key2" => "val2" }; #hashmap
@arr = ( 1, 2, "three", 4); #array
$array_ref=\@somearray; # array ref
$hash_ref=\%somehash; # hash ref
$scalar_ref=\$some_scalar; # scalar ref
$$arrayref[0] = "data";
${$arrayref}[0] = "data";
$arrayref->[0] = "data";
@IP = ('192.168.1.10','192.168.1.15');
@PORT = ("5000","5002");
@TCP = ("Q931","H225","H245");
@LAYER = ("ETHERNET","IP",\@TCP);
@PKT = (
\@IP,
\@PORT,
\@LAYER
);
$array_ref = \@PKT;
${${${$array_ref}[2]}[2]}[1];# oof!
# same result, looks better, but imagine
# we put a hash in the data structure, or
# had deeper structures
$array_ref->[2]->[2]->[1]; $array_ref->[2][2][1];Here's a modified example where it's not as clear how to deref.
Like:
@IP = ('192.168.1.10','192.168.1.15');
@PORT = ("5000","5002");
@TCP = ("Q931","H225","H245");
%TAGS = (L2 =>"ETHERNET",L3=>"IP",L4=>\@TCP);
@PKT = ( \@IP, \@PORT, \%TAGS);
$array_ref=\@PKT;
print $array_ref->[2]{L4}[0];# this works
print $$array_ref[2]{L4}[0]; # this works
print $array_ref[2]{L4}[0]; # this doesn'tHow was it a pain specifically? If you used references, then defining an arbitrary data structure shouldn't be an issue and accessing individual elements would be a matter of prefixing the reference with the appropriate sigil.
In python, you need to be aware of when you're making a copy of an element in a data structure rather than getting a reference of that element. In perl, you would know based on syntax whether you're dealing with a reference as opposed to a copy of an instance.
Once you 'get' the sigils in Perl, you miss them everywhere else.
PHP's weird half-assed copy of the sigil system ($ only, for everything) is one of my least-favorite things about it (but I don't really hate PHP the way some people do, so that may not be saying much).
$, %, and @ are why using complex multi-dimensional arrays & associative arrays in Perl is non-crazymaking. You can at least state the kind of thing you're intending to use at each layer of the array, and have that intention readable even when syntax highlighting isn't available, which is a lot better than nothing.
I mean, sure, in Perl the language "casts" the value into an appropriate type for you, but only in a few select cases..
For me, the main advantages of sigils are that I can immediately see if I am looking at a variable or a function name and that the sigil effectively separates the name spaces between functions and variables. This has the side effect of making it easy to distinguish functions that have been passed in as variables from functions declared or imported into the particular scope.
Even with a nice IDE I miss the distinction that the sigils provide.
foo.bar = 1
I also like the more explicit operators in Perl that help show context:
$foo + $bar
Another problem I noticed would be natural language like syntax sugar, which makes it harder to maintain your knowledge of the language if you don't use it regularly. I learned some perl long time ago during one project, and after I stopped working with the project, I also gradually stopped using perl for quick scripts, and settled on sed/grep/awk again for quick simple stuff, and python for the other tasks.
XML::LibXML is a nice wrapper around libXML.
XML::Twig is great if you need to process huge files.
XML::Rabbit will seamlessly map your XML into objects.
There are things to criticise Perl for, like idiosyncratic argument handling in subroutines or the use of weird punctuation variables, but to call out XML parsing as particularly hard is questionable.
Take a look at this example from https://grantm.github.io/perl-libxml-by-example/basics.html
use XML::LibXML;
my $filename = 'playlist.xml';
my $dom = XML::LibXML->load_xml(location => $filename);
foreach my $title ($dom->findnodes('/playlist/movie/title'))
{
say $title->to_literal();
}
Can you expand on that a bit? Are you talking about how Perl5's variable sigils?
Oh man did we ever abuse the shit out of the loosy-goosy data structures you could make in perl. Almost any time you needed to debug or trace something, you'd pretty print the entire data structure you were passing around. Some of those suckers would be huge and you'd be passing that structure around to almost everything in your codebase!
As an outsider it might appear scary and a massive code smell... but when you worked on that codebase it just kinda all made sense somehow. It was just how perl programs rolled.
I have yet to work in any other language that let you use and abuse the native data structures quite like you could in Perl.
I firmly believe that it wasn't specifically about the switch to perl6, it was about the loss of the cpan that broke the camel's back.
Which would go one to have its own breaking change.
Probably people who took up perl after something even more adversarial can learn to love it. I doubt I ever can.
What I did love about perl though — something I don't find in modern languages — is its carefree playfulness, which must have stemmed from the hacker culture associated with it. I still chuckle every time I use Carp for debugging. Carp::croak, Carp::confess, or Carp::cluck are genius!
$ - > the value of
@ - > the values of
% -> the collection of key value pairs
$_ is pronounced "it". @_ is pronounced "them". Don't use either of them except if it would make sense in english - e.g. you wouldn't refer to "it" in anything more than a sentence, so don't use $_ in anything longer than a couple of lines of code
I am not sure this metaphor makes sense to me.
Imagine that I have a pack of dogs. When I use a language to say: "Remember that pack of dogs that I mentioned previously? Go ahead and give it to me" — I do not expect to also need to specify whether I want the pack with all the dogs in it, or whether I just want some value associated with that pack, which, if I remember perl's behaviour here, would be its length. I could understand if a language wanted me to specify whether I want the thing itself as opposed to a reference to the thing (I suppose it would make total sense as a Saussurian opposition of a signifier vs the signified); but the ternary opposition that perl enforces is neither here nor there linguistically — it's just bizarre.
Context and list flattening are probably the most foreign parts of Perl to someone who doesn't know it. Everyone fixates on the sigils, but the weirdness in the way sigils operate stems from context.
When you call a function, the arguments are flattened into a single list. So `foo(1,2)` is the same as `my @args = (1,2,3); foo(@args, 3)`. Every expression can be evaluated in one or more contexts. So taking the value of an array in scalar context gives you the length, which is handy but also means that, since 0 is falsy, you can just do logical tests on arrays to check if they are empty. Because the behaviors are relatively intuitive, it's possible to quite a bit of work in Perl before you even understand what context is or how it operates. `if (@foo) { do_stuff(@foo) }` does what you'd think it does, even if you don't know about context.
But it also means that the distinction between `my $match = $foo=~/(foo)/g;` and `my ($match) = $foo=~/(foo)/g;` is not at all obvious if you don't understand context. (The first example gives you the count of matches, the second example gives you the first match because the parens put you in a list context which means you are effectively assigning into a slice.)
The fact that you use two sentences don't make sense together in order to try to illustrate your point seems to me to demonstrate that.
Python helps you to think more like the computer does. Perl helps the computer think more like you do.
As someone who works with a legacy system written in Perl (we're slowly moving to Go), I absolutely hate this. It's completely obscure for no reason, and that's just not fun. I'm glad no language does this anymore.
Same goes for Perl critic levels: --brutal | --cruel | --harsh | --stern | --gentle, they're all compleyely useless at conveying any meaning! why is brutal > cruel??
Chef is the worst for this
But I have found the experience incredibly useful. Using Raku is like working with advanced alien technology. My experience with it changed the way I write other code.
I recommend playing with Raku for mind expansion.
For Christ's sake, I keep forgetting what "croak" and "cluck" even are in, you know, normal language usage.
But I agree about the use of '$' for array elements. '$array[$index]' - this is kind of unintuitive - because the array is @array - and here you need to change the sigil. That is why in Perl6 (and Raku now) they got rid of that.
I remember the moment that Hungarian notation died for me (when previously I was all about it in C++): when I looked in the back of a Microsoft book on Visual Basic and found a six page table of four letter prefixes for all the different types you might encounter in VB6 with COM. The idea that I would either memorize those or continually look them up so that I knew what I was dealing with in code was the reductio ad absurdum of Hungarian notation.
I would argue that python, ruby, javascript and similar languages have demonstrated that it's just as easy to read code without sigils as with them, probably even easier — let alone to write one. Uncle Bob and other evangelists of software craftsmanship suggest clear, descriptive names for variables that would convey their meaning to the reader. As far as I understand, perl programmers also don't dispute the value of meaningful names. At which point using additional twiddles for conveying intent to the reader becomes redundant.
It's funny to me to see the same people who complain about sigils in perl whole heartedly adopt the Rx convention of naming streams with a tailing $.
It's literally just a sigil. Yeah, you put it at the end, but it serves the same exact purpose.
This one is a naming convention. Same as how the previous generation of javascript developers used to prepend variable names with a dollar sign if those variables referred to jquery-wrapped objects. Same as starting class names with a capital letter, or using all capitals to name constants. It doesn't have any special meaning for the parser. Your program won't break if you don't follow these naming conventions. It's entirely a style thing.
If you can't rely on the symbol or its absence meaning anything, it's just more punctuation.
It seemed that Perl allowed me to leverage my existing knowledge of UNIX utilities, regular expressions, etc. So using it wasn't completely like learning a new programming language and a set of libraries at the same time. In other words, the startup cost wasn't all that high.
I agree with comments about doing anything too complex with data structures in Perl. I am sure there are people that easily remember the syntax for returning a reference to a hash of hashes, or whatever. I'm not one of them. Every time I have to work on applications I wrote previously that did this, it's a couple of hours of googling and trying things out in the interpreter.
If I had to write or rewrite a large application today, I'd probably use Python. I learned it fairly well about ten years ago and enjoyed working in the environment.
In my secret inner fantasy world, I'd use Common Lisp exclusively, my colleagues would just agree that it is the best programming language ever, and we'd spend our days sitting in an outside cafe in San Jose, drinking espressos, hacking our .emacs files "for efficiency," and telling stories about how we used to boot computers by first toggling in the boot loader from the front panel.
Ehhhhh. I appreciate the opaqueness of Perl, but you've described something like the easiest data structure in Perl to write and access: return {"foo" => {"bar" => "baz"}}; return {foo => {bar => "baz"}}; $data->{foo}{bar} = "quux"; etc etc.
It's when you drop away from the land of hashrefs and listrefs, and have to use plain old hashes and lists, that things actually get super weird - because most programming languages you're used to simply give you "refs" for everything, and they definitely don't have concepts like "list context" that let you merge lists by saying @a = @b, @c;
third_list = [*first_list, *second_list]
Perl grew to prominence when being a creole of C, shell, sed, awk, and lisp was an advantage. Anyone who might reasonably use it would be familiar with at least a few of these tools.
Now, we live in a very different world. JavaScript is the new BASIC. Everyone has JsBASIC installed on their (virtual) machines. So that's what people learn on their own. Python and Java are closer to JS so, the transition is easier (at least superficially--I could argue that JS and Perl a lot in common, designwise).
However, the rise of database backed web apps gradually removed a lot of the need for the special magic that Perl brought to the table.
Here are alternative links to the same emails by Paul "LeoNerd" Evans
external factors email https://marc.info/?l=perl5-porters&m=161688954811345&w=2
internal factors email https://marc.info/?l=perl5-porters&m=161688963311406&w=2
Sigh. You would think that reflecting on a thread the author knows is public would have better introspection than this, but there's that Upton Sinclair quote again:
“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
Python didn't win simply by randomly being selected as the choice to snowball effect on. Ask any language-agnostic or new programmer to take take a gander at each one. 90% will find Python easier to use. That's where Python's strength is, and that is a huge market, as the general population just isn't that great at advanced lower-level programming like C++. So you have college intro courses and programming-adjacent fields in academics (stats, bio, etc) able to dabble into Python. Perl kept plodding on with it's diehard unix fanbase. You can't expect mass appeal when that's your focus. Still failing to acknowledge this is what contributed to Perl's downfall (random snowball effect, seriously?) at the expense of Python is why Perl continues its decline.
However, I think languages like Perl, PHP, and Tcl get far too much grief. To quote Hemingway "Critics are men who watch a battle from a high place then come down and shoot the survivors."
A friend of mine texted me a question about an issue he was having, and I texted back an answer with some Python code for illustration. I don't know if he has ever used Python for anything. I just assume it's an acceptable least common denominator for technical communication. Even if it turned out he was a copy of my friend from an alternative timeline where Python never existed, he would have no trouble reading it as pseudocode.
Try that with Perl!
As a Perl fanatic. I've come to like Python because of the endless feature bloat and growth of library ecosystem.
The Perlification of Python has happened and we old time Perl programmers are enjoying it.
Personally I still think Perl 6/Raku has a chance provided a Killer app comes around.
This is fine for a lot of stuff, but somewhere in the 2000s, it became increasingly annoying you could not properly use Perl's biggest value up to that time, CPAN, anymore, because when you brought in 5 dependencies, you ultimately had 5 different object systems, 15 type validator libraries, 5 different time libraries and probably 20 different exception systems in your project, all happily eating away at your memory and your sanity.
This is still a major problem today, where you basically cannot pull anything from CPAN anymore without the smallest package requiring a different fat object system.
A lot could have been avoided by early on building a proper standard library delivered with the language, but instead at that time Perl delivered a lot of obsolete cruft, simply because it always was part of Perl, instead of real basics.
That's at least my take on things. Though of course, npm proves many people do not give a damn about overly long dependency lists, so maybe it's just what I personally dislike about the direction Perl has taken.
This is an issue in Lua as well. The language is unopinionated and designed to offer “mechanism, not policy”, meaning you can design your own object system based on the language-provided primitives.
The problem is that everyone does design their own object system - and they’re all different, with no interoperability.
Back in the day there was that horrible trend of using "inside out" objects that would let you reliably subclass something without knowing it's underlying module system.
Ovid's Cor project has some really great work on specifying a default OO sytem for Perl 5 (or maybe 7). https://github.com/Ovid/Cor/wiki
I think Perl has always been an artist's tool, rather than an industrial tool, and this is why so much Perl code in the world is a relatively-unreadable mess. It grants great artistic license (which was also the name of its software license!) to the coder, as evinced by the Perl community motto TIMTOWTDI ( https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to... ). In the hands of an expert working on a labor of love, flexible artistic tooling allow maximal freedom and craftsmanship to create truly great things. But in the hands of novices, or even experienced professionals who are tasked with just getting something functional done on a deadline, there's little in the way of guardrails pushing the solution towards elegance, simplicity, and readability.
Most coding work that is ever done is more industrial and task-focused in nature, and artistic tools aren't always really the right tools for that job. By way of analogy: Let's say in an industrial setting a manager decides that a new, large, safety warning placard needs to be created to warn employees about slipping on the wet floor of the factory. The manager could task an employee to go pick a standard "Wet Floor" sign from a catalog and order it, or she could decide we need a custom message and ask someone to contract with a signage company, or even in a pinch she could decide to hand someone a big square of plastic, some white paint, and a set of letter stencils to go make a sign with. She might even cite some ANSI standards the sign has to comply with about font sizes and colors for warning signs of this nature.
What she'd never rationally do in this scenario, is just hand them a gift card to an art supply house and a tab of acid and tell them to go be creative, which is probably the closest thing to the Perl way to go about the problem. Nonetheless, Perl has value and merit, and is a beautiful thing.
as a quick and dirty web app it feels much more useful then anything else.
When I see or code PHP nowadays, I still feel welcome and understand all of it. Kudos to the PHP team for that.
Learn Java. Work in finance. Take the money :)
Perl devs were self taught hackers. Finding them was nigh on impossible
We ended up with a bunch of Java devs and pivoted to Java for all new applications. As a commercial decision it was sound and the company is doing well
I'm doing Ruby now and facing the same problems but at least the graduates have heard of Ruby so they at least know what we are asking them to do
And yes Perl6 was a massive issue. At least they finally acknowledged that it was really a Perl inspired language and not Perl at all
;P
In fact, the color of the spoon (the syntax and expressiveness of the language) is probably why Python won out over Perl; it is certainly why I switched somewhere in the late 90s.
Also... If your niche language isn't well supported by those who build language bindings for libraries and systems, fix that by making it extremely easy to create language bindings. If building a Python-to-Your-Language bridge is the only way to achieve this (it isn't) then build that.
Perl 6/Raku was also a response to Perl's shortcomings. The rewrite has allowed the language to leapfrog several other languages in various ways. Without going into details, I'm thinking about just concurrency, gradual typing, parsing, method dispatch, unicode handling -- digging into any one of these topics reveals a lot of richness to be explored.
Whilst they dont admit they had nicely developed specs and list of features to implement (for perl6), but couldn't manage (technically) to implement even the most simple ones from 2002 to 2021. Management is not-existing, developers all went elsewhere. You don't want to argue with people you have no idea. Famous is e.g. how Russ Cox was treated when re2 and backtracking DDOS was presented to p5p: https://perl.perl5.porters.narkive.com/guZUVhlv/article-on-p...
Just a few amateurs and system admins, who use it for their job are dabbling with it and keep destroying the codebase. It was unmaintainable in 2002, and it's more so now. The language is fine, p5p (the development process) is totally broken.
It's possible to be expressive enough in perl that your colleagues cant really fully understand what it is you're trying to accomplish.
And every Perl developer took that as a personal challenge to find and use all the ways in a single program :-)
A couple years later I needed a slightly different calendar render for a freelance project that had to be in Perl. I looked at my old, terse Perl code (it was maybe a couple screens if that), tried to understand what the hell it is doing, and wrote the new calendar from scratch. I also made sure to "write C in Perl" so someone could actually understand it later.
It's possible to write clean code in Perl, but from pretty much every codebase I've seen, it is not natural :)
Then I discovered Python and haven't looked back.
I witnessed the change as, overnight, my Perl expertise became 100 percent useless in the job market. Today, almost no one younger than 35 has even seen Perl code unless they work in a megalarge corporation that has legacy code.
* poor language support for building complex programs or data structures... it was possible but never easy. * the stdlib: compared to PHP, Python, and Ruby, Perl offered very little built-in, which means that the next item was even more critical: * CPAN: was extremely difficult to automate and extremely flaky compared to the alternatives, RubyGems in particular.
And yes, Perl6, which for a long time prevented Perl5 updates entirely. They got past that, but it was too late. I think the uncertainty guaranteed no one was going to invest in pushing for the needed improvements to CPAN either (tho maybe they’ve happened, I haven’t even tried in a decade).
It's not fun and not hell compared to other jobs. If it does keep running, it's not that bad. To put a perspective on it, I've seen Python codebases so overengineered, brittle, and hard to read, that I couldn't help but think that the authors chose the hard way quite deliberately, and that they viscerally hated their colleagues. This doesn't make Python the language bad.
But how Perl handles Unicode and it's plethora of internal flags on strings that make them bags of octets, maybe-invalid UTF-8, valid UTF-8, and other such nonsense — is driving me nuts! Because it's documented right there in `perlunicode`, some people take those flags to introduce some kind of their own type system. Mostly it's DBI, which will send corrupt data to your database if a string value had the wrong flags. There may be others, but DBD::mysql is something I've been burned by.
Now, sometimes you get the string after soaking it in a chain of third-party module calls, and you can't be sure if it's all octets, or it's UTF-8. `eq` returns true on two strings, but on the application-database boundary you get two distinct behaviors.
I know that people have been furious about the bytes/unicode split in Python 3, but trust me, it's the better than Perl's nightmare.
Perl's gimmick was "we had this text processing language based on linguistics theory, and we hung stuff off the side until it became a proper language". What the result was, really, was something that went through text like a swiss army chainsaw, but was a damn clunky mess doing real language stuff. Even if it was, for the time, pretty damn neat in its overall list of features. This neatness gradually paled as everything else caught up and surpassed it.
Nothing since has changed this. Raku still has the gimmicky feel - because that is what defines it as (a) Perl.
There are simply better syntaxes - better, even, nowadays, for text processing and sysadmin, where I'd reach for Ruby. And if I'm not too fond of Python, at least it's mostly uncomplicated.
I think at this point you can stick a fork in it, the gimmick has run its course, it's done.
It scaled up horribly. It showed its weaknesses in larger scripts, and it was gratuitously bad at any scale above that. And of course, as a bundle of idioms with no surface coherence and no unifying logical principles, it was grotesquely hostile to anyone who had not spent a lot of time immersed in it.
But as a tool for command-line wizardry and small-scale scripting, for tasks that didn't need to be shared or maintained outside the priesthood of sysadmins, it was brilliant, and it hasn't been bested or even equaled as far as I know. I think the only reason it fell out of favor is that you can never be sure that a task won't grow beyond this little realm where Perl shines.
Perl design seems like it tries to be “cute” and “clever” almost every design decision. “Hey let’s name it bless, hey add unless and if too”.
Even the documentation tries to be all funny and jokey.
The language suffers for it, when you actually try to do something serious.
Perl 5 fails in separate areas.
* no standard OO system * no standard exception system * no standard module system * context-driven polymorphism * the standard library didn't have JSON and a few other key needs built in, so dragging in CPAN all the time was a hassle.
The first three issues generate maintenance issues that are not found in other languages that are roughly isomorphic. The fourth generates bugs. The fifth generates deployment problems out of line with its competitors.
Perl is also, as alluded to elsewhere, an expert tool. Those have not fared well for the past 25 years, sadly. Hopefully in the next 25 years, as the industry matures and stratifies, experts will have the opportunity to select and use difficult but high quality tools on the regular.
The Perl 6 horse got put together for another ritual beating, I see. Have at it.
Sigils and the other ideas from linguistics are a notion which I believe will be adopted down the road more and more. I see them as one of the best syntactic ideas of Perl, although the context-shifting use of them (@ vs $) is something I see as bug-prone.
Types are an orthogonal concept, so this direction of thought is fruitless and explains nothing. (An example is Raku, it has both typing and sigils.)
People should discuss what sigils or lack of them brings to the table, and language designers must be challenged to defend their decision for or against sigils and explain the resulting trade-off specific to their language. I sincerely hope they are not simply acting out of ignorance, but it's plausible because the language design docs make no mention. Well, Sturgeon's law applies: not everyone's a Larry.
Yet, I don't see that kind of rational discourse happening in the vast majority of cases. Instead I see something very superficial, namely end-users complaining that languages are different. Features that cannot be found in the majority of languages are suspect and basically criticised as a foregone conclusion for just being there, i.e. they will not entertain finding out what the advantages of having identifiers with sigils are. This makes me sad because tolerating this discourse makes the world dumber.
Try working with a database such as sql server. If the sybase driver gets the string encoding wrong good luck debugging the problem.
Perl has a syntax that appears to be designed to make a google search impossible.
I'm not sure why they want you to explicitly work with references. Constantly having to dereference is nothing but noise.
Tooling is non existent. Want to step by step debug, good luck.
It's just not fun.
• Support for database drivers exists, most notably the DBI mailing list where all the driver authors participate. This is mentioned prominently in the documentation.
• Perl predates Google, so it is tragically wrong to put the blame on Perl. Blame Google for not searching correctly for a long time. This is fixed since 2019. Other search engines did not make mistakes of the same kind. I personally do not see Google as the first and final means. It's not asking too much using other means of looking up information when Google falls short, e.g. the offline documentation shipping with language, or bookmarking some specialised Web sites and using their search.
• Explicit references are a consequence of Perl's early life (< v5) catering to programmers familiar with shell, and then adding the feature in a backward-compatible manner. When it came to adding the feature, it was the choice between explicit references with the benefit of keeping code running, or implicit references and invalidating existing code with the benefit of terser syntax (i.e. the dereferencing arrow -> would mostly disappear). The trade-off was made in favour of backward-compatibility, and this direction was the case ever since. Hope this explains it well enough, keep in mind that you have the advantage of judging the decision in hindsight.
• Debuggers not existing is just plain wrong.
I agree Perl's docs are great. Once I discovered 'man perl op' I was set. My complaint is that Perl differs from other languages where a quick Google of a bit of syntax leads directly to stack overflow question or the language docs.
The DBI issue I had was a mix of FreeTDS, Sybase and SQL Server 2008. The combination of an old version of SQL Server and these drivers meant we hit uncommon bugs. My complaint here is how tricky it was to debug. The string has an internal flag to say that it's UTF8. Somehow that was getting set when the encoding was Windows CP1252. It took me a long time to learn about how Perl stored these Strings. Even longer to resolve the issue it caused. Something about packing and unpacking a string just felt harder than it needed to be. The experience left a me disliking Perl.
I worked with a Perl backend for almost a decade. I love not working with it now.
I don't blame Perl for it's difficult to Google syntax, or it's design choices for backwards compatibility. I know some people are Perl grandmasters and can do amazing things with it in short time ( I worked with one ). But to me I didn't like it, it felt out dated and harder to use than any other scripting language that I've used.
Debuggers may well exist. My initial attempts at getting one running failed, but that was years ago. If there are good debuggers out there I'm happy to admit I'm wrong on that front.
https://raku-advent.blog/2020/12/02/day-1-perl-is-dead-long-...
It was a trial-by-fire implementing new modules in a codebase written by a seasoned Perl programmer who didn't shy away from its esoteric features. Having mostly moved to Python, I can't say I miss the whackiness of the language.
This is actually a giant sore point for me as a programmer. Let me ask the HN collective for advice:
How do you set up an interface for a scripting language in a larger application?
Most applications like KiCad or Blender have their own Python baked very deeply into the software architecture. It works ... mostly ... but it seems to me like its suboptimal
1) you have to jump through an enormous amount of hoops to try to connect your "normal" development environment to the "captive" scripting engine.
2) controlling UI elements from the scripting language is a real PITA
3) you don't have a choice of scripting language
It seems like there ought to be a better way to do this, but I always wind up sort of landing on "open a socket and talk RPC" which has it's own failure modes (for example: how do you expose everything (including the UI) and how do you handle concurrent access).
What is the solution to this?
The way forward seems to be to stick to a single blessed extension language and try to reduce the pain points when integrating with IDE, debuggers etc.
(getting a 503 from the original)
Perl's readability is low, in my opinion, due to a few factors. First and most obvious is the reliance on, well, tons of symbols, resulting in the refrain "executable line noise." The second factor is the philosophy of there being more than one way to do it; this means that you have less local idiom in the language and so you have to spend more time guessing how this programmer did it. The third factor is what I would consider cultural: one-liners. The one-liner is an interesting exercise but it only proves how clever you are in writing the code for a very arbitrary restriction, the number of characters used, and the tradeoff is readability.
Another big arc would be CPAN. So many modules, each covering a different eighty percent of what you needed to do. And heaven help you if you were on Windows for some odd reason because many of those modules needed a compiler, or at least the ones I came across did. The standard library was simply too anemic, and so you were left trying to find just the right package and hope you could work around its shortcomings instead of doing something obvious and getting on with your day.
I do not buy into the network effect of the article. Perl was there before Python, and it was larger than Python for some time.
Culturally, it was a ticking time bomb, waiting to be supplanted by a language that was not a write-once, read-never design. In a similar sense, PHP's culture assured its fast adoption and rise, but also would bring it an ugly reputation, which it still struggles with -- perhaps now unfairly!
And like you said... other languages like python came "batteries included" with a ton of stuff that you'd have to spend quite some time hunting around for on CPAN.
I think the culture has just changed since then and most people aren't into that any more. People now seem to value one clearer way to do everything, and more straightforward terminology. Look at the popularity of much more no-nonsense languages these days.
I think unfortunately Perl just now looks deeply unfashionable, and I think even the context of why it is the way it is and how people saw things back then has sort of been lost so it's somewhat hard to explain to younger people in the community.
What you describe is what the Ruby community was in the early 2000s.
These aren't per-language terms that people have to learn just to use Perl, though are they? 'bless' is. A new term for something that could have been described so simply as 'set-class' or 'give-class' or anything else using plain language.
But I suspect "set-class" or "give-class" would be a bit cumbersome to trip over every time it happens. A relatively core concept should have a relatively short name (in the Perl philosophy of working like a natural language) so we'd still probably have to find something around 5 characters or fewer.
Now look at what bless(8) does on macOS. Not a programming language, but the disconnect between what it says on the tin and what it actually does is quite apparent.
Python was like this as well, the language is even named after a comedy group. Perhaps as the culture has changed, Python has done a better job of adapting (e.g. changing the name of the "Cheese Shop" to PyPI)?
But well, I guess once libraries start to actually appear there, the name change was unavoidable.
Yes. That’s why the packages you download from PyPI are called “wheels”.
The lack of breaking changes between releases, so common in other languages, was a major selling point for me.
Just about every other language I've used, as a high-level coder, would not have stood up to 20 years, but Perl has.
I think of it as a feature-complete language, enough to get what I want done without making me worry about migrations when "old" syntax is "deprecated".
I still start my Perl scripts with "use 5.010", and it is enough for me to generate HTML from text and do whatever else in between.
The whole Perl 6 v.s. Perl 5 branding was a source of friction, but as far as I know the rebranding of Perl 6 to Raku wasn't in any way because Larry was forced to do something. The two communities eventually decided that sharing the same name for two completely different languages didn't make any sense.
Right now C++ and Rust appear to be competing to be the next Perl WRT hieroglyphics in code. The smug and pointless answer to the complaint that the code looks like line-noise is usually "whichever language you use, you have to learn the symbols anyway".
https://cran.r-project.org/web/packages/reticulate/index.htm...
One other thing you can do with Perl is transition very smoothly from one-liner, to stand-alone script, to multi-module systems, as your requirements get more and more complex.
I think the visceral reactions people claim to have to the syntax and other warts are rather sad. Perl certainly has warts but with some determination you can get used to them and become much more productive as a result.
I am not a big fan of OO in general, and it seems the major complaints against Perl include the object system and nested references. I happily avoid those features, and this may be why I don't resonate with the Perl criticisms.
Even though I miss it, it’s hard to justify using Perl for much these days other than the “it’s everywhere by default” reason in enterprise Sys admin environments.
I'm surprised. Many people can't do this.
Honestly haven't seen any perl since a hackthebox machine before covid where you compromise a user with a perl shell.
>In practice, Python has snowballed simply because of network effect. Everyone knows Python so everyone uses it so everyone new has to learn it.
I would interject and suggest this is incorrect. Python has 1 thing that Perl does not.
‘{‘ and ‘}’ and ‘;’ and $`’, ‘$&’
Clearly unnecessary. Python simply does it better. By that simple reality Perl is doomed to death.
>Does the colour of the spoon really matter that much, or is it simply that everyone wants the same colour, regardless of what it is? Do we want to throw away what makes our blue spoons distinctive blue colour just to get in with the "in" crowd, even though we don't actually like green?
This is a very bad analogy. It's making the assumption that all spoons are equally effective. Syntax alone the green spoons are green spoons but Perl's blue spoons have a different handle, 1 with spikes that may hurt you. Why do people use the green spoons? They have scars on the hands from the spikes.
www.wall.org/~larry
Unlike the author, I think there is room for more than one language in town. PHP and Ruby are still around, after all.
Should have used PHP.