I love Perl. I use almost none of its more esoteric features, and just write "classic procedural" code, mostly using command-line utilities instead of third-party modules for anything I don't want to write myself (mainly cryptography), and I am so fucking happy not having to deal with breaking changes in my language, a rare quality these days.<p>I used a machine with a 9-year-old distro on it for a few months, and all my scripts ran without issue, and I have high confidence that they will continue to run for years down the road without my having to adjust them for breaking changes in the language runtime, which is more than I can say for most other stacks I've used.<p>Furthermore, ALL the code examples I can google up will work without me having to check if they're for the right version of Perl, because it has near-perfect backwards compatibility going back all the way to 5.000 from 1994.<p>About the only other thing with a comparable level of stability has been HTML/JS/CSS, which gets a lot of new features all the time, but, for the most part, if I use only minimal features, remains usable for years without modification.
Reposting my old comment <a href="https://news.ycombinator.com/item?id=10774245" rel="nofollow">https://news.ycombinator.com/item?id=10774245</a> :<p>> People seem to have forgotten that when Perl evolved from being a better AWK to the paradigm example of the modern "scripting language", Larry Wall explicitly described this as a rejection of the Unix small-tools philosophy. <a href="http://www.linux-mag.com/id/322/" rel="nofollow">http://www.linux-mag.com/id/322/</a> ("But Perl was actually much more countercultural than you might think. It was intended to subvert the Unix philosophy. More specifically, it was intended to subvert that part of Unix philosophy that
said that every tool should do only one thing and do that one thing well.") <a href="http://www.wall.org/~larry/pm.html" rel="nofollow">http://www.wall.org/~larry/pm.html</a> The fact that getting things done with a Perlesque scripting language is now seen as the height of purist Unix propriety only shows how far gone the original Unix ideal now is. But moving to the scripting-glue model doesn't really get rid of small tools that endeavour to do one thing well, it just reimplements them inside the scripting-language universe as functions/objects, though with a more expressive and less burdensome common language that makes it easier for them to stay small while being correct and effective. The more expressive their shared language, the smaller [the individual tools in] a set of tools can be.<p>>> Text just isn't a great medium for IPC.<p>> Yes, in retrospect Unix's determination to know about nothing but binary or plaintext blobs and streams looks like an adolescent rebellion against the (apparently - I haven't used them) clunky record structures of '60s operating systems.<p>[Extra text] added for clarification.
Perl was the first language I used professionally and I used it almost exclusively for years. I don't understand all the negative comments about its use of sigils, I find them useful and I never got the impression that they made the code less readable but maybe that's because I was never taught the gospel of computer science :)
I also appreciate the extended backwards compatibility. I still occasionally run decade-old code and it's still doing its job which means that writing code in perl was time well invested.
...to this day, I still can't wrap my head on <i>how PHP even got to exist</i> in a world where Perl was already filling the web niche just fine.<p>Also, if they wouldn't have made it too-weird-for-math-and-physics people, Perl would've probably filled Python's niche too.<p>And with that kind of resources focused on it, Perl 6 could've actually turned up into a clean nice new language that would've unified us all by also supporting nice compile-to-wasm.<p></alternative-reality>
Perl is really cursed by the past glory. People still trying to revive Perl against modern fad, for example, Python. Fad are powered by steam of live Eco-systems, which Perl once had, but no longer have. There is no real reason why Perl couldn't succeed where Python does other than the path of history. And there is no real reason to chase history today.<p>Rather than looking for killer app or adding modern features, such as the effort of Perl 6, now Raku, Perl should shed features and focus on stability (which it is fighting hard to retain), on ubiquity (which it had and are losing ground), and core performance (which it is slowly degrading due to features). I think it should try to get a core set into POSIX standard. The core Perl can be like POSIX shell, while a distribution always can distribute a fancier, but always compatible Perl.<p>Perl should replace shell scripting, period. If there is any reason shell scripts is still preferred, then that should be the TOP focus for Perl steering council to address.<p>It really frustrates me to see people today, me included, are still trying to manage basic software engineering in shell scripts. It really amuses me today to listen to pastors on how to write good shell scripts. It really saddens me today to watch efforts of inventing a better shell for scripting.
>Whatever the verb you choose, I've done it over the course of the years from C, sh, csh, grep, sed, awk, Fortran, COBOL, PL/I, BASIC-PLUS, SNOBOL, Lisp, Ada, C++, and Python. To name a few. To the extent that Perl rules rather than sucks, it's because the various features of these languages ruled rather than sucked.<p>"I have stolen ideas from every book I have ever read. My principle in researching a novel is 'Read like a butterfly, write like a bee', and if this story contains any honey, it is entirely because of the quality of the nectar I found in the work of better writers."<p>Philip Pullman
maybe perl code is a bit unreadable at times, but its documentation is very readable.
Just look at:<p><a href="https://perldoc.perl.org/perlfunc#Perl-Functions-by-Category" rel="nofollow">https://perldoc.perl.org/perlfunc#Perl-Functions-by-Category</a><p>All the standard library ordered as links, by categories that actually make sense!<p>Also perl5 used to be very accessible, even the parser error message made actual sense. I think that a lot of care has been put into these details, and that this attention to details did have a role in the success of the language.
Modernism:<p>"Less is more"—Mies van der Rohe<p>Postmodernism:<p>"Less is a bore"—Robert Venturi<p>—————<p>Guided by these famous quotes, if I were to call a programming language a "Modernist" language, I'd think of something that prizes elegance. It can't just be a small language, it has to be a small language with a few features powerful enough to actually do more.<p>I would think of languages like Scheme or Smalltalk or C as fitting that label. But not JavaScript or Java or C++.<p>And if I were to call a language "Postmodernist," I'd expect a language to incorporate historical motifs, whimsey/surprise, and arresting/attention-grabbing features.<p>Perl might fit that bill. C++ manages to be "more" without being postmodernist, IMO.
Perl rose to popularity because early web development was all about text processing (reading web forms and outputting HTML) and Perl made that easier (regex deluxe) than other choices on unix at the time. It became the lingua franca of web developers. Perl 5 made heavy use of symbols so it was visually noisy, and then Perl 6 came along and added even more magic meanings to other symbols, and that was a tipping point of perl’s decline. Readability of code is paramount. Code is for machines to execute and for humans to understand. Perl code became both modernist abstract art, and Baroque in its intricacies.
Perl is a surprisingly Lisp-like language, due to its very consistent approach to closures and statements-as-expressions. Its approach to references, which are reference-counted and have RAII with predictable destructors, is also very clean. I think most people don't notice that Perl is a cleaner and more consistent language in depth than it appears on the surface.<p>Criticisms of Perl often talk about the sigils and other punctuation characters which appear in normal Perl code, implying that's a big issue, or at least rather old-fashioned. (Although I really like Perl and got to know it intimately, especially the guts of the interpreter, I did feel it would have fared better without the sigils.)<p>That might be a fair criticism by modern standards, but if so, it annoys me that Perl gets singled out for punctuation while other popular languages don't. PHP has sigils everywhere, and many languages have some sigils. Rust has quite a lot of special punctuation syntax that has to be written often. Aside from sigils, Rust code looks to me like it has a similar amount of punctuation-oriented syntax as most of the Perl code I used to write.
Perl was the first dynamic language I learned after taking most of my college courses in Java. It was an eye opening experience in many regards: ease of standing up a web app via CGI.pm, dynamic dispatch tables using anonymous sub procedures, an OOP system based on "blessed" data structures, access to the symbol table, etc. In the last couple of years I've gotten into learning Common Lisp and it's surprising how many similarities there appear to be. I'm actually kind of surprised that given Perl's ability to change packages in an ad-hoc fashion that some type of live programming system was never developed for it.
I think this is a pretty great analysis of what's wrong with modernism(Which is unfortunately coming back), the part I disagree with is programmer creativity and "There is more than one way to do it" thinking.<p>The current crop of popular languages does it really well. They aren't designed starting from any kind of simple theoretical construct like stacks or lisps or machine code, but they do always watch your back and prevent many unsafe(Unsafe in the sense that they allow common mistakes that are hard to detect automatically) constructs, while providing equally easy constructs.<p>A lot of the value in moving away from modernist thinking is that you actually have fewer concepts to work with. In programming, the usual goal of minimalism is to let you build exactly what you need.<p>Since you're building it yourself as you go, the language effectively has <i>every</i> imaginable feature, minus any syntactic sugar for any of them. I suppose that's where the idea that all projects eventually include half of common lisp comes from.<p>Perl's rich but predefined set of language and syntax features was a wonderful advancement, but other languages have since combined that with a lot more safety and opinionatedness.
I have written many thousands of lines of Perl. It is great for text processing type stuff but I don't want to deal with the boilerplate associated with marshaling errors through a deep stack of functions and stuff just failing with "undefined" blah and "die" everywhere. I resorted to Try::Tiny as a poor man's exception handling setup - either give me proper exceptions or give me pattern matching (Rust's Option/Result combined with ? operator is great in this regard).<p>Also, TIMTOWDI starts to suck in a team where everyone thinks they can be clever about their style (simpler languages like Golang, which I don't really love, tackle this better). Especially when you have an entire application in the range of 100KLOC written in Perl. My next project after that was in Java, which in all seriousness, felt amazing. Just like Perl felt when I discovered it after having to write tons of shell scripts.
It's interesting seeing this conception of post-modernism 20 years down the track. I think the article almost gets at the point, but overshoots and ends up in navel-gazing territory with:<p>"Look at the big picture. Don't focus in on two or three things to the exclusion of other things. Keep everything in context. Don't go out of your way to justify stuff that's obviously cool. Don't ridicule ideas merely because they're not the latest and greatest. Pick your own fashions. Don't let someone else tell you what you should like. 'Tsall good."<p>Post-modernism is not so much about picking-and-choosing and going-your-own-way, but it <i>is</i> about looking at the big picture and keeping everything in context. Importantly it's not about the total rejection of assumption and consistency, but about critically challenging and analysing them.<p>I think a lot of folks unfortunately continue to approach it in this same way, but in 202X we often make the additional mistake of assuming that the "modernism" that "post-modernism" is rebelling against is our contemporary "modern" society. That often gets misrepresented as a rejection of the enlightenment or some other extreme sounding position, but it's much better understood as a challenge of epistemic certainty and an attempt to break down and understand our ideological assumptions.
When it comes to writing code exploiting a database via SQL (and not needing/liking mappers) the trio Perl, DBI and Perl::Critic seems hard to beat.
The first code base I worked on professionally was Perl. While I admire it's power I never got used to it. It was very difficult for me to read and our code base was pretty large and I didn't feel like Perl handled OOP well at all. When we switched to Python it was like a breath of fresh air.
Jumping in on this late, but I think the haters and some of the lovers miss the point.<p>Perl doesn’t need to be Python. It’s great to be the #20 language.
For years Mr Wall attempted to justify Perl as the manifestation of 90's neohippie culture, as this mashup of weirdness that was cool because it didn't worry about being particularly consistent with itself. I think the worst of it is when he draws parallels with the Dave Matthews Band. Ugh. Nothing screams "I'm soooo dated" like fixating on short-lived youth trends. Perhaps he should've described Perl as "hip hop" but... hmmm...