IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects. Anything beyond array of arrays or hash of hashes was a pain. It was and it still is way superior to Python for hacking of flat files, but once you needed to go beyond a hash the pain was real.
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.
I think they lost it with Perl 6. Perl 6 was a bit late, but it could have been a better rejuvenation for Perl than Python 3 was for Python.
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.
Please note that Perl 6 is no longer a thing: it has been renamed to the Raku Programming Language (https://raku.org). If you want to stay up-to-date, you can check out the Rakudo Weekly News at https://rakudoweekly.blog
Eh, it sorta still is? Not really, but if you spent ten years announcing an upcoming perl6, then you rename it to Raku... There will be confusion, at least.
They should have done what the YAML designers did when they suddenly realized to their great surprise that the language they themselves designed and named was NOT actually a markup language:
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.)
The problem isn't that all this happened, or maybe that is the problem, the problem is that the future of Perl was very confusing for a very long time.
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.
I'm not in the Perl world. I have heard of Perl 6 and know what it is. I've never heard of Raku before this thread. "perl6" and "perl 6" together have 58 matches on this page right now (before my comment). Raku has 28.
I was at the point of deciding whether to focus on Perl or Python when there was the 01Apr "Parrot" gag on Slashdot. This was a couple of decades back.
Then Larry Wall announced Perl6 and focusing on Python while awaiting P6 was an easy call.
Perl 6 wasn't "a bit late" - the path forward meandered for years, so the point even diehard perl fans (me, at the time) questioned whether it could/would ever happen. And as pointed out down thread, the branding completely changed at least once or twice along the way, to the point perl fans of 20 years ago don't even know "perl 6" became something else today.
Where Perl overdid on hackery, Python may have overdone on sugar
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.
As you probably know, contrary to almost every other language out there, Perl was not designed by people with CS degrees adding things that sound cool.
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.)
Ok, then if not actually designed under the influence of LSD, then certainly under the influence of religious fanaticism.
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):
>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.
>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
I think this is a silly line of inquiry at best, but if one were to attempt to take it seriously, surely “there is precisely one way to do it” is an approach that would better fit the “imperialist” frame than Perl’s actual approach.
>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!
>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
I think one could easily make similar arguments about, say, the Internet. But let’s leave it aside. Let me ask you something: even granting it’s true, what does anything here have to do with Perl, beyond guilt by association?
I think it is a stretch to argue that every missionary is motivated by 'Imperialism'. Certainly some may have been in the past, but if one sincerely accepts the tenants of a religion then it isn't surprising one has enthusiasm to spread it. I've seen plenty of evangelists for every ideology under the sun. People who think they are right will go to great lengths to spread their ideas.
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!'.
I think it might be easier to see the point you are making if we substituted some other ideas. For instance, how many of us are ready to argue that freedom and democracy are evil or imperialist ideas? Yet they served as a rationale for the invasion of Iraq.
> There should be one-- and preferably only one --obvious way to do it.
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.
I think this is pretty common though. Most language communities converge on some standard way of doing things. I always try to go along with the philosophy of the language I’m working in, even if I wouldn’t necessarily choose that myself from a blank slate.
I don't think it's a stretch to argue that Christianity is imperialistic, and by extension Christian missionaries are de facto agents of imperialism. However, I think it's a stretch to argue that Perl is imperialistic. :)
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.
> 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 [...] like religious and linguistic imperialism...
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.
That's very interesting. I thought it was odd that so many writing systems for indigenous languages[0] use invented alphabets instead of adapting Latin letters but this makes total sense when the written form is a source of pride and identity.
So, picking a few religious-themed keywords out of a hat, and using this + non programming interests as a strawman basis to attack the whole language as designed by 'religious fanaticism' ? If I have to pick the 'superstitious' side, it would be the side of this argument.
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.
This bigoted, anti-religion, ad-hominem ranting would result in a stern chastisement, or even an outright ban by dang for "ideological flamewar" were it not posted by a user with 14k karma points. And it's far from the only such comment DonHopkins has made on HN (he even continues by quoting Wikipedia rants about "Christian colonialism": https://news.ycombinator.com/item?id=26660365).
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.
Let's stipulate that Larry Wall is a religious fanatic (though I think that's only true if you use the word "fanatic" in a highly nonstandard way). So what? What actual impact has that had on the design of Perl? What features of Perl's design are worse as a result of Larry Wall's religious beliefs or practices? I don't see any sign that any are.
(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 makes it very convenient to express common things in different ways
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.
There are a ton of hacks in the Perl parser and interpreter that use context to support otherwise irregular syntax. For example, autovivification: https://en.wikipedia.org/wiki/Autovivification DWIM is the goal behind TMTOWTDI.
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.
It also means you have to grok the language to reap the benefits. Perl is often judged harshly by those who prioritise ease of use for beginners over linguistic elegance and usefulness. Can you imagine going to China and complaining that Mandarin and Cantonese suck because they're not beginner-friendly or that medicine is a pointless practice because it involves learning many complex terms? I've never understood the "Python for readability" mantra.
I think Larry Wall's theory of language development is interesting and the long term failure of Perl shows interesting ways in which computer language development and natural language development are rather different.
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.
"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
The last real job I did with Perl was just over nine years ago. HTML::TreeBuilder saved just hours, probably weeks, of frustrating work during a web platform transition.
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.
Probably dereferencing, since Perl never had multidimensional datastructures. You'd put a reference to an array into an array value, and then access it with $array[0]->[0] (iirc) to get the first value of the first array. That was the easy way to write it, the much more annoying way was like ${$array[0]}[0] (or $$array[0][0] if you really wanted to? my memory is fortunately fading), I believe, which got really out of hand when you went three or more levels deep.
The syntax for accessing nested indices actually automatically resolves references the way you'd expect. So for the specific case of accessing a single deeply nested value, no special incantation is needed.
So, you can put scalars into arrays and hashes, refs into hashes and arrays, etc, etc. At whatever nested depth you want. But you have to extract pieces later. And Perl, as usual, allows a zillion ways to do it. These are all exactly the same thing:
I can extract something using different approaches, like:
${${${$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];
> IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects. Anything beyond array of arrays or hash of hashes was a pain.
How 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.
They're kinda just a barely-there static-typing system, but damned if that's not way better than none. And if one recalls that monochrome screens used to be a thing, and that syntax highlighting was wonky (because shortcutted to be usable on weak hardware) and/or too computationally expensive for computers for a while after that, one really understands the appeal of the sigils. Perl is one of the most notepad-friendly languages around.
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.
It is pretty similar to Hungarian notation, but it also denotes context. But is it half-assed? I'm not sure. It expresses the type of the variable over a very narrow set of types. If anything you could say that the type system is half-assed. I've thought a lot about this over the years and I have come to believe that it is really a minimal type set that offers an incredibly useful set of abstractions.
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.
Yes, I definitely miss this in Ruby since it also has optional parens for method calls but lacks sigils. Even the most basic-looking expressions can have arbitrarily complicated meanings:
foo.bar = 1
Is that just an attribute set on an object, is it calling a method foo that returns an object containing a bar attribute with a normal getter/setter, or is bar= a method that has arbitrary functionality?
I also like the more explicit operators in Perl that help show context:
$foo + $bar
This is specifically numeric addition and those operands are probably at least somewhat number-like. Yes you can potentially overload it, but by convention, it will still be something like addition, so you don't have to wonder if you are adding, concatenating, appending a list, or something else, because they have different operators.
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.
To me it was the documentation. Whenever I tried to get into it, I only came across books/tutorials(I dont remember) which start with, oh pearl, here are regular expressions. And then a very very unstructured heuristical explanation of regular expressions. Usually gave up at that point.
How were you parsing XML? I've never found it to be a difficult task.
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.
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();
}
> IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects
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.
Odd that there's no mention of PHP: many developers who used Perl/CGI back in the early days of server side development moved to PHP and PHP was much easier for beginners, especially if you wanted to incrementally move from a static to dynamic site. Perl was, in its day, as much the king of web development as it was admin scripting.
It's not just that it was easier, it also ran everywhere, was fast (with mod_php), did not require chmod'ing files on the server, did work even if you uploaded the file with windows line breaks, had parameter parsing and sessions built in. It was pretty quickly superior to Perl for web-stuff in my opinion.
I still like it for CRUD apps and below. you really can't beat just being able to take a plain HTML file and throw a few <?php foreach($array as $row){ ?> in the middle of it
as a quick and dirty web app it feels much more useful then anything else.
I think what changed was that when Perl was popular people were generally a bit more into lots of wacky way to do the same thing, deliberately whimsical terminology, puns in their programs, the program equivalent of creative writing, and being a bit different for the sake of it. I think I had a Perl book at the time that tried to make a serious case for Perl programs being poetry.
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.
Not really a mystery why though, is it? Cute and novel ways to do things are less charming when you’re trying to figure out what earth they do well after the fact to solve some problem.
I’ve heard this a few times but never really saw any of that creative culture working close to a few Perl folks, besides a few funny package names. More a culture of roughness, “hacker cred” and a defensive, short-sighted, we-know-better attitude that left people stranded and is totally not welcoming to creative types. I learned very little during this time.
What you describe is what the Ruby community was in the early 2000s.
My favourite example is the 'bless' function. It attaches a class to an object, if people didn't know. I can't imagine such a name getting approved in any other language. I think any other community would say 'hang on shall we give it a descriptive name that anyone can understand without context, rather than doing this whole faux-religion schtick that will need to be explained to everyone?'
Programming is filled with weird terminology that only means something because we've gotten used to it. String? Method? Abstract method? Stack? Sure, there's a weak link between pre-existing meanings and the programming one, but so is there with bless.
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.
Well, they do mean slightly different things in different languages.
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.
See, that’s not even that funny. Especially followed by the lesson on how it makes total sense to attach a class to an object after its creation and how every other language is doing it wrong. And then the 47 ways blessed objects can trip you up, but they are all obvious because you should know the inner workings of the compiler and runtime or you’re not a real developer!
> I can't imagine such a name getting approved in any other language.
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.
> deliberately whimsical terminology, puns in their programs
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)?
Perhaps my experience with Perl is similar to that of others who have been programming since the 1970s.
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 started with Perl and Python much later (mid-to-late-2000s) and my experience is the opposite. Python programs aged horribly (just after 6 months it could be a half day's work to get the build working locally again) whereas with Perl programs, written correctly with plenty of tests, I could jump into them two years later and everything just worked exactly as where I left it off.
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.)
I think the OP was referring to the readability of the code, versus the build pipeline. I'd have to agree with them - I could never understand my own Perl code 6 months after I had written it, whereas I have little difficulty reading anybody's Python code.
Pipelines or, more in general, an escape hatch within shell scripts when awk doesn't cut it, are indeed my main remaining use of Perl. I used it recently for some JSON processing script, because I couldn't expect jq to be installed and I couldn't even know in advance if the Python interpreter was python, python3 or python3.8, but that was painful...
I still use Perl for occasional one-liners in pipelines as well (where it's simply more expressive than sed or awk), but I've given up on it for scripting in favor of (first) Ruby and (later) Python. About a decade ago, though (long after I'd switched to Python), I found that a regex-heavy program I'd written for processing terabytes of JSON files ran several times faster in Perl than in Python. I wonder if Perl still has a noticeable edge in text processing speed?
A Perl regex is certainly more performant than the Python equivalent however I was surprised to find one of PHP's .ini options enables regex performance which surpasses even Perl's.
I would always use Python over Perl for ad-hoc scripting jobs above a trivial level of complexity, but would worry about its performance vs Perl for more permanent tasks. Worked on a codebase that has a lot of Perl glue, including a lot of text munging, and tbh whilst rewriting that stuff in Python would mean that it's not reliant on grey old geezers to maintain it, I would worry about the performance hit. Wonder if commenters have any explicit comparisons they could share.
I think there is room for a tool that is used for the same purpose as awk and Perl one-liners, but feels more familiar to 2020s programmers. Something that intentionally doesn't scale up to complex scripting, and is designed from the beginning to be relatively readable and learnable for people whose background doesn't already include the old-school command line text processing tools.
> 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.
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.
The obvious answer to me is that the drawn-out, confused, ultimately abortive transition to Perl 6 sucked all the energy out of the ecosystem and it fell behind. Awkward support for OOP and the whole manual reference thing also probably didn’t help. Ruby in a lot of ways seems like a more modern language that is similar to Perl.
That whole mug throwing incident did Perl no favors. They needed to continue competing with PHP and Python at the time with full focus, not start gazing into the future of computing.
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 was my first programming language, however ill-advised, it was what my computational linguistics professors used in 2012.
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.
Having started with more modern scripting languages, such as ruby, javascript, or python, every time I touched perl I felt it was actively fighting me. Those sigils! God, those sigils! It's bad enough that we have to prefix variable names with a dollar sign in php, as if a language parser can't be smart enough to figure out whether you mean a variable or not; but having to use three different sigils for scalar variable, array variable and hash variable, and needing to know when to refer to the same variable with the array sigil or the scalar sigil — this is just vile. Things like $_ or @_ didn't help either.
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 sigils are a feature that underpin perl's roots from practical linguistics (unlike other languages which have roots in theoretical linguistics).
$ - > 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
> The sigils are a feature that underpin perl's roots from practical linguistics
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.
The the distinction in Perl is context. If I want to flatten that pack of dogs into a collection of individual dogs, I'd use the `@` sigil. If I want to operate on the pack as a whole, I'd use the `$`.
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.)
>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!
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??
erg that's one thing I hate about modern tools, they love to use stupid terminology like helm with charts and salt with pillars and all this other childish shit.
Yeah, Helm and K8s are not great in that regard, but the overwrought metaphors do end pretty quickly in favor of naming things for what the actually are.
I suppose that because you can be cruel with somebody without touching it physically. Being brutal involves cruelty + physical violence, thus is more than cruel.
That same feeling of carefree playfulness is also the reason I keep meaning to give Raku a visit. They're pretty explicit about it even with pages like https://raku.org/fun/ and https://raku.org/whatever/. It looks like they've done some interesting stuff around making text-based command line tools really easy to work with, which makes sense since that was a huge part of perl5's wheelhouse, so I think that may be a good place to start digging into Raku.
I have played with Raku a bit over the years, but haven't taken it up for any major projects.
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.
Sigils are for simpler visual parsing - they stand out and mark the 'nouns'. It is not about the compiler - but about people reading the code. I know you can get similar advantages with IDEs colouring the code - here it is in the language itself. I find it useful. I think people just don't like the typography of dollar sign. It is ergonomic because it stands out but it is uglier than other glyphs and that impresses people badly. Later they only look for confirmation of that first bad impression.
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.
In my experience those sigils fell into the same trap that Hungarian notation discovered. A few sigils work well because they provide immediate comprehension, but there's a tipping point where they become noise and a barrier because there's too many, in too many combinations, to be readily understood. In every perl script you end up reading them out loud to parse them.
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.
> Sigils are for simpler visual parsing - they stand out and mark the 'nouns'. It is not about the compiler - but about people reading the code.
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.
The advantage with sigils, that little bit of standardized extra information means that I don't have to do any work to distinguish a verb from a noun. It makes it possible to use names that are just a bit shorter, on average, without sacrificing readability.
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.
> 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.
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.
So an unenforced convention that does the same thing as a sigil, but worse. It can't be relied upon because it's not enforced. I've lost count of how many times I've seen streams without their trailing $ in codebases where people were theoretically using them.
If you can't rely on the symbol or its absence meaning anything, it's just more punctuation.
For me Python is a more ergonomic language. It is easier to read and write. And that led to a sustained growth of Python. Python's popularity exploded in recent years due to data analytics tools using that language, but there was a reason why these tools did choose Python in the first place ...
I think the author is way to generous to the PERL community and the drama of PERL 6. I think the toxicity that eventually led to Larry Wall bowing out is being replicated in Python and Guido leaving. I left PERL for Python in the mid-2000s because it was clear with the Parrot engine and other misguided notions by the PERL bullies that the PERL leadership was bent. Now that Guido is out it will be interesting to see how long Python retains its perch. I think the demise of PERL would have been vastly different if Larry Wall hadn't been forced out.
Larry Wall wasn't forced out of Perl development. He decided on his own to stop actively contributing to Perl 5 sometime before 2000 and to hand it off to others.
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.
That may have played a part, but I feel that a larger problem was the line-noise-like syntax.
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".
One of the factors which lead to Perl's decline is there are too many ways to do it :-)
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.
This was a huge pain in the neck. The rise of Moo/se has helped somewhat.
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 feel like the old Perl saying "There's more than one way to do it" Is what makes Perl a powerful tool for an individual, and an impediment to progress in an organization.
It's possible to be expressive enough in perl that your colleagues cant really fully understand what it is you're trying to accomplish.
>Stepping outside the Perlish echochamber for a moment
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.
I tried to figure out how to do object oriented programming in Perl but got stuck at "an object is a thingy which contains a reference to itself" ...and apparently you had to "bless" that reference?
I've made a presentation on this very subject to a hackers conference in 2013. It's very clear to me, it's because of Perl6. In 2013, Perl was 26 years and Perl6 was 13 years already, half as old as Perl itself but nothing close to production ready.
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...
Focusing on the community is a strange take. I dont know much about Perl6 or care...anymore than I knew anout PHP6. Perl is syntactically complete and has great library support.
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.
As someone who learned both well after the 2000s, it was painfully obvious to me that Python was easier to learn/use and had a lot more momentum than Perl (this was around 2012). I think that's really the nail in the coffin in that they both cover the same scripting niche, but Python won out and less people began to use Perl. Also, Perl5 has a modules approach in that there are several potential OO frameworks like Moose, while Python had it as part of the base language which a lot of people prefer. Python also became a solid data science and numerical methods language, so it ended up winning out. I never thought Perl5 was bad, just not as good as Python. As far as P6/Raku, I think the language design is good, but I won't use something like that professionally until it reaches a certain quality and production readiness. It really is pretty neat and is like a superior Python without the useful frameworks.
Edit: the Python REPL approach was also much better for debugging scripts than how I had to do things in Perl.
In one of my previous positions, part of my work was maintaining legacy build and automation scripts, many of which were written 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.
> 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.
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?
Most Perl jobs today involve either maintenance or modernizing some existing codebase. I wouldn't start a new project in Perl, other than simple scrips that I wouldn't write in bash or a sub 5k loc web service, but I'd probably rather do that one in Node.js.
After working a python shop for few years one thing I always liked was it was rare that you could tell who wrote what bits of code. Not sure why that was... it might have been how the language itself forced certain idioms. But typing this out I also think it could be the shop’s practice of face to face code reviews. Before you’d merge anything into master you’d always snag somebody to sit next to you and look over your code.
So it could have been the language, but it could have been the culture too.
Python and Go are both like that. The language really encourages a single way of doing things, so when a new programmer sticks 20 lines of new logic in the middle of someone else’s file, it quite often aesthetically blends in. I like it, but sometimes there’s a trade off against power and flexibility.
Python has magic methods, metaclasses and decorators, which gives you quite a bit of flexibility when you need it. Maybe not quite to the extent of Ruby, but more than Go.
I've had to read other people's Perl code before, and that experience basically made "flexibility" a bad word in this area for me.
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.
> No needing to explain that the @ symbol is an array, except when reading from it. Then you use $.
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.
"Unrolling @" was a common bugbear amongst Perl programmers and caused a few I know of to leave for Ruby or Python. Normal, parenthesised parameters were considered experimental until not that long ago so is it any wonder Perl failed to compete with Ruby and Python?
The term you are looking for is "pass by reference".
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.
> The term you are looking for is "pass by reference".
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...
> 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 $.
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.
Perl almost encourages obfuscation. Some folks took pride in writing hard to read Perl code - and the language gave them all the rope they could hang themselves with.
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.
This is the correct answer. Python and Ruby pretty much ate Perl's lunch. Depending on whatever you were working, one of those two languages, was almost always a strict improvement over Perl.
The only place really shines comparatively is in CLI one-liners. But even there, awk is usually a better tool.
I agree that Python and Ruby ate Perl, but for me they are not strictly an improvement. Just spoons of a different colour. Python is more novice friendly, but for someone who uses language every day it is not a problem to learn Perl syntax and BCP.
I was doing web development back then, and Perl in your cgi-bin was pretty hot tech, especially compared to c. But then PHP came around, and I never really looked back. I've moved on, and out of web development, and I keep circling back to C, but never perl. Python does pretty much everything I'd want Perl for.
" Also, Perl5 has a modules approach in that there are several potential OO frameworks like Moose, while Python had it as part of the base language which a lot of people prefer."
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.
This right here. I had a project in 2003 that I started in Perl and wanted to do right with OO. That lasted two days. I switched to Python and have never turned back
I like Perl, and find the complaints about sigils weak given how many people swear by POSIX scripting, when there are so many better tools out there like Perl.
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.
I didn't mean to say that sigils were a general issue. Just that they made complex data structures (and thus, OO) more complex...and intimidating for newcomers.
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();
That will print out "whee". Because I "blessed" $foo into the main namespace, calling $foo->test() is calling the subroutine "test" in the main namespace, with '$foo' as the first argument.
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).
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?
The fact that PHP was, in the era of shared hosting accounts, the default scripting language was like a slingshot maneuver around the sun. It's hard to understate the incredible momentum that surge of casual users brought to it that no other language received, and has sustained it over the long, painful modernization that was needed to make it relevant today. More than PHP, we're still using platforms that were begun in that era: WordPress, Drupal, etc. There's still Zencarts out there.
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.
I don't know about quality of design. Python's popularity is largely due to how much it dumbs down and being a first mover in the scientific world. Python has no built-in regex support and its crippled lambdas are nothing more than the indulgence of its BDFL who has a bias against functional programming. Compare that with Matz's approach to language design.
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
Okay, so that's a somewhat different claim and it really comes down to how much you care about an operator versus a extra couple of characters. Most programmers know how to touch-type and do not hammer out regexps so quickly that the difference between:
$foo =~ s/foo/bar/
and
foo = re.sub("foo", "bar", foo)
is a significant factor in deciding which language to use, especially since there are legibility tradeoffs (i.e. escaping) and the Python approach for handling e.g. groups is cleaner for non-trivial code and avoids the chance of accidentally clobbering $1, $2, etc. — a bug pattern I've seen affect people more than once.
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/).
Having been raised into the profession at a time when both Perl and Python were strong, the amount of times I have had to reach for regexes as a frequent solution to a problem is so rare that I can hardly see how it's a problem.
It's about as much of a problem as not having built-in linear algebra operators.
I thought this as well but didn't want to get sidetracked on a specific. Perl was one of my first languages and regexes were one of the big tools I started using, while I was processing text files. Once parsing lines of ASCII stopped being my major task, regexes stopped being a frequent tool.
Arguably, that's good design, at least in terms of actual success. Where is Ruby relative to Python? "Dumbed down" means good pedagogical language--it's always had an advantage there as well in scientific computing. And the strength of its design is seen in the fact that it's still used by very experienced/advanced users.
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's popularity is largely due to how much it dumbs down and being a first mover in the scientific world.
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.
I think two major things, beyond the sheer audacity of it, really slowed Perl6 down. This is NOT meant to sound negative; I basically owe my entire career to Perl. I got paid to write Perl every day from 1993 until 2015, and I still really like the language, warts and all, and love the amazing features/ideas in Perl6/Raku.
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.
This is a very neat and relatively obscure reference, but yeah, Orwant's very considered 'tantrum' was almost certainly the psychological 'kick' Larry needed to get out of a local maxima.
This is exactly it for me. Perl just seemed to be stuck in a stasis with the whole Perl6 mess for over ages while the world moved on. I still maintain some perl scripts and it's great for small tasks, but by the time they got everything sorted out no one under 30 knows perl at all anymore as it seemed like a dead end.
That's pretty much exactly it. The core of the perl community decided that what they really wanted to do was spend their time bathing lazily in their shared hubris, designing (with... surprising patience) a new perfect language. And I don't really blame them, that's a lot of fun.
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.
> 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.
Obviously yes, they entered different niches. But that's true of any technology. The question in my mind is more: if PyPy hadn't been preoccupied with fighting a compatibility battle with all the churn in upstream python, would it have been chosen instead of V8 as the vehicle of the new concurrency revolution? I think there's a reasonable argument that it would have been.
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.
In 2008, I was in charge of standing up a new service at the company that I worked. They were a heavy Perl shop. I considered using Perl 6 for it since it was "just around the corner." After some investigation, we realized that (a) it was not just around the corner and (2) Perl developers were hard to come by. We went with Java/Spring instead.
> 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 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.
> I am sure there are people that easily remember the syntax for returning a reference to a hash of hashes, or whatever.
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;
I wonder if you've hit on a major factor of Perl's decline. Like you say much of Perl's power was leveraging existing unix utilities, the whole duck tape development thing. As more developers started growing up on windows and then macs, fewer developers had knowledge of the tools to tie together. Without the unix tools to tie together, perl's value proposition drops.
I think that may be part of it. For example, if grep (1) doesn't already mean something to a person, they probably won't have an immediate idea about what the grep function in Perl is all about.
I believe this is a major reason. Demographic shift.
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).
I think a related factor is the shift from raw text to databases. Perl's text oriented tools shine (obviously) when there is a lot of text to deal with. There was a lot of that at the dawn of the web.
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.
Link is 503'ed, but isn't Python the main external factor? Who cared about Perl6 other than enthusiasts?
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.
I've been happily using Perl daily for 20 years. I still use it daily, despite slowly moving to NodeJS for most production work. There's just some things that Perl does better than everything else -- text processing and gluing external programs together, namely -- that I very frequently find myself doing.
I love using Perl too (the real one, not Raku) for the same reasons, except I haven't even been using it as long as you (only 4 years or so).
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.
302 comments
[ 3.1 ms ] story [ 295 ms ] threadThat 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....
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?
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.
Here's a modified example where it's not as clear how to deref.
Like:
How 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.
I also like the more explicit operators in Perl that help show context:
This is specifically numeric addition and those operands are probably at least somewhat number-like. Yes you can potentially overload it, but by convention, it will still be something like addition, so you don't have to wonder if you are adding, concatenating, appending a list, or something else, because they have different operators.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
How is that particularly difficult?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.
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
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.
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”.
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.
https://cran.r-project.org/web/packages/reticulate/index.htm...
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.
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.
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.
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".
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
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 :-)
www.wall.org/~larry
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.
Then I discovered Python and haven't looked back.
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:
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:
That will print out "whee". Because I "blessed" $foo into the main namespace, calling $foo->test() is calling the subroutine "test" in the main namespace, with '$foo' as the first argument.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
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
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;
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.
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.
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.