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.
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.
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.
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.
Yeah, I agree with you. For fun I built Perl 1 a couple years ago and was amazed at how similar it was to Perl 5. In fact most of the test suite from Perl 1 runs unmodified on Perl 5. The subroutine calling syntax was different (it used `do xxx();` I think) so those tests fail.
But unfortunately, some Perl devs in recent years keep thinking that what they need to do is break stuff to "modernize". They keep eyeing goals like turning `strict` on by default, and eliminating lesser-used features, which will surely break untold numbers of 20-year-old scripts.
I think there is some low-level anxiety among some of their developers that interest in their language has basically evaporated and they keep reaching for a silver bullet that doesn't exist. I think they are crazy ("perl 7... now 10% more like python!") but it's open-source so in the worst case I'm sure someone will keep a traditional perl from bit-rotting.
Curious - is there a reason to use Perl (Wall's latest version, 5 or whatever) in 2022 if one has no familiarity with the language? What would be the major advantage of using Perl over its closest analogues, some bastardization of Bash and Python?
I don't know if its backwards compatibility reaches into the 90s but I've been using ruby for this for like a decade now. Most envs that ship with anything ship with ruby and I've only very rarely run into version problems.
I think people tend to associate it only with a certain era of web dev, but it has remained a good scripting language with a large, consistent, well-documented standard library for a long time now.
Not worth switching off perl since you're very used to that, but iirc ruby was initially conceived as a successor to perl and for me at least it has landed in that role.
I only touched Perl a little bit, at the start of my career in the mid-to-late 00s. I didn't hate it. For our specific use case, which was generating reports from large groups of text-based log files, it was wonderful.
I'm curious, though, do you have any Perl programs you've worked on recently that are public? I'd love to take a look at how people are writing Perl these days...
> 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. http://www.linux-mag.com/id/322/ ("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.") http://www.wall.org/~larry/pm.html 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.
>> Text just isn't a great medium for IPC.
> 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.
I think Unix's refusal to impose arbitrary structure on data is what has enabled a lot of the innovation and experimentation with alternative ways of organising and accessing data. Binary blob, SQL, NoSQL, key/value, column oriented, etc, etc Unix doesn't care. It just gets out of your way and lets you do your thing.
A lot of projects tried to implement opinionated OSes to the point that the OS was really an application. I'm thinking of Sprite and Amoeba, which attempted to abstract out the network and present a unified interface to accessing resources, and fancy storage systems, but in doing so impose opinionated interfaces on that access.
That's half way between an OS and an application like Hadoop, or Kafka, but you couldn't effectively develop something like Hadoop or Kafka, with your own optimisations and implementation tradeoffs on one of these things because the implementations or access models would clash.
Interesting take, but as someone who still works regularly with the shell, I'd say there is still a place for small core utils connected together with pipes/textual streams.
If we're talking parsing and chopping up text files, I can usually whip up something with awk/jq/cut/whatever in far less time than writing an equivalent Python script. There's a threshold where you prefer to switch to the scripting language for maintainability/testing, but the shell won't be going anywhere any time soon.
Having dealt with the clunky record structures of 60s operating systems, they did have their advantages, but the spread of cross-platform tools in the 80s and 90s killed them since Unix only knew byte streams. There are, I think some vestiges of it in the distinction between text and binary files on Windows (assuming that this still exists), but otherwise Unix’s everything is a stream of bytes has won. I kind of miss knowing that I had a file consisting of, e.g., 256-byte blocks.
It fit well with the network code where the other side is never be sure. Text interaction is a good initial way out of it. From old ftp, http, telnet … Xml and even json even if they are “structured” or fsm at least they are text. We can read the log.
I prefer text. Binary is too early optimisation and record oriented is too restricted.
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.
Larry Wall said once that he added sigils in Perl so he could freely add features to the language without conflicting with other's peoples variable names. It's a language design choice that makes sense for Perl's maximalism approach to features.
Perl is very well thought out, in a way that I don't think gets enough credit. For example, the three loop controls (next, last, redo) are four letters long, which makes remembering them easier. In a world where I sometimes have to jump between languages I haven't used in a while, and I'm always forgetting what arbitrary word choice this particular language used for a feature, it's nice to come back to Perl and have a language where the grammar is a little bit less arbitrary.
Other programming languages also have sigils, such as LLVM, etc.
I think that it does not make it less readable.
In some programming languages they will be used to avoid clashes with reserved words, which I think is a good idea.
Some programming languages (such as BASIC) have suffix sigils to indicate data type; some (such as OAA) have both prefix and suffix sigils.
Some programming language may allow multiple sigils together in some cases (e.g. Raku and Free Hero Mesh) (in Raku they called the secondary sigils as "twigils").
The meaning seems to vary depending on programming languages; some are used for similar purposes and sometimes they are used for different purposes.
In Perl, the sigil can indicate scalar vs array (but not numbers vs strings), and in BASIC it can indicate numbers vs strings (but not scalar vs array, which is differently).
...to this day, I still can't wrap my head on how PHP even got to exist in a world where Perl was already filling the web niche just fine.
Also, if they wouldn't have made it too-weird-for-math-and-physics people, Perl would've probably filled Python's niche too.
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.
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.
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.
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.
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.
> People still trying to revive Perl against modern fad, for example, Python.
Lmao Python has been around since 1991 only three years after Perl appeared. How's it a fad? Sucess of python is a testament to the difference a simple and beginner-friendly syntax can make as well as the "batteries-included" paradigm. Most people don't realize how much of a difference these things make especially in removing the initial barrier to get started with programming. There's a reason Go language creators enforced a rigid formatting requirement. It not only improves readability but helps in creating clever tools for syntax checking and other tasks. Readability is key, the fact that Perl code is compatible with that 20 years before makes no difference as they have such bad readability (especially quickly made scripts for sysadmin tasks which no newbie can understand and maintain now). So even for now Python is the best choice for shell scripting, eventually until Go takes over. At this point unfortunately I don't see any area where Perl can make a difference compared to other languages.
I sympathise with your desire to replace shell scripts, but I don't see why that replacement should be Perl of all things. Like you said, Python has displaced Perl due to ecosystem support, so why chase history here?
>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.
"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."
All the standard library ordered as links, by categories that actually make sense!
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.
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.
I would think of languages like Scheme or Smalltalk or C as fitting that label. But not JavaScript or Java or C++.
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.
Perl might fit that bill. C++ manages to be "more" without being postmodernist, IMO.
p.s. This is fun. So what constitutes a Brutalist programming language?
It should be something that:
- Exposes the construction materials
- Implies mass and permanence
- Is usually institutional, e.g. libraries, government buildings, public housing. Only rarely shopping centres or company head offices (which were usually done in the "International" style when Brutalism was a thing).
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.
For almost all languages, Perl included, this onus is mainly on the programmer. You can churn out gritty spaghetti in almost any language. Perl code doesn't have to look like what Perl programmers put out in the 90s. It's an old misconception that people refuse to let go of.
As someone who spent many years loving Perl, I counter that literally every programming language is obtuse and overloaded with meaningless symbols.
And I'd also credit Perl's rise to Lincoln Stein who wrote CGI.pm which was at the time the absolute state of the art for managing web applications with Apache and mod_cgi.
I first encountered Perl as Perl 4, which certainly had the @ and $ sigils. I had been using Perl 5 for a while before using it in any web development. I think that Perl 6 contributed to Perl's decline much more by the long delay and certainly than by anything it had when it appeared.
If I understand right you are saying that the # of symbols Perl employs makes it hard to understand or read, correct?
TL;DR; I would say that you assertion is context sensitive.
- For a junior Perl programmer or an outside expert those symbols are stumbling blocks.
- For an intermediate Perl programmer and up, those symbols are tools that make the code more readable and expressive.
I got two ways of looking at that. First, I would look at Perl in the context of language. It is a more context sensitive language than some of it's close competitors. When you understand those \ $ % @ & sigils you gain the ability to know at a glance the context in which data is being used. Understanding @_, $_, allows you to write shorter code without sacrificing meaning. Part of the Perl philosophy is TIMTOWTDI. Most of those special variables also have an English equivalent. Instead of using $) which I never remember I can use $EGID, or if I think that's not explicit enough then I can use $EFFECTIVE_GROUP_ID to really spell it out.
The second way is that Perl has a steeper learning curve than it's close competitors. I see this like comparing Vim to Notepad++ and Emacs, or Haskell to well most other functional programming languages. Just because it took longer to learn, that doesn't mean it's better or worse at creating good code. It does mean that armchair pundits are less likely to be correct in their hot takes. They lack experience and understanding.
I feel like PHP was the first big blow to Perl's king-of-the-web status. Python and especially Ruby+Rails knocked Perl off many people's radars for good.
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.
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.)
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.
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.
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.
Since you're building it yourself as you go, the language effectively has every 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.
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).
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:
"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."
Post-modernism is not so much about picking-and-choosing and going-your-own-way, but it is 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.
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.
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.
>At the Open Source Developers Conference in Melbourne in December 2006, Perl community member Adam Kennedy gave a lightning talk (a short (5 minute) talk for which he didn't have to submit an abstract) on the CPAN Acme::Playmate module, a joke Perl module designed to download the measurements of Playboy magazine Playmates from the Playboy website. (The 'Acme' namespace in Perl is the joke namespace.) During his talk Kennedy showed (twice) a single still photo of a Playboy model.
>Schwartz often comes up in discussions of sexism in open source because of his open enthusiasm for Hooters restaurants, which he mentions frequently in professional contexts.
>[...] In 2001, Randal's company, Stonehenge Consulting, ran a Hooters Wings Promotion at LISA, a sysadmin conference (an example of booth babes).
>"Stonehenge ran a Hooters Wings promotion at the booth at LISA 2001. We gave away 1000 wings in about 45 minutes, with the aid of two Hooters girls Sarah and Lacey."
>notes on: perl lightning talks, impressionistically rendered» Stumbling into the Perl Lightning Talks now. Randal Schwartz (looks like Randal. Certainly wearing Randal-like clothes. He's the Hooter's guy, right? I always get him and Tom Phoenix confused. Okay, definitely Randal.)
>At OSCON, between 2001 and 2009 (several reports during this period, not necessarily every year), Stonehenge Consulting has held parties on one evening of the conference. At these parties, there are usually women present who are not otherwise connected to the conference. They have variously been reported as scantily clad, present to "entertain" the guests, etc. It is unclear whether these women are connected to the venues in which the events are held or are friends of OSCON attendees.
>Michael Schwern, prominent Perl developer and keynote speaker at the National Center for Women & Information Technology's 2013 summit, was arrested in Portland, Oregon on Sept 19, 2013 on two counts of misdemeanor domestic violence charges against his then-spouse Nóirín Plunkett -- specifically, harassment and strangulation.
>The Perl Foundation is fragmenting over Code of Conduct enforcement. "I'm fresh out of ideas with regards to handling toxicity in the Perl community."
>[...] I have personally used and enjoyed the Perl language for nearly 30 years, and it's distressing to see the bigotry and edgelording coming from prominent elements of the community—not to mention the board's failures to respond decisively. The Perl community is not the first to struggle with "culture wars" revolving around a code of conduct, either, which makes it all the more puzzling why its board seems incapable of formulating one.
>This is not tolerated. By Sawyer X on August 31, 2012 10:46 PM under Rant.
>There had been several posts recently about disgusting sexist idiotic behavior on PerlMonks. Most people know my opinion on these issues very well, but I don't think that's good enough. I think we need to actually bring it up and discuss it. I want to thank all the people who wrote about it and specifically Joe McMahon who both spoke of it on blogs.perl.org and on Perlmonks here. No, this is not to be taken lightly. And no, I will not shut up about this. And yes, my post is probably gonna be long. I'm sorry, but I need to put it out there.
[+] [-] forgotmypw17|3 years ago|reply
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.
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.
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.
[+] [-] richard_todd|3 years ago|reply
But unfortunately, some Perl devs in recent years keep thinking that what they need to do is break stuff to "modernize". They keep eyeing goals like turning `strict` on by default, and eliminating lesser-used features, which will surely break untold numbers of 20-year-old scripts.
I think there is some low-level anxiety among some of their developers that interest in their language has basically evaporated and they keep reaching for a silver bullet that doesn't exist. I think they are crazy ("perl 7... now 10% more like python!") but it's open-source so in the worst case I'm sure someone will keep a traditional perl from bit-rotting.
edit: I had made a short blog post about playing with perl 1: https://rwtodd.org/2020/Jun/building-perl-1
[+] [-] SOLAR_FIELDS|3 years ago|reply
[+] [-] giraffe_lady|3 years ago|reply
I think people tend to associate it only with a certain era of web dev, but it has remained a good scripting language with a large, consistent, well-documented standard library for a long time now.
Not worth switching off perl since you're very used to that, but iirc ruby was initially conceived as a successor to perl and for me at least it has landed in that role.
[+] [-] taeric|3 years ago|reply
[+] [-] scruple|3 years ago|reply
I'm curious, though, do you have any Perl programs you've worked on recently that are public? I'd love to take a look at how people are writing Perl these days...
[+] [-] petdance|3 years ago|reply
Which features do you see as esoteric?
[+] [-] leoc|3 years ago|reply
> 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. http://www.linux-mag.com/id/322/ ("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.") http://www.wall.org/~larry/pm.html 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.
>> Text just isn't a great medium for IPC.
> 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.
[Extra text] added for clarification.
[+] [-] simonh|3 years ago|reply
A lot of projects tried to implement opinionated OSes to the point that the OS was really an application. I'm thinking of Sprite and Amoeba, which attempted to abstract out the network and present a unified interface to accessing resources, and fancy storage systems, but in doing so impose opinionated interfaces on that access.
That's half way between an OS and an application like Hadoop, or Kafka, but you couldn't effectively develop something like Hadoop or Kafka, with your own optimisations and implementation tradeoffs on one of these things because the implementations or access models would clash.
[+] [-] nmfisher|3 years ago|reply
If we're talking parsing and chopping up text files, I can usually whip up something with awk/jq/cut/whatever in far less time than writing an equivalent Python script. There's a threshold where you prefer to switch to the scripting language for maintainability/testing, but the shell won't be going anywhere any time soon.
[+] [-] dhosek|3 years ago|reply
[+] [-] twic|3 years ago|reply
awk has named parameters! Perl was a step backwards!
[+] [-] mjd|3 years ago|reply
[+] [-] ngcc_hk|3 years ago|reply
I prefer text. Binary is too early optimisation and record oriented is too restricted.
[+] [-] andi999|3 years ago|reply
[+] [-] jkh1|3 years ago|reply
[+] [-] lifefeed|3 years ago|reply
Perl is very well thought out, in a way that I don't think gets enough credit. For example, the three loop controls (next, last, redo) are four letters long, which makes remembering them easier. In a world where I sometimes have to jump between languages I haven't used in a while, and I'm always forgetting what arbitrary word choice this particular language used for a feature, it's nice to come back to Perl and have a language where the grammar is a little bit less arbitrary.
[+] [-] hedora|3 years ago|reply
Want to pass me a hashtable of lambdas that return arrays of alternating functions and regexps?
Go ahead. Show me how to invoke it. I'm waitng.
Python (which has all of the type safety and expressivity of perl) allows such abominations to hide behind clean looking syntax.
Sigils also improve readability. Bad Perl looks like serial port noise. Bad Python looks like good python.
(In Python's defense, it has a nice ffi.)
[+] [-] zzo38computer|3 years ago|reply
I think that it does not make it less readable.
In some programming languages they will be used to avoid clashes with reserved words, which I think is a good idea.
Some programming languages (such as BASIC) have suffix sigils to indicate data type; some (such as OAA) have both prefix and suffix sigils.
Some programming language may allow multiple sigils together in some cases (e.g. Raku and Free Hero Mesh) (in Raku they called the secondary sigils as "twigils").
The meaning seems to vary depending on programming languages; some are used for similar purposes and sometimes they are used for different purposes.
In Perl, the sigil can indicate scalar vs array (but not numbers vs strings), and in BASIC it can indicate numbers vs strings (but not scalar vs array, which is differently).
[+] [-] tenebrisalietum|3 years ago|reply
`@array` - array of values.
`$array[1]` - get element 1 of the array.
`$array` - What do you think this does? Why can't we just `@array[1]`?
[+] [-] collyw|3 years ago|reply
[+] [-] catchclose8919|3 years ago|reply
Also, if they wouldn't have made it too-weird-for-math-and-physics people, Perl would've probably filled Python's niche too.
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.
</alternative-reality>
[+] [-] hzhou321|3 years ago|reply
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.
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.
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.
[+] [-] random_cynic|3 years ago|reply
Lmao Python has been around since 1991 only three years after Perl appeared. How's it a fad? Sucess of python is a testament to the difference a simple and beginner-friendly syntax can make as well as the "batteries-included" paradigm. Most people don't realize how much of a difference these things make especially in removing the initial barrier to get started with programming. There's a reason Go language creators enforced a rigid formatting requirement. It not only improves readability but helps in creating clever tools for syntax checking and other tasks. Readability is key, the fact that Perl code is compatible with that 20 years before makes no difference as they have such bad readability (especially quickly made scripts for sysadmin tasks which no newbie can understand and maintain now). So even for now Python is the best choice for shell scripting, eventually until Go takes over. At this point unfortunately I don't see any area where Perl can make a difference compared to other languages.
[+] [-] mvhvv|3 years ago|reply
[+] [-] andai|3 years ago|reply
"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."
Philip Pullman
[+] [-] MichaelMoser123|3 years ago|reply
https://perldoc.perl.org/perlfunc#Perl-Functions-by-Category
All the standard library ordered as links, by categories that actually make sense!
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.
[+] [-] a4isms|3 years ago|reply
"Less is more"—Mies van der Rohe
Postmodernism:
"Less is a bore"—Robert Venturi
—————
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.
I would think of languages like Scheme or Smalltalk or C as fitting that label. But not JavaScript or Java or C++.
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.
Perl might fit that bill. C++ manages to be "more" without being postmodernist, IMO.
[+] [-] a4isms|3 years ago|reply
It should be something that:
- Exposes the construction materials
- Implies mass and permanence
- Is usually institutional, e.g. libraries, government buildings, public housing. Only rarely shopping centres or company head offices (which were usually done in the "International" style when Brutalism was a thing).
What fits that bill? How about SQL?
[+] [-] snorkel|3 years ago|reply
[+] [-] daneel_w|3 years ago|reply
For almost all languages, Perl included, this onus is mainly on the programmer. You can churn out gritty spaghetti in almost any language. Perl code doesn't have to look like what Perl programmers put out in the 90s. It's an old misconception that people refuse to let go of.
[+] [-] tootie|3 years ago|reply
And I'd also credit Perl's rise to Lincoln Stein who wrote CGI.pm which was at the time the absolute state of the art for managing web applications with Apache and mod_cgi.
[+] [-] cafard|3 years ago|reply
Edit: and Perl 4 had the % sigil.
[+] [-] peelle|3 years ago|reply
TL;DR; I would say that you assertion is context sensitive. - For a junior Perl programmer or an outside expert those symbols are stumbling blocks. - For an intermediate Perl programmer and up, those symbols are tools that make the code more readable and expressive.
I got two ways of looking at that. First, I would look at Perl in the context of language. It is a more context sensitive language than some of it's close competitors. When you understand those \ $ % @ & sigils you gain the ability to know at a glance the context in which data is being used. Understanding @_, $_, allows you to write shorter code without sacrificing meaning. Part of the Perl philosophy is TIMTOWTDI. Most of those special variables also have an English equivalent. Instead of using $) which I never remember I can use $EGID, or if I think that's not explicit enough then I can use $EFFECTIVE_GROUP_ID to really spell it out.
The second way is that Perl has a steeper learning curve than it's close competitors. I see this like comparing Vim to Notepad++ and Emacs, or Haskell to well most other functional programming languages. Just because it took longer to learn, that doesn't mean it's better or worse at creating good code. It does mean that armchair pundits are less likely to be correct in their hot takes. They lack experience and understanding.
[+] [-] anthk|3 years ago|reply
To me Perl it's a better tool for anything better than shell scripting without needing to get dirty with C or Go.
[+] [-] scelerat|3 years ago|reply
[+] [-] jlokier|3 years ago|reply
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.)
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.
[+] [-] simonh|3 years ago|reply
>opposition to epistemic certainty and the stability of meaning
Yep, that's Perl.
[+] [-] dmux|3 years ago|reply
[+] [-] eternityforest|3 years ago|reply
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.
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.
Since you're building it yourself as you go, the language effectively has every 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.
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.
[+] [-] noisy_boy|3 years ago|reply
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.
[+] [-] mvhvv|3 years ago|reply
"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."
Post-modernism is not so much about picking-and-choosing and going-your-own-way, but it is 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.
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.
[+] [-] lvl102|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] natmaka|3 years ago|reply
[+] [-] iamalnewkirk|3 years ago|reply
[+] [-] 40acres|3 years ago|reply
[+] [-] mproud|3 years ago|reply
[+] [-] Aperocky|3 years ago|reply
[+] [-] DonHopkins|3 years ago|reply
https://geekfeminism.fandom.com/wiki/Perl_is_my_bitch
>Perl is my bitch was a slogan used by the London Perl Mongers (a Perl user group) and printed on t-shirts ca. 2000.
https://geekfeminism.fandom.com/wiki/Acme::Playmate_talk
>At the Open Source Developers Conference in Melbourne in December 2006, Perl community member Adam Kennedy gave a lightning talk (a short (5 minute) talk for which he didn't have to submit an abstract) on the CPAN Acme::Playmate module, a joke Perl module designed to download the measurements of Playboy magazine Playmates from the Playboy website. (The 'Acme' namespace in Perl is the joke namespace.) During his talk Kennedy showed (twice) a single still photo of a Playboy model.
https://geekfeminism.fandom.com/wiki/Randal_Schwartz
>Schwartz often comes up in discussions of sexism in open source because of his open enthusiasm for Hooters restaurants, which he mentions frequently in professional contexts.
>[...] In 2001, Randal's company, Stonehenge Consulting, ran a Hooters Wings Promotion at LISA, a sysadmin conference (an example of booth babes).
>"Stonehenge ran a Hooters Wings promotion at the booth at LISA 2001. We gave away 1000 wings in about 45 minutes, with the aid of two Hooters girls Sarah and Lacey."
https://web.archive.org/web/20080212061647/https://www.oblom...
>notes on: perl lightning talks, impressionistically rendered» Stumbling into the Perl Lightning Talks now. Randal Schwartz (looks like Randal. Certainly wearing Randal-like clothes. He's the Hooter's guy, right? I always get him and Tom Phoenix confused. Okay, definitely Randal.)
https://geekfeminism.fandom.com/wiki/Stonehenge_OSCON_partie...
>At OSCON, between 2001 and 2009 (several reports during this period, not necessarily every year), Stonehenge Consulting has held parties on one evening of the conference. At these parties, there are usually women present who are not otherwise connected to the conference. They have variously been reported as scantily clad, present to "entertain" the guests, etc. It is unclear whether these women are connected to the venues in which the events are held or are friends of OSCON attendees.
https://geekfeminism.fandom.com/wiki/Michael_Schwern_v._Noir...
>Michael Schwern, prominent Perl developer and keynote speaker at the National Center for Women & Information Technology's 2013 summit, was arrested in Portland, Oregon on Sept 19, 2013 on two counts of misdemeanor domestic violence charges against his then-spouse Nóirín Plunkett -- specifically, harassment and strangulation.
https://arstechnica.com/gadgets/2021/08/the-perl-foundation-...
>The Perl Foundation is fragmenting over Code of Conduct enforcement. "I'm fresh out of ideas with regards to handling toxicity in the Perl community."
>[...] I have personally used and enjoyed the Perl language for nearly 30 years, and it's distressing to see the bigotry and edgelording coming from prominent elements of the community—not to mention the board's failures to respond decisively. The Perl community is not the first to struggle with "culture wars" revolving around a code of conduct, either, which makes it all the more puzzling why its board seems incapable of formulating one.
http://blogs.perl.org/users/sawyer_x/2012/08/this-is-not-tol...
>This is not tolerated. By Sawyer X on August 31, 2012 10:46 PM under Rant.
>There had been several posts recently about disgusting sexist idiotic behavior on PerlMonks. Most people know my opinion on these issues very well, but I don't think that's good enough. I think we need to actually bring it up and discuss it. I want to thank all the people who wrote about it and specifically Joe McMahon who both spoke of it on blogs.perl.org and on Perlmonks here. No, this is not to be taken lightly. And no, I will not shut up about this. And yes, my post is probably gonna be long. I'm sorry, but I need to put it out there.
http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im-cons...
http://www.modernperlbooks.com/mt/2012/08/you-dont-get-to-ch...
http://blogs.perl.org/users/tinita/2012/08/to-be-or-not-to-b...
http://blogs.perl.org/users/lichtkind/2012/08/to-say-schwern...
http://www.perlmonks.org/?node_id=989181
http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im-cons...
https://perlmonks.org/?node_id=989879