huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird.
And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.
My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.
I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.
Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.
It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.
Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.
I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.
Start https://perldoc.perl.org/perlre.html#Extended-Patterns . I was trying to find an article from many years ago, but either my google skills fail me, or it is dead. Perl's regular expressions haven't been regular expressions for a long time. Beyond that, the ergonomics of perl make them much more useful for things like flow control than in other languages. It's similar to how you can do type matching in Java, but it's ugly, versus a language like Haskell where using type matching simplifies the code.
Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.
With which JavaScript version? At the time HOP was written I remember JavaScript still doing all it's for loops in C-style and there was certainly no arrow syntax to make anonymous JS functions manageable.
There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).
Perl definitely has a lot of non-patterned arcana. For instance,
$| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0.
In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.
Sure, it's got lots of historical baggage, but there are more sensible alternatives to $| - like STDOUT->autoflush(1) - it's not like you have to use the obscure versions of every feature.
That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code.
If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.
Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn.
If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
You have to bare in mind Perls roots are as an awk-like language for the command line. In those instances weird line noise syntax was the idiom and as Perl grew it moved away from that but without breaking compatibility by default.
This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.
Because perl improved over time, but they didn't want to break people's existing code needlessly.
No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of older, 'worse' things.
The concept of giving functions names spelled out with letters that form words that describe their meaning was invented a long time before Perl figured out that doing that was better than overloading a limited set of ASCII punctuation with random abstract unrelated concepts.
You are going to end up perpetually unhappy if you always assume that people designed things the way they did just because of stupidity / incompetence. Perhaps instead you should take a while to think about the reasons why they might have chosen their design. Even if you can't immediately think of a good reason, doesn't mean there wasn't one.
For this particular case, I'm not sure what drove the selection, but I would guess (since the decision would have been made many decades ago!) it was probably based around perl trying to operate similarly to other command line tools of that era, like awk, sed, (or even ed?), so that people could switch to perl and have a familiar environment? But I don't know, nor have I researched it. In any case, perhaps give the designers the benefit of the doubt before assuming their incompetence?
...and how many of them were designed to be sprinkled liberally in the command line?
Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.
Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)
When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.
Whatever happened to the neophyte raising him/herself up to level of the master? Programming seems to be the only profession in which the beginner is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? If you want to grok Perl learn Perl ... thoroughly.
> Programming seems to be the only profession in which the neophyte is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"?
The problem isn't merely that notation is easy/hard, but that people will not only pass judgement about a language (or any other idea), they will also work actively to convince others to agree with them, and oh yeah, that programmers are people too.
> "worse, that he/she expects the language to be dumbed down to make it easier to learn."
And why should "simplify" have the connotation "dumbed down, for dumb people"? Everyone benefits from simpler things with fewer warts and fewer hazards.
I suspect that Ruby has almost no usage. I've only ever heard of using it in a handful of startups from the valley and it's only Ruby on Rails.
Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.
Some things are unavoidable though. Perl hijacking a user space variable to do internal sort management? Bizarre to my mind, and utterly confounding the first time one accidentally runs into it.
I take it you've never done much shell scripting? This part of perl's baggage comes from its roots as a "better" shell/awk/sed. I don't like it any more than you do, but I must say, I wish people would reserve some of the vitriol they have for perl for the shell. Because I gotta tell you Rabbi, perl is a hell of a lot better than shell scripts. And that's even if you compare perl4 (1991-1994 or so?) to the very latest bash or zsh.
edit:
BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)
Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)
Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.
That's not so much Perl hijacking a user space variable as Perl having some single character globals that have special behavior. Really, you usually learn about those early (sorting is common), and if you're using strict like you should be, if you define them and use them they will work as expected until you use a custom sort, in which case you'll track down the error.
In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.
> utterly confounding the first time one accidentally runs into it.
Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.
Developers spend most of their time reading other peoples code, so yes, one does have to learn the less sensible alternatives, if you choose this tool. It's called historical baggage for a reason.
I'm no fan of Perl, but you can use $OUTPUT_AUTOFLUSH instead if you "use English;". So this isn't really a Perl language thing; it's a style thing. Other languages can be made to look really bad with poor style. The question then becomes what is culturally accepted, and what is not.
The problem is that nobody ever tells you these things, the documentation doesn’t cover them and as a result everyone still uses the terrible original syntax.
The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
In Perl `$` is strictly a scalar variable though this can be a reference to an array, hash or object as they are stored as references. Not to be confused with `$` in PHP which simply denotes a variable of any kind. In Bash `$` denotes the value of a variable.
Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.
Favorite syntactic sugar feature: the /x modifier which makes the regex ignore spaces and comments, meaning you can break your regex into multiple lines and comment them.
Have you ever read O'Reilly's "Mastering Regular Expressions" by Friedl? He does a deep dive into the weird guts of regex modifiers.
I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
Friedl's masterpiece was my introduction to server-side programming in 2000. I'd been doing front-end for a few years with Dreamweaver and I was looking-up it's find & replace features in "Dreamweaver Bible 8" where regexes were mentioned as the ultimate weapon. "Mastering Regular Expressions" was referenced in a footnote and fortunately my local library had a copy. My mind was blown. Regex symbols were just so powerful and the examples were mainly written in Perl which added even more power to them. The book was part of O'Reilly's Perl bookshelf so in addition to Friedl's book I bought the other Perl classics - "Programming Perl", "Perl Cookbook", "Mastering Algorithms with Perl" and "Learning Perl". With CPAN downloaded to my local disk I felt like a hitch-hiker setting out on a journey around the world needing nothing more than Perl in my backpack. Those were the days. Now I have to download 200Mb of node_modules before I can get started.
Recently I found some old floppy drives at the back of a drawer. I manager to find an usb disk drive, inserted the floppy, what do I find? Sure enough, Perl code I've written back in 2000! Indeed, those were the days :)
If it was back-end website code it probably used Lincoln Stein's CGI.pm module which was used everywhere though it was a bit of a beast with frequent security updates. I later progressed to CGI::Application for an app which ran a business for 12 years before I converted it to Rails. I always thought Mojolicious was a great Perl web framework but unfortunately it landed just as Rails was picking-up steam.
If you're interested in improved regular expressions, I wuold suggest you have a look at Raku's regular expressions and grammars (formerly known as Perl 6): https://docs.raku.org/language/regexes
Agreed. Regex is a “part of the language” not a bolt on library like you have in Python. It’s one of those cases where you don’t even know how crap regex is in another language if you’ve never used Perl.
I mentioned Boost's Regex in C++ (boost is essentially a different language), but I didn't bother to mention my experiments with regex in C, for example:
I do recommend Haskell. (But do not go into regexes first!)
But even though it has a similar powerful set of operations for regular expressions, people mostly don't use it, because there are better ways to deal with text.
> You learn perl, and you've learned nothing but Larry Wall.
Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose.
Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)
25 years ago is 1995, and around the release of Windows 95, the first 32-bit version of Windows.
A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.
Windows NT was released in July, 1993. Almost exactly two years before Windows 95.
In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)
> Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird.
Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.
Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.
The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.
At least one of the inspirations of Moose, was the object system of Perl 6 at the time (now Raku https://raku.org using the #rakulang tag on social media). To create a Point class that has an x and a y attribute, you'd write:
I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.
Things have moved on. Moose is a bit of kitchen sink. These days you would generally choose Moo first unless you really needed the meta object features. Or to get incremental Moo(se) features you’d use Role::Tiny, Class::Method::Modifiers And Type::Tiny
> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.
I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks.
The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:
my $bar = foo();
my ($baz) = foo();
I firmly believe that context is one of the worst ideas in Perl. There is a good reason why it was not borrowed by other languages. It is far better to expand arrays like Ruby does with * instead.
This is why Raku doesn't have contexts in that sense. All a subroutine or method can ever return, is a single object. Such an object can be a List or an Array, but it is still a single value.
Whether context is good or bad, a success or a mistake, there's no denying it is either one of the most or the most important idea in Perl.
That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing.
That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).
Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.
Perl’s core object system isn’t really an object system, it’s a toolkit for building object systems. Of course this leads to too many ways to do it, so if starting fresh just use Moo
I think that criticism that by learning perl one doesn't get any transferable concepts is bit unfair. Though I no longer program in perl, some of the things I learnt using perl has been useful later too. To list here are some of the "concepts" that I learnt using perl: regexes, some aspects of *nix system programming (fork, zombies, signal handling etc.), modular code organisation (writing/using perl modules), code documentation (aka PODs) imbibing importance of documenting the code.
True learning some other language (say Java) would make familiar with other concepts (say OOP) but perl has its fair share of concepts that one can pick by programming using it.
On the subject of transferrable knowledge, Perl was the first language I learned, and I was always a little bit confused about why every language I learned since then didn't have pronouns, until finally magrittr came along in R and made perfect sense to me, since "." in magrittr/dplyr feels a lot like "$_" (or "@_") in Perl.
And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.