We were wizards – a foreword to Learning Perl (1993)(jwgoerlich.com)
jwgoerlich.com
We were wizards – a foreword to Learning Perl (1993)
https://jwgoerlich.com/we-were-wizards-learning-perl/
129 comments
Perl was my first programming language love. While we've largely gone our separate ways, we still keep in touch and occasionally we still spend some time together.
One such case is adhoc small scripts mid pipeline. There's just certain Perl syntax that's so deeply embedded in me that no matter how much I try to learn sed/awk/tr, I can't help but reach out to my old love in times of weakness and need. I just know how to talk to Perl in the most intimate of ways that's been hard to reproduce in other languages.
I still feel a little like I've betrayed Perl a bit every time I use Python.
Perl, Larry Wall, Randal Schwartz, Tom Christiansen, brian d foy, O'Reilly, and the many other participants of comp.lang.perl.* had such a lasting influence on my programming career. I wouldn't be who I am today as a programmer without having experienced all the Perl community put out into the world.
One such case is adhoc small scripts mid pipeline. There's just certain Perl syntax that's so deeply embedded in me that no matter how much I try to learn sed/awk/tr, I can't help but reach out to my old love in times of weakness and need. I just know how to talk to Perl in the most intimate of ways that's been hard to reproduce in other languages.
I still feel a little like I've betrayed Perl a bit every time I use Python.
Perl, Larry Wall, Randal Schwartz, Tom Christiansen, brian d foy, O'Reilly, and the many other participants of comp.lang.perl.* had such a lasting influence on my programming career. I wouldn't be who I am today as a programmer without having experienced all the Perl community put out into the world.
I picked up the same habit years ago in my first job because we worked with a mix of all the UNIXes (AIX, HPUX, Solaris, etc). Always "perl -pe" instead of "sed" and man oh man you're right perl is amazing for that, its original task
The trend then was towards standardization towards linux, but then that got compromised as that's when macbooks got popular with developers.
The trend then was towards standardization towards linux, but then that got compromised as that's when macbooks got popular with developers.
> Eventually I started expanding my Perl use to a few lines of code at the time, and now I write a few larger (100+ LOC) scripts in it a year.
This was the same road I took in the late 90's - started with simple scripts and ended up with more and more complex scripts when I was learning all the shortcuts. Until the day I could not understand anymore my own code from a few days back :)
This was the same road I took in the late 90's - started with simple scripts and ended up with more and more complex scripts when I was learning all the shortcuts. Until the day I could not understand anymore my own code from a few days back :)
I wonder, is Perl more ubiquitous than Python for these cases?
It is! Modern macOS, fresh install: no Python, no Ruby, but Perl is there. Git for Windows adds Bash with Perl in it. Every linux server has it. You probably can come up with some Docker image that doesn't have it installed, but it comes in as a dependency to a lot of linux software.
The cool thing is that Perl is compatible, and maintaining compatibility is the top priority for Perl developers. so, many distros keep updating it because it's very safe to do so. When many projects switched from GPL2 to GPL3 macOS famously decided to either freeze some bundled tools, switch to alternatives or removed them entirely. It took them years and years, but all this time Perl has been a notable exception.
As a result nowadays you can be very certain that every machine you run your code on has a very recent Perl installed, so you can use many new stuff, too. It's an old language, but the code you can write can be pretty modern, which is nice.
It's still Perl: lots of symbols, some variables get set up implicitly for you, some keywords look silly to modern eyes (`my` to declare a variable, `sub` declares a function). Some newish stuff is handy. Like, these days you can specify types of parameters in function signatures, and it does a rudimentary type-checking for you. And Perl regexes are still better than in ANY language out there, for 35 years and counting!
The cool thing is that Perl is compatible, and maintaining compatibility is the top priority for Perl developers. so, many distros keep updating it because it's very safe to do so. When many projects switched from GPL2 to GPL3 macOS famously decided to either freeze some bundled tools, switch to alternatives or removed them entirely. It took them years and years, but all this time Perl has been a notable exception.
As a result nowadays you can be very certain that every machine you run your code on has a very recent Perl installed, so you can use many new stuff, too. It's an old language, but the code you can write can be pretty modern, which is nice.
It's still Perl: lots of symbols, some variables get set up implicitly for you, some keywords look silly to modern eyes (`my` to declare a variable, `sub` declares a function). Some newish stuff is handy. Like, these days you can specify types of parameters in function signatures, and it does a rudimentary type-checking for you. And Perl regexes are still better than in ANY language out there, for 35 years and counting!
> It took them years and years, but all this time Perl has been a notable exception.
If we take Apple at their word then it's an exception only in that they haven't got round to it yet, not that it isn't also going to be culled -- the Catalina release notes mentioned Perl explicitly alongside the other two:
If we take Apple at their word then it's an exception only in that they haven't got round to it yet, not that it isn't also going to be culled -- the Catalina release notes mentioned Perl explicitly alongside the other two:
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for
compatibility with legacy software. Future versions of macOS won’t include scripting
language runtimes by default, ...
Yep, Ruby and Python got removed very quickly from the system following this announcement. Perl, however, stays. It seems like some components of macOS depend on it and the dependency is hard to remove. It will likely happen but huge kudos to Apple for keeping it up to date meanwhile.
I switched from Python to Perl for a lot of these use cases as the Perl across many target devices is gonna be much the same/largely compatible, and virtually always present, while Python could be some random fucking version or broken or not present.
Perl gets installed wherever `git` CLI is available, generally. I'd say it's more ubiquitous. And it doesn't suffer from the python2/3 split.
Neither does Python, for years now.
I'm pretty sure people are going to be haunted by it for years. I just updated some internal scripts for Python 3 this year.
I believe they should have been Py3 when they wrote them. It was not my decision, but it did become my problem.
I believe they should have been Py3 when they wrote them. It was not my decision, but it did become my problem.
Perl did have a 5.6/5.8 split over unicode, but it wasn't nearly so bad. By the time 5.10 came out, I think everything had been sorted. Or my work changed and I stopped running into code that I needed to patch 'use bytes' into.
not to mention the perl5 / perl6 split
perl6 is now called raku
perl6 is now called raku
Possibly more terse.
For anyone who cares, sed -i'' should be compatible on both mac and linux.
It is not. -i'' is exactly the same thing as "-i", and while GNU sed interprets this as an empty suffix, BSD sed expects -i to take an argument normally, and will treat the next argument as the extension. If you instead use sed -i "", as is appropriate with a BSD sed, GNU sed will interpret that as the empty program and try to read from a file named your actual script.
I hate that behavior of GNU sed (and also of mktemp). Having a flag optionally take an argument is just so weird and surprising, and the syntax is always unexpected and inconsistent.
I don't see it as a flag that optionally takes an argument, but rather a flag that makes an optional argument mandatory.
No, that's how optional flags should work. I mean how specifically -i works. With GNU sed:
-lN, --line-length=N, -l N, --line-length N
All work the same, set line length to N.
-iSUFFIX --in-place=SUFFIX, -i NEXTARG --in-place NEXTARG
Don't all work the same. The argument is only actually taken if it's attached to the flag directly. In the latter two forms, no backup is made.
GNU mktemp is similarly annoying, but different, with the --tmpdir flag.
-pDIR, --tmpdir=DIR, -p DIR, --tmpdir NEXTARG
Only the last one is different. If you use --tmpdir literally without attaching an argument to it, it defaults to $TMPDIR, otherwise it takes in DIR.
This is inconsistent and unpredictable. A flag should either take an argument or not.
I also dislike Python's argparse variable-length nargs behavior for similar reasons. Even with an integer nargs, it makes for an ugly command line, but with variable-length ones it just gets hideous, and can make it impossible to pass an argument beginning with a hyphen to a flag.
-lN, --line-length=N, -l N, --line-length N
All work the same, set line length to N.
-iSUFFIX --in-place=SUFFIX, -i NEXTARG --in-place NEXTARG
Don't all work the same. The argument is only actually taken if it's attached to the flag directly. In the latter two forms, no backup is made.
GNU mktemp is similarly annoying, but different, with the --tmpdir flag.
-pDIR, --tmpdir=DIR, -p DIR, --tmpdir NEXTARG
Only the last one is different. If you use --tmpdir literally without attaching an argument to it, it defaults to $TMPDIR, otherwise it takes in DIR.
This is inconsistent and unpredictable. A flag should either take an argument or not.
I also dislike Python's argparse variable-length nargs behavior for similar reasons. Even with an integer nargs, it makes for an ugly command line, but with variable-length ones it just gets hideous, and can make it impossible to pass an argument beginning with a hyphen to a flag.
We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. And we had too many sigyls and weird symbols and we didn’t see farther than our nose, so we weren’t that good with foretelling things, but only with practical magic.
Even though wizards foretold nPm by inventing CJAN - like Cpan for JavaScript. And also IO::Async and Lehman’s work was very much ahead of NodeJS.
But we were not brave enough to transpire to JS neither .Net, nor JRE so others figured out how to do it better before us… even though we tried.
Finally like all proud wizards we eventually split the magic school in two faculties and went in ever deeper obscurity and magic.
Even though wizards foretold nPm by inventing CJAN - like Cpan for JavaScript. And also IO::Async and Lehman’s work was very much ahead of NodeJS.
But we were not brave enough to transpire to JS neither .Net, nor JRE so others figured out how to do it better before us… even though we tried.
Finally like all proud wizards we eventually split the magic school in two faculties and went in ever deeper obscurity and magic.
POE (2001!) was another async-ahead-of-its-time:
https://www.perl.com/pub/2001/01/poe.html/
https://en.m.wikipedia.org/wiki/Perl_Object_Environment
https://www.perl.com/pub/2001/01/poe.html/
https://en.m.wikipedia.org/wiki/Perl_Object_Environment
the perl community has a way to create cute abstraction that still makes sense ..
> We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world.
The submitted post exemplifies the worst characteristics of what we can call coding culture. Larry Wall was a polarising character. He could be witty but also tiresome.
The C and C++ coding cultures have had their problems too.
Python has been successful as a language and as a coding culture. I don't like the bigotry of the Python community towards other languages, but the openness and focus on coding ergonomics has been different from most (all?) other prominent languages.
It can't hurt to have a couple of MAANA (was FAANG) giants providing material support.
> And we had too many sigyls and weird symbols
This I think is an unfair criticism frequently aimed at Perl by people who haven't reached fluentness. The language is expressive. To attain higher complexity, languages will adopt new symbols and forms. Anyone who knows Python and uses DSLs such as pandas and numpy knows that "sigils and weird symbols" make their appearances in the mutant notation.
Python has its own TIMTOWDI at this point.
The submitted post exemplifies the worst characteristics of what we can call coding culture. Larry Wall was a polarising character. He could be witty but also tiresome.
The C and C++ coding cultures have had their problems too.
Python has been successful as a language and as a coding culture. I don't like the bigotry of the Python community towards other languages, but the openness and focus on coding ergonomics has been different from most (all?) other prominent languages.
It can't hurt to have a couple of MAANA (was FAANG) giants providing material support.
> And we had too many sigyls and weird symbols
This I think is an unfair criticism frequently aimed at Perl by people who haven't reached fluentness. The language is expressive. To attain higher complexity, languages will adopt new symbols and forms. Anyone who knows Python and uses DSLs such as pandas and numpy knows that "sigils and weird symbols" make their appearances in the mutant notation.
Python has its own TIMTOWDI at this point.
> Larry Wall was a polarising character. He could be witty but also tiresome.
To whom? Unless you were working on the Perl language itself, there was no need to interact with him.
To whom? Unless you were working on the Perl language itself, there was no need to interact with him.
I offered to help out with the Perl 6 logo, as I had both experience writing Perl as a career and having gone to art and design school - while also running a printing studio of my own.
I joined the Perl6 dev mailing lists, listened in on them, offered my support, gave a broad stroke on design ideas, backed them up with reasonable arguments and asked for comments. Larry chimed in basically saying, "no, because this sucks" and not too long later the Camelia butterfly[0] thing was born.
So yeah, I bounced.
Larry may be brilliant, but maybe he also has a history of not knowing when to delegate tasks (and trust). And now Perl WAS something, rather than IS something.
[0] https://raku.org/camelia-logo.png
I joined the Perl6 dev mailing lists, listened in on them, offered my support, gave a broad stroke on design ideas, backed them up with reasonable arguments and asked for comments. Larry chimed in basically saying, "no, because this sucks" and not too long later the Camelia butterfly[0] thing was born.
So yeah, I bounced.
Larry may be brilliant, but maybe he also has a history of not knowing when to delegate tasks (and trust). And now Perl WAS something, rather than IS something.
[0] https://raku.org/camelia-logo.png
To clarify, I am OK if Larry shot down a design idea on Perl 6 itself, but there WAS a RFC of design ideas, which I did not contribute because honestly, I am not qualified to design a language.
I am qualified to help design a logo. And if the feedback was, "great ideas, but not the direction I want to go. What about..." or anything similar, that would be a fine way to show that my offer for doing free work is still happily welcome, with reasonable direction from the owner of the project. You know like a discussion.
There's some great OS logos. The Linux Penguin was great. BSD Daemon, etc, etc, etc. I love the camel, but that's not owned by Perl. It's not an impossible task.
I am qualified to help design a logo. And if the feedback was, "great ideas, but not the direction I want to go. What about..." or anything similar, that would be a fine way to show that my offer for doing free work is still happily welcome, with reasonable direction from the owner of the project. You know like a discussion.
There's some great OS logos. The Linux Penguin was great. BSD Daemon, etc, etc, etc. I love the camel, but that's not owned by Perl. It's not an impossible task.
Can you provide a link to this conversation? I'd love to hear your input or see what you proposed.
That cheap logo did serious brand damage...
"Perl 6" in a monotype typeface would have been worlds better.
An elegant logo having "Camellia" is straightforward to design. They could even have some fun, use the fact that Camellia is the Tea plant and lampoon Java (with a flower floating on a cup for example, Japanese style). That would had sent the correct message of "we are back, unafraid to comparisons, and want our throne returned". And would be perfectly inclusive for both men and women.
We all ask the children to name the pets. Is cute, but often we live to regret it. With logos is the same.
We all ask the children to name the pets. Is cute, but often we live to regret it. With logos is the same.
I love it - these are really good, fun ideas.
>> Python has its own TIMTOWDI at this point.
It's Python's dependency management, and there is more than one way to do it:
pip, pipenv, poetry, conda, setuptools, hatch, micropipenv, PDM, pip-tools, egg, ActiveState platform, homebrew, or your operating system's package manager.
Relevant xkcd: https://xkcd.com/1987/
It's Python's dependency management, and there is more than one way to do it:
pip, pipenv, poetry, conda, setuptools, hatch, micropipenv, PDM, pip-tools, egg, ActiveState platform, homebrew, or your operating system's package manager.
Relevant xkcd: https://xkcd.com/1987/
python packaging is nearing "there's no way to do it right"
But I feel like Python is too complex and big to really like now. It was my go-to language in the 2000s as a kind of sweet spot: featureful/library-rich enough for getting things done, but not overgrown with decades of individually-worthwhile complications.
(Not saying it was ever my paradigm for elegant language design or that it's their job to conform to my taste.)
(Not saying it was ever my paradigm for elegant language design or that it's their job to conform to my taste.)
"Larry Wall was a polarising character. He could be witty but also tiresome."
Yes. This. Thank you for calling this out.
Yes. This. Thank you for calling this out.
Yeah, while everyone still discussing on how to do FP in mainstream languages, Higher-Order Perl was published in 2005, placing many of such ideas how we were already doing that stuff in Perl into paper.
Perl allows to come at peace with UNIX being done in C, by exposing similar programing language capabilities, mixed with Lisp like wizardy, without having to deal with C security faults unless required for performance reasons, that could not be improved in any other way.
Perl allows to come at peace with UNIX being done in C, by exposing similar programing language capabilities, mixed with Lisp like wizardy, without having to deal with C security faults unless required for performance reasons, that could not be improved in any other way.
Higher Order Perl is such a gem, one of the best programming books in general.
Forgot most of the Perl I've learned, but I really should go through this book, thanks for bringing it up.
While Higher Order Perl had a lot of neat tricks, they were quite useless in production because they would slow things down significantly with all the subcalls.
Becouse that's like functional programming work :) It is liked by Academia peoples and those that can't be bothered by implementation design.
But in reality it is how reality works: more complicated things consume execution time: a is Int.range(1..3) IS NOT THE SAME AS: "load 1 to register A" - it contains 'if' or few on every single use. Or function call(s).
We need CPU's that support such things natively (or via cooprocesor or something, with atomics and full transactions :) ) or need to accept slow code or layer like OS for "rich types" and "type safety"...
But in reality it is how reality works: more complicated things consume execution time: a is Int.range(1..3) IS NOT THE SAME AS: "load 1 to register A" - it contains 'if' or few on every single use. Or function call(s).
We need CPU's that support such things natively (or via cooprocesor or something, with atomics and full transactions :) ) or need to accept slow code or layer like OS for "rich types" and "type safety"...
The worry with any language dying is the loss of knowledge that accompanies its demise. CPAN has a lot of great libraries that once used to power the early internet. Decades ago, it was in a Perl group / forum that I first heard the term "do not re-invent the wheel" when someone enquired about making some kind of their own CGI framework along with a great write-up about all the unique edge cases that the existing library already handled due to the experiential knowledge it had gained during its development. These were also the times when Oracle DBAs used to love Perl.
CPAN was pretty great, all the good practices around documentation and unit testing as well as quite possibly the first real internet native shared library community complete with beautiful tooling for one step download/install/test and strict curation.
on my first day of my first software internship in the mid 90s, my boss handed me the ora programming perl 5 book and said "read this." it served me well as a swiss army knife for many years.
on my first day of my first software internship in the mid 90s, my boss handed me the ora programming perl 5 book and said "read this." it served me well as a swiss army knife for many years.
Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project.
There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it doesn't count. JSON? You're guaranteed to have both JSON::XS and CPanel::JSON::XS. The list just goes on and on. HTTP clients? You have Furl, LWP::UserAgent, something built atop IO::Socket. TLS with HTTP? LWP::UserAgent::SSL, IO::Socket::SSL, and someone will use Net::SSLeay raw just to watch the world burn. You pull in all of the latter ones courtesy of modules doing API integrations because their authors just have their favorites.
Web? Oh, you want to do web. Mojolicious, Dancer, CGI::Application, just CGI.pm... Granted, at least you won't have libraries pull those in willy-nilly, thank goodness.
There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it doesn't count. JSON? You're guaranteed to have both JSON::XS and CPanel::JSON::XS. The list just goes on and on. HTTP clients? You have Furl, LWP::UserAgent, something built atop IO::Socket. TLS with HTTP? LWP::UserAgent::SSL, IO::Socket::SSL, and someone will use Net::SSLeay raw just to watch the world burn. You pull in all of the latter ones courtesy of modules doing API integrations because their authors just have their favorites.
Web? Oh, you want to do web. Mojolicious, Dancer, CGI::Application, just CGI.pm... Granted, at least you won't have libraries pull those in willy-nilly, thank goodness.
>There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime.
I think this is hyperbole. Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.
There was a progression to things, mostly because of performance reasons why there is a bit of a proliferation. Moose (and the underlying Class::MOP) were about providing a meta-object protocol for Perl which didn't exist before it. As such, it was focused on being correct over fast. A whole community sprang up from stevan's art. Then sartak's Mouse came along and made some performance improvements with some compatibility caveats. Finally, mst's Moo stripped away the "reflection" aspects of Moose to really squeak out even more performance.
MooseX::Declare was always a (beautiful) research project. I spent some time in that space welding POE and MooseX::Declare together. But these weren't suitable for any kind of production code. If you see this live somewhere, you should definitely rip it out lol.
As for TIMTOWTDI, this is sorta why project Andy Lester's Phalanx came about (it was trying to bless a chunk of modules as a sort of smoke test for Ponie (perl5 implementation on the Parrot VM (which was the first step toward a Perl 6, now Raku)). It was trying to provide an opinionated set of high quality libs for SWE.
Unfortunately, working in Perl really requires a bunch of skill and discipline if you want a long-term maintainable project. This means really looking at your dependency tree and making difficult decisions on which libs to use specifically to avoid installing all of CPAN. npm's installing the world behavior was foretold by Perl.
I think this is hyperbole. Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.
There was a progression to things, mostly because of performance reasons why there is a bit of a proliferation. Moose (and the underlying Class::MOP) were about providing a meta-object protocol for Perl which didn't exist before it. As such, it was focused on being correct over fast. A whole community sprang up from stevan's art. Then sartak's Mouse came along and made some performance improvements with some compatibility caveats. Finally, mst's Moo stripped away the "reflection" aspects of Moose to really squeak out even more performance.
MooseX::Declare was always a (beautiful) research project. I spent some time in that space welding POE and MooseX::Declare together. But these weren't suitable for any kind of production code. If you see this live somewhere, you should definitely rip it out lol.
As for TIMTOWTDI, this is sorta why project Andy Lester's Phalanx came about (it was trying to bless a chunk of modules as a sort of smoke test for Ponie (perl5 implementation on the Parrot VM (which was the first step toward a Perl 6, now Raku)). It was trying to provide an opinionated set of high quality libs for SWE.
Unfortunately, working in Perl really requires a bunch of skill and discipline if you want a long-term maintainable project. This means really looking at your dependency tree and making difficult decisions on which libs to use specifically to avoid installing all of CPAN. npm's installing the world behavior was foretold by Perl.
> I think this is hyperbole.
(Looks at the dependency graph) No, it’s a fact.
> Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.
I don’t. But the modules my project depends on (transitively) do, because those modules were developed and last touched during different fad eras. So when the app starts, I have, like, four OO systems, three ways to do JSON, two to do YAML, and four ways to do HTTP in the memory.
Also, the authors of said modules tend to have Egos and Opinions (capitalization intended) that prevent them from converging on common things.
(Looks at the dependency graph) No, it’s a fact.
> Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.
I don’t. But the modules my project depends on (transitively) do, because those modules were developed and last touched during different fad eras. So when the app starts, I have, like, four OO systems, three ways to do JSON, two to do YAML, and four ways to do HTTP in the memory.
Also, the authors of said modules tend to have Egos and Opinions (capitalization intended) that prevent them from converging on common things.
... and now you have Mojo::Base which is kind of like Moo lite with batteries included. Last week I was concurrently programming some Mojo::Base stuff and some python stuff with cached properties, and I way more enjoyed the salience of my intention in the perl code.
No difference to Python dependencies nowadays.
Not really. There is typically just one import for CSV, JSON...etc. It can be hell to get the various libraries to work though.
Bashing Perl is now a meme, but I can never get over what could have been… Python 3000 and Perl 6 had the community all abuzz. CPAN was the amazing Wild West where people were sharing amazing libraries in such a simple way compared to how every other language was still using the likes of Source Forge and possibly even Fresh Meat (GitHub didn’t exist yet).
Don’t fall into the meme trap of hating on Perl. Although it’s only now used in a handful of companies run by OGs and possibly by devops, I urge you to take a look and spend a month using it - really using it. .. because it really is a beautiful language and it really makes Stream-of-Conscious programming the norm
Don’t fall into the meme trap of hating on Perl. Although it’s only now used in a handful of companies run by OGs and possibly by devops, I urge you to take a look and spend a month using it - really using it. .. because it really is a beautiful language and it really makes Stream-of-Conscious programming the norm
Bashing Perl is a meme precisely because of the mentality of the creators of Perl (who set the culture). This "Forward to Learning Perl" epitomizes the mentality: Imagery of wizards, alchemy, breaking all the stuffy rules that quashed creative thought, etc. He even says "bowing down at the Temple of Orthogonality" like orthogonality a bad thing!
It hearkens back to the days when motor cars were curiosities that required frequent tinkering and had no safety requirements. The sky was the limit, but your car could blow up.
Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety. This allows you to use a product with confidence. I had the misfortune of inheriting some cowboy code, and to this day I call a pox upon the writer. His lack of discipline caused YEARS of misery and maintenance costs; far outweighing any temporary benefit he provided.
Newer programmers might not have lived during the bad old days of cowboy coding, but I did. Nothing was documented. Nothing really worked because there was no edge case support. The mentality was "If it was hard to write, it should be hard to understand" and "If you're not happy with it, feel free to modify the code" (their impenetrable code). Basically, pass-the-buck for your own lack of discipline, and then blame the user.
Personally, I'm glad we've moved on towards becoming a serious engineering discipline, complete with UX being a thing.
It hearkens back to the days when motor cars were curiosities that required frequent tinkering and had no safety requirements. The sky was the limit, but your car could blow up.
Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety. This allows you to use a product with confidence. I had the misfortune of inheriting some cowboy code, and to this day I call a pox upon the writer. His lack of discipline caused YEARS of misery and maintenance costs; far outweighing any temporary benefit he provided.
Newer programmers might not have lived during the bad old days of cowboy coding, but I did. Nothing was documented. Nothing really worked because there was no edge case support. The mentality was "If it was hard to write, it should be hard to understand" and "If you're not happy with it, feel free to modify the code" (their impenetrable code). Basically, pass-the-buck for your own lack of discipline, and then blame the user.
Personally, I'm glad we've moved on towards becoming a serious engineering discipline, complete with UX being a thing.
People often forget how bad things were in 2000s. A "serious engineering discipline" usually meant Java and "writing a unit test and five lines of docstring for every get/set method". I'd go for wizards and alchemy any day.
Even today many of the "serious engineers" of the time still roam the industry and show up for interviews every now and then, completely unable to write code. Some even capture younger souls into this trap, a sad picture.
Even today many of the "serious engineers" of the time still roam the industry and show up for interviews every now and then, completely unable to write code. Some even capture younger souls into this trap, a sad picture.
I'm glad you found a corner of this industry with "serious engineering." It's still the wild west in web development. Today the creators of frameworks chase engagement metrics rather than wizardry, but the end result is the same.
Cowboy Coding is not a language thing, it’s a mentality thing. I’ve seen many beautifully crafted Perl projects. “Perl Best Practice” was a thing
> Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety.
That’s the meme, but it’s simply not true.
I’m going to use Python as a basis of comparison because that’s the language which, from my perspective at least, seemed to replace Perl.
> understandability
A lot has been said about sigils but ultimately a language is only as familiar as a developers exposure to it. Python appeared easier to understand for the newbie because it favoured words over expressions but now that Python has matured it’s become just as incomprehensible too.
> predictability
I’ll be the first to admin that there are a couple of really massive footguns in Perl which are remnants of its evolution as a shell tool. But there’s other aspects to the language which are really clever. For example the way Perl does type comparison is much more predictable then Python.
On the whole, I think those languages are about equal.
> reproducibility
CPAN was also light years ahead anything also available at the time. And still is in many regards. For example, Python environments is a mess. Perl is one of the most portable languages out there. Want to change the state of the runtime? Just add a line to the top of your source. Simple.
Python and JavaScript are a completely pain in the arse in comparison.
PHP is another example of a language that gets this right. Few people on here (myself included) will have much love for 2010’s PHP but it just goes to show that a lot of the languages “real programmers” praise do actually suck at a lot of the basic principles.
> measurability
Not really sure what this is intended to refer to. Maybe APMs? Either way, a lot of diagnostics like that came into vogue after Perl’s decline so this isn’t really the fault of the language but more just 3rd party tool writers putting their focus elsewhere.
That all said, don’t be fooled into thinking such tooling doesn’t exist for Perl.
> safety
Perl basically invented unit tests amongst the scripting languages. It also has stricter run modes to differentiate between one time scripts and important business code.
Saying Perl lacks safety demonstrates a lack of experience with the language.
——-
I’ve written production Perl, PHP, JavaScript, TypeScript, Python, C++, Go, Bash, Visual Basic and even Pascal. De-mangled other people’s spaghetti code in all of those languages too. Probably a few languages I’ve forgotten about too. Perl is one of those languages people love to hate but is, in my opinion, one of the most misunderstood.
[edit] I should have added a comment about Perl’s backwards compatibility. Few other languages even come close to the longevity of Perl 5. And that commitment extends down throughout Perl’s ecosystem. With JavaScript I’m constantly scared the next npm update will break the project.
That’s the meme, but it’s simply not true.
I’m going to use Python as a basis of comparison because that’s the language which, from my perspective at least, seemed to replace Perl.
> understandability
A lot has been said about sigils but ultimately a language is only as familiar as a developers exposure to it. Python appeared easier to understand for the newbie because it favoured words over expressions but now that Python has matured it’s become just as incomprehensible too.
> predictability
I’ll be the first to admin that there are a couple of really massive footguns in Perl which are remnants of its evolution as a shell tool. But there’s other aspects to the language which are really clever. For example the way Perl does type comparison is much more predictable then Python.
On the whole, I think those languages are about equal.
> reproducibility
CPAN was also light years ahead anything also available at the time. And still is in many regards. For example, Python environments is a mess. Perl is one of the most portable languages out there. Want to change the state of the runtime? Just add a line to the top of your source. Simple.
Python and JavaScript are a completely pain in the arse in comparison.
PHP is another example of a language that gets this right. Few people on here (myself included) will have much love for 2010’s PHP but it just goes to show that a lot of the languages “real programmers” praise do actually suck at a lot of the basic principles.
> measurability
Not really sure what this is intended to refer to. Maybe APMs? Either way, a lot of diagnostics like that came into vogue after Perl’s decline so this isn’t really the fault of the language but more just 3rd party tool writers putting their focus elsewhere.
That all said, don’t be fooled into thinking such tooling doesn’t exist for Perl.
> safety
Perl basically invented unit tests amongst the scripting languages. It also has stricter run modes to differentiate between one time scripts and important business code.
Saying Perl lacks safety demonstrates a lack of experience with the language.
——-
I’ve written production Perl, PHP, JavaScript, TypeScript, Python, C++, Go, Bash, Visual Basic and even Pascal. De-mangled other people’s spaghetti code in all of those languages too. Probably a few languages I’ve forgotten about too. Perl is one of those languages people love to hate but is, in my opinion, one of the most misunderstood.
[edit] I should have added a comment about Perl’s backwards compatibility. Few other languages even come close to the longevity of Perl 5. And that commitment extends down throughout Perl’s ecosystem. With JavaScript I’m constantly scared the next npm update will break the project.
>> safety
>
>Perl basically invented unit tests amongst the scripting languages. It also has stricter run modes to differentiate between one time scripts and important business code.
Don't forget Tainted Mode! It's 2024 and I still have never seen it adopted in any other language. It's essentially SELinux-lite for variables :)
IMHO Perl lost to Python because of 3 reasons: 1) Google at the time chose Python and it was the new cool startup everyone wanted to work at, 2) Pandas and Numpy weren't matched in the market (I'd even argue this is still true in 2024), and 3) Perl 6 was way too ambitious and scared people off (even though Perl 5 was never going to go away overnight (and still hasn't))
Don't forget Tainted Mode! It's 2024 and I still have never seen it adopted in any other language. It's essentially SELinux-lite for variables :)
IMHO Perl lost to Python because of 3 reasons: 1) Google at the time chose Python and it was the new cool startup everyone wanted to work at, 2) Pandas and Numpy weren't matched in the market (I'd even argue this is still true in 2024), and 3) Perl 6 was way too ambitious and scared people off (even though Perl 5 was never going to go away overnight (and still hasn't))
Back compat is an important thing. A few years ago we took a 250kline from perl 5.8.9 to perl 5.16 in one hit. Out of the entire application under 50 lines of application code needed to be changed (excepting the big bump in cpan module versions). Currently I'm slowly finalising the move from 5.16 to whatever debian stable is currently shipping 5.34 maybe? The biggest pain point is some type safety in the elastic search cpan module. Other than that I've had to slightly refactor some hacky but effective cache invalidation startup code due to a weird `perl -e` bug I found but can't characterise sufficiently precisely to report. The only reason that the perl latest upgrade wasn't done incrementally was because of a super weird unicode bug between perl and the oracle client library which is now out of scope for us.
But I agree perl can have bad management problems because of different people's capabilities, and different people's approach to showing their individuality.
But I agree perl can have bad management problems because of different people's capabilities, and different people's approach to showing their individuality.
> safety
You forgot safe mode and tainting, which while imperfect and has some sharp edges, is a first class construct that when correctly wielded outright prevents classes of attacks like shell or SQL injections or XSS.
Some have been reinventing it in a piggybacked way, and so, partially/poorly (comparatively), e.g Rails's safe/unsafe strings in ActionView.
You forgot safe mode and tainting, which while imperfect and has some sharp edges, is a first class construct that when correctly wielded outright prevents classes of attacks like shell or SQL injections or XSS.
Some have been reinventing it in a piggybacked way, and so, partially/poorly (comparatively), e.g Rails's safe/unsafe strings in ActionView.
Some of the arguments about Perl and bad engineering practice are not entirely without merit. Neglecting 'use strict;' or 'use warnings;' in your script typically makes this more apparent. The language itself however does not attempt to constrain developers in the same way modern languages do, instead the burden of responsible engineering is placed on the developer. The result is people that deal with badly engineered Perl typically become sour to the language itself.
I reserved my criticisms of Perl for things like signal handling and it's implementation OOP(to name a few), but overall it's a good language.
I reserved my criticisms of Perl for things like signal handling and it's implementation OOP(to name a few), but overall it's a good language.
>I'm glad we've moved on towards becoming a serious engineering discipline
To quote the immortal Bender:
>> Oh wait, you're serious, let me laugh even harder.
To quote the immortal Bender:
>> Oh wait, you're serious, let me laugh even harder.
I'm bashing Perl because I'm using it daily today. I have the moral right.
People waxing poetic about their time using Perl back in the late 1990s/early 2000s don't have a vote because they clung onto good bits and have long forgotten the ugly.
> it really makes Stream-of-Conscious programming the norm
Are you sure it's a Good Thing? Really sure? What if you have teammates? What if you have a life? What if you need to revise your stream of consciousness after a year? Still sure?
People waxing poetic about their time using Perl back in the late 1990s/early 2000s don't have a vote because they clung onto good bits and have long forgotten the ugly.
> it really makes Stream-of-Conscious programming the norm
Are you sure it's a Good Thing? Really sure? What if you have teammates? What if you have a life? What if you need to revise your stream of consciousness after a year? Still sure?
I'm currently writing perl with a team, and I find that so long as you write in a way that looks good, there's no issue with other people reading the code either.
And that still happens at stream-of-conciousness.
And that still happens at stream-of-conciousness.
I still use Perl, maybe not daily but yes to weekly, so I have still have skin in the game.
Yes I'm sure.
Yes I'm sure.
Do you develop with Perl collaboratively with teammates?
Last year I finished over a decade on very large Perl project, collaborating within a team. When I joined that project it was already over a decade old a most of the code was much like what you are probably imagining. When I left the project, all the parts we had touched were much like any other high quality modern codebase, and we could almost as readily maintain the decade-old parts (that we had worked on) as the week-old parts.
Having worked in many languages over many decades, I've learned that a high quality codebase is built by high quality developers, largely independent of the languages they use. You can build an unmaintainable mess in any language as easily as you can build a high quality codebase in Perl. I would concede that you can more easily build an unmaintainable mess in Perl than in many languages but that's up to you; you can do most things more easily in Perl than in many languages ;)
Having worked in many languages over many decades, I've learned that a high quality codebase is built by high quality developers, largely independent of the languages they use. You can build an unmaintainable mess in any language as easily as you can build a high quality codebase in Perl. I would concede that you can more easily build an unmaintainable mess in Perl than in many languages but that's up to you; you can do most things more easily in Perl than in many languages ;)
The advantage of bad perl is that it pretty much is immediately obvious on first sight that it's bad perl. Compare with python, it takes thought and time to identify bad python because it's so syntacticly bland.
With python, write enough of it and you'll be able to spot bad python code just fine. If I don't have Perl muscle memory exercised enough, the same problem telling good and bad Perl code exists too, but it's the other way around — it's all bad until proved otherwise.
Not anymore, but I’ve probably worked on the largest Perl code bases in the world, so again… I’m not a Perl noob
I have written Perl solo, and then migrated that Perl into a team setting, and the mindset shift needed is HUGE. I agree with you.
The happy medium is to write your program twice: Write it solo in Perl for rapid thought-to-code, figuring out architectural issues along the way. Then, write it again in Python for scalable collaboration using the revised architecture. This gives you a working solution for the problem FAST and adheres to "Do it, then do it right".
Unfortunately, this doesn't scale to systems. I do hope LLM-driven transmogrification becomes a real thing.
The happy medium is to write your program twice: Write it solo in Perl for rapid thought-to-code, figuring out architectural issues along the way. Then, write it again in Python for scalable collaboration using the revised architecture. This gives you a working solution for the problem FAST and adheres to "Do it, then do it right".
Unfortunately, this doesn't scale to systems. I do hope LLM-driven transmogrification becomes a real thing.
I’ve never done Perl but would writing solo in Perl and then rewriting it again in Perl with a team be an option?
I have an affection for both Forth and Lisp, two languages that have also been called highly productive but write only.
I think a working early version- even if its a spreadsheet- is 10x of a supposedly 80% done version of something else. The latter of which I must now return to unfortunately…
I have an affection for both Forth and Lisp, two languages that have also been called highly productive but write only.
I think a working early version- even if its a spreadsheet- is 10x of a supposedly 80% done version of something else. The latter of which I must now return to unfortunately…
Interesting this stream of consciousness analogy.
I use Perl a lot because it doesn't get in the way. The functional aspect of it lets you map from problem to solution easily.
I use Perl a lot because it doesn't get in the way. The functional aspect of it lets you map from problem to solution easily.
Stream of consciousness programming?
Perl has a weird way of letting you go from thought to code, and disappearing in between, unlike any other language I've ever used. You really can go from idea to functioning system as fast as you type without a lot of pre-planning. It's hard to describe, and the style has fallen out of fashion for more formal, easier to share between humans languages like Java or python, which feel like they introduce an inherent friction in that transition layer as a tradeoff for scalable teams and readability.
I miss it, but understand why it fell out of favor. It's the closest I've ever gotten to singing whalesong with a machine.
I miss it, but understand why it fell out of favor. It's the closest I've ever gotten to singing whalesong with a machine.
I love this subthread; I've tried to explain this for years and I've concluded it's simply impossible to convey to someone who never experienced it. It's sad, and really frustrating, to just hear the same clueless comments and memes repeated. So I'm glad to see there are still people around who know what it was like to work with a truly expressive language.
About 15 years ago I was put on a Java project that ran for a year with half a dozen developers toiling away (along with an outsourced team that management eventually added to write unit tests). I spent half that time fighting with Eclipse and the other half divided between tearing my hair out trying to wade through the AbstractSpringFactoryInterfaceAbstractFrameworkInjectorAbstractionBuilder nightmare, being lectured at by people who learned everything they know about computers from in-flight magazines that this is the way professional software development is done, waiting for the one person who could actually build the application (which he did partly by unzipping the jar files and manually tweaking their contents), and actually coding.
To my complete lack of surprise, the project never achieved a working milestone and was cancelled. What did surprise me was that a coworker who was sympathetic to my grumbling persuaded the CTO who was trying to rescue the project to let me try it my way. On my own (using Perl and PostgreSQL), in a couple of weeks, I had a fully working prototype. We got the green light to proceed and built the company's flagship product on that stack. It was not my brilliant engineering as much as Perl's extraordinary ability to connect mind and machine (coupled of course with my brilliant engineering) that made it possible. I owe Larry Wall for a huge career boost.
About 15 years ago I was put on a Java project that ran for a year with half a dozen developers toiling away (along with an outsourced team that management eventually added to write unit tests). I spent half that time fighting with Eclipse and the other half divided between tearing my hair out trying to wade through the AbstractSpringFactoryInterfaceAbstractFrameworkInjectorAbstractionBuilder nightmare, being lectured at by people who learned everything they know about computers from in-flight magazines that this is the way professional software development is done, waiting for the one person who could actually build the application (which he did partly by unzipping the jar files and manually tweaking their contents), and actually coding.
To my complete lack of surprise, the project never achieved a working milestone and was cancelled. What did surprise me was that a coworker who was sympathetic to my grumbling persuaded the CTO who was trying to rescue the project to let me try it my way. On my own (using Perl and PostgreSQL), in a couple of weeks, I had a fully working prototype. We got the green light to proceed and built the company's flagship product on that stack. It was not my brilliant engineering as much as Perl's extraordinary ability to connect mind and machine (coupled of course with my brilliant engineering) that made it possible. I owe Larry Wall for a huge career boost.
LOL are you me? This is exactly what happened to me! Same situation, Java with an external team, project over budget and over time, gets canned and then a few weeks with Perl and it’s done
Large teams themselves become boat anchors towards progress. But you’ve inspired me to spend a little time with Perl.
I so much feel the same. At the time I was writing Perl, each line made so much sense, as if I was speaking my mother tongue. It was clearly an extension of my brain.
Never had that feeling with any other programming language, and it took me years to eventually let Perl go and try to wrap my head around Python.
I wonder how much Larry Wall's background as a linguist has to do with that, which perhaps also explain some of Perl's "messier" features, just like natural language is kind of messy.
I once had a long conversation about this with a linguist and Perl programmer that I randomly met in a pub. However, I was quite drunk and don't really recall too much, and we never saw each other again.
I once had a long conversation about this with a linguist and Perl programmer that I randomly met in a pub. However, I was quite drunk and don't really recall too much, and we never saw each other again.
This is quite an interesting phenomenon, and kind of explains why perl is disliked so much.
Computer programming theory has large swathes of inspiration from theoretical linguistics - think lisp. That's nice for theoreticians because it makes things like parsing easier to think about rigorously. Perl on the other hand, to my knowledge is the only significant programming language to be inspired by practical linguistics, and therefore appeals to concepts like context and ambiguity way more than other languages. This means that a lot of computer scientists academics absolutely hate it, and so it was very much neglected in the education space.
The other side effect of this is you still get a good number of talented programmers with backgrounds in the humanities and social sciences who do very well on perl.
Computer programming theory has large swathes of inspiration from theoretical linguistics - think lisp. That's nice for theoreticians because it makes things like parsing easier to think about rigorously. Perl on the other hand, to my knowledge is the only significant programming language to be inspired by practical linguistics, and therefore appeals to concepts like context and ambiguity way more than other languages. This means that a lot of computer scientists academics absolutely hate it, and so it was very much neglected in the education space.
The other side effect of this is you still get a good number of talented programmers with backgrounds in the humanities and social sciences who do very well on perl.
Exactly this.
As fast as you type you're coding. Even though I've now spent years in other languages compared to Perl, it's still stop-start in every other language.
I've said it many times, but Perl really moulds to your brain rather than the other way around. You bend Perl how YOU want it.
As fast as you type you're coding. Even though I've now spent years in other languages compared to Perl, it's still stop-start in every other language.
I've said it many times, but Perl really moulds to your brain rather than the other way around. You bend Perl how YOU want it.
> Perl has a weird way of letting you go from thought to code, and disappearing in between, unlike any other language I've ever used.
Funny, a lot of people say that about Lisp...
Funny, a lot of people say that about Lisp...
As a medium long time perl guy who's been dragged kicking and screaming to do a bit of python recently I'm going to repeat this here:
Python and perl are actually pretty much exactly the same - analogous to the Judean People's Liberation front versus the People's Liberation front of Judea. However the languages are optimised for a slightly different purpose. Python helps you to think more like the computer does, whereas perl helps the computer to think more like you do.
Python and perl are actually pretty much exactly the same - analogous to the Judean People's Liberation front versus the People's Liberation front of Judea. However the languages are optimised for a slightly different purpose. Python helps you to think more like the computer does, whereas perl helps the computer to think more like you do.
This can be nice in Python. The `dis` module makes execution pretty transparent, & it's easy enough to know what bytecode a given line will compile to (granted, comprehensions creating closures does make that a bit harder)
CPython's implementation is also straightforward enough that you can look up ceval.c to get a gist of what an opcode is doing
CPython's implementation is also straightforward enough that you can look up ceval.c to get a gist of what an opcode is doing
I associate this with what we used to call "one-liner programming": I would write a single line of Perl code (in bash, prefixed with `perl -Mwarnings -MDebug -E'<code here>'`, convince myself the code did what we needed, and then share it around as a paste in irc / chat / whatever. It was amazing what you could achieve with the right modules, and Perl's flexibility allowed your mind to roam freely.
Incidentally, the fact that you cannot write this type of one-liner in any meaningful way with Python is one reason I do dislike that language.
Incidentally, the fact that you cannot write this type of one-liner in any meaningful way with Python is one reason I do dislike that language.
About Python, are there practical situations outside IRC where you can't include a newline in there? This ..
python -c '
import re, sys
for line in sys.stdin: print(line.lower().count("foo"))
'
You can do that as a one-liner (I have kept the unused “re” module import, to keep it as close to your code as possible):
python -c 'import re, sys; print("\n".join(str(line.lower().count("foo")) for line in sys.stdin))'
python -c 'import re, sys; print(*(line.lower().count("foo") for line in sys.stdin), sep="\n")'
python -c 'import re, sys; set(print(line.lower().count("foo")) for line in sys.stdin)'
[deleted]
It's sad that Perl is dying a slow death. Between Python and Perl, both styles of coding are possible.
While Python is my preferred language for most tasks, I still use perl as an ad hoc stream processor with `perl -pe` and nothing really beats it at the task. Anything more than 10 lines and I find python easier to deal with (or at least it's my comfort zone).
While Python is my preferred language for most tasks, I still use perl as an ad hoc stream processor with `perl -pe` and nothing really beats it at the task. Anything more than 10 lines and I find python easier to deal with (or at least it's my comfort zone).
Perl was the first programming language I worked with at a real, paying job. I don’t miss that job, but it did teach me a lot about how to deliver value quickly (Perl is still better at smashing 400 million lines of text than most other languages), and some of the impediments to that (Perl’s “write only” syntactic approach).
For all of Perl’s shortcomings, I’ve always felt that no other language came with Larry and Randall’s sense that programming was fun. The Perl folks always understood that our skills were rare, and the powers they conferred were inherently magic - even if a bit dorky.
For all of Perl’s shortcomings, I’ve always felt that no other language came with Larry and Randall’s sense that programming was fun. The Perl folks always understood that our skills were rare, and the powers they conferred were inherently magic - even if a bit dorky.
Indeed, I started programming early (age 9 or so) and have always seemed to have a talent for programming, but also just a sense that it's fun to work out how to express steps in terms of smaller reusable steps.
Now thanks to Devin, anyone can have that skill!
But AI can never replace the human dorkiness I bring to a project.
You should try asking ChatGPT about Lord of the Rings esoterica. You might be surprised.
So I was doing Perl at this time on Wall Street, basically using it to replace shell-based abominations with something faster and easier to maintain. Perl 4.
Being in-process certainly sped things up. And it was easier to understand than the shell based solution.
But it would have been easier to write and read in just about any other language.
Perl 4 at the time only had very primitive data structures. Most of the time you were concatenating and splitting strings together to mimic real data types. The baroque way file handles were a first class data structure made abstracting over them painful and hacky.
That $foo and @foo and %foo were different variables caused innumerable bugs.
The exposure of function arguments as a stack directly in the language made for weirdness all its own.
The mimicry of shell expressions brought its own pain.
And finally, Perl’s greatest strength and horrific weakness: the regular expressions. One liners that would bring tears to your eyes the next time you had to debug it.
I get where Wall was going with Perl, but the emphasis on beautiful natural language for various idioms really crippled the language horrifically from the start. Going into Perl was forgetting nearly everything you knew from other languages and entering this unreal fantasy forest of code, with monsters lurking behind every rock and twist in the road.
Being in-process certainly sped things up. And it was easier to understand than the shell based solution.
But it would have been easier to write and read in just about any other language.
Perl 4 at the time only had very primitive data structures. Most of the time you were concatenating and splitting strings together to mimic real data types. The baroque way file handles were a first class data structure made abstracting over them painful and hacky.
That $foo and @foo and %foo were different variables caused innumerable bugs.
The exposure of function arguments as a stack directly in the language made for weirdness all its own.
The mimicry of shell expressions brought its own pain.
And finally, Perl’s greatest strength and horrific weakness: the regular expressions. One liners that would bring tears to your eyes the next time you had to debug it.
I get where Wall was going with Perl, but the emphasis on beautiful natural language for various idioms really crippled the language horrifically from the start. Going into Perl was forgetting nearly everything you knew from other languages and entering this unreal fantasy forest of code, with monsters lurking behind every rock and twist in the road.
Perl was one of the first languages I learned and also the first language I used commercially. I have a huge soft spot for it as a language. Still love Perl regular expressions like no other. I loved the camel book and its various footnotes with both humour and deeper knowledge on a topic.
Right there with you.
No language even comes close to Perl’s regex support. First class support for regexes as programming tools, and unparalleled speed.
No language even comes close to Perl’s regex support. First class support for regexes as programming tools, and unparalleled speed.
I attended Sun’s road show announcing Java to the world in 1996 (IIRC) and when I asked about regular expression support, I was shocked that it not only didn’t have it built into the language syntax, it wasn’t even available in the library.
As a die-hard Perl fan, that seemed a ridiculous oversight for a language being promoted for Internet programming.
As a die-hard Perl fan, that seemed a ridiculous oversight for a language being promoted for Internet programming.
not only didn’t have it built into the language syntax, it wasn’t even available in the library.
Did not know that about the first Java release. That shit is bananas.
Did not know that about the first Java release. That shit is bananas.
The Perl Journal had that flavor too. I hardly ever read it because I had no interest in actually coding Perl, but it was great to see this kind of culture on the magazine rack at Borders or wherever.
Like everything else, Perl has its warts - tacked on object orientation, crude way of handling errors, lack of a decent REPL, way too much expressiveness (I have seen what happens to a few hundred thousand lines of Perl code written by developers who, instead of writing in a maintainable consistent style, tried to show their cleverness and the language was a willing ally to that) etc. Many words have been spent on those shortcomings so I want to focus on the other side.
Many eons ago, I remember me (and my team) being so tired of writing bash wrapper scripts - we just didn't know any better. To my surprise/delight, I discovered that the Solaris boxes we were using came with Perl pre-installed (which in hindsight is totally expected). So I decided to learn about it the proper way and the Llama book was exactly what I needed.
People have called Perl code line noise. But when I read the book for the first time, everything make sense to me because my mind likes mnemonics. $ is for ($)calar, @ is @(rray), % has a pair of circles like key/value pair and so on. I didn't find it odd that you'll get the array in list context and count in scalar context - it made complete sense. Till date, Perl is the language which I reach out for short-term tasks which need to be done immediately, because it helps me get the job done at the speed of thought.
I picked up some bash scripts as candidates to be re-written in Perl and I will never forget my mind being blown by the sheer lightening speed of Perl scripts; stuff that took many seconds or even minutes in bash were done in a second or less, even with my unrefined code. It was like a new world opened up and indeed, I felt like a wizard.
Many eons ago, I remember me (and my team) being so tired of writing bash wrapper scripts - we just didn't know any better. To my surprise/delight, I discovered that the Solaris boxes we were using came with Perl pre-installed (which in hindsight is totally expected). So I decided to learn about it the proper way and the Llama book was exactly what I needed.
People have called Perl code line noise. But when I read the book for the first time, everything make sense to me because my mind likes mnemonics. $ is for ($)calar, @ is @(rray), % has a pair of circles like key/value pair and so on. I didn't find it odd that you'll get the array in list context and count in scalar context - it made complete sense. Till date, Perl is the language which I reach out for short-term tasks which need to be done immediately, because it helps me get the job done at the speed of thought.
I picked up some bash scripts as candidates to be re-written in Perl and I will never forget my mind being blown by the sheer lightening speed of Perl scripts; stuff that took many seconds or even minutes in bash were done in a second or less, even with my unrefined code. It was like a new world opened up and indeed, I felt like a wizard.
I love the glyphs in APL, but not so much with Perl as they don't seem consistent. Like there is an "of that's an array, but you're accessing it with scalar context" or some catch.
With Python, you have lists, tuples, and dictionaries. Those are data structure objects that are useful for different things. Tuples use (), lists use [], and dictionaries use {}. After you learn that, you just learn the few methods and manners to populate them and you're done.
There's nothing wrong with either way of course. Both appeal to different kinds of folks.
With Python, you have lists, tuples, and dictionaries. Those are data structure objects that are useful for different things. Tuples use (), lists use [], and dictionaries use {}. After you learn that, you just learn the few methods and manners to populate them and you're done.
There's nothing wrong with either way of course. Both appeal to different kinds of folks.
I was interested to learn on a recent episode of FLOSS Weekly [1] that Randal Schwartz had moved on from Perl somewhat and is now effectively an MVP and trainer of Dart and Flutter.
[1] https://hackaday.com/2024/01/09/floss-weekly-episode-765-tha...
[1] https://hackaday.com/2024/01/09/floss-weekly-episode-765-tha...
Schwartz basically rode his early fame into the ground. While the world was moving on from Perl (especially after the community completely fractured and started disintegrating during the early days of Perl6, now Raku), he doubled down, but also didn't really produce much or engage with community. The Perl work around the world was drying up. He ended up begging online instead of pivoting. Glad to know he finally did pivot.
This is a fair observation. At most, my FLOSS Weekly fame was still propelling my career, but I also gave that up after 13 years. It took a while to find my Dart/Flutter groove, but here I am.
Every time I see a Polish domain name I am reminded at how obsessed that country is with Perl.
Speaking of that:
.sh Saint Helena
.py Paraguay
.rs Serbia
.md Moldova
.tf French Southern and Antarctic Lands
.cc Cocos Islands
.so Somalia
.bz Belize
.ps PalestineLearning Perl is imho the best book for beginning to code. It is clear, as short as it can be, fun, explains why not just how, encourages efficiency, has exercises, etc.
To this day I still recommend it even if opportunities to use Perl are gone.
To this day I still recommend it even if opportunities to use Perl are gone.
And, the latest edition of Learning Perl covers up to v5.34. I also provide additional exercises in Learning Perl Exercises (<https://leanpub.com/learning_perl_exercises>), and cover new features in Perl New Features (<https://leanpub.com/perl_new_features>) so I can update it faster than the paper books.
But yet, Randal had beat into me the idea of explaining "why" on everything. You'll notice the basic pattern in Learning Perl and my other writing is that we show the expedient thing, tell you how that fails, improve that a little, show how that fails, and end up at a better final solution. That path shows quite a bit that's ancillary to the task at hand, but also shows how the pieces work together and how different parts affect the solution. I'm usually frustrated by other language tutorials where they say "just do this" without saying anything about why the various parts are there.
Learning Perl was originally written with a C programmer audience, so it assumes that the reader is comfortable with ideas such as variables and looping. I have another book I might recommend for beginning to code: Squeak: Learn Programming with Robots. Sure, it's Smalltalk and literally written for teenagers, but I think it works. It reminds me of the fun days of Logo.
But yet, Randal had beat into me the idea of explaining "why" on everything. You'll notice the basic pattern in Learning Perl and my other writing is that we show the expedient thing, tell you how that fails, improve that a little, show how that fails, and end up at a better final solution. That path shows quite a bit that's ancillary to the task at hand, but also shows how the pieces work together and how different parts affect the solution. I'm usually frustrated by other language tutorials where they say "just do this" without saying anything about why the various parts are there.
Learning Perl was originally written with a C programmer audience, so it assumes that the reader is comfortable with ideas such as variables and looping. I have another book I might recommend for beginning to code: Squeak: Learn Programming with Robots. Sure, it's Smalltalk and literally written for teenagers, but I think it works. It reminds me of the fun days of Logo.
There's a lot of really good Python books too (and I have a 5 foot stack of Perl books). I read one for Python in 2012 that finally got me into coding a lot. People overlook how the basic building blocks of Python are very simple. I learned Perl after Python and it's fine, but I often found Python to be a bit clearer and more obvious than Perl.
If I had to use a language just for Unix scripting, it would probably be Perl though.
If I had to use a language just for Unix scripting, it would probably be Perl though.
If some old soul is up for it, Exercism Perl track could use improvements in concepts.
Worth noting that Exercism is (or at least was at the beginning of the year) experiencing a bit of a funding problem. It would be a remarkable shame if it were to go away, or be less accessible. Such a great resource.
I liked Perl for text parsing and that kind of work.. Used it professionally for about 3 years.
Two things i didn't like about it which i still don't
1. It's a conceptually huge language. There are several things to learn to be effective or you fall into the problem when the 10% that you use is different from the 10% that your teammates use. I found python attractive because of this.
2. I disliked Walls book. It was long winded and very hard to sit down with when I wanted to find something. I expected something like K&R but found it tedious and boring.
Two things i didn't like about it which i still don't
1. It's a conceptually huge language. There are several things to learn to be effective or you fall into the problem when the 10% that you use is different from the 10% that your teammates use. I found python attractive because of this.
2. I disliked Walls book. It was long winded and very hard to sit down with when I wanted to find something. I expected something like K&R but found it tedious and boring.
IMHO, Python is also huge nowadays. :( (The language itself, that is, not counting the 500K+ third-party libraries that it has nowadays.)
As for the Camel book, what I liked about it is that it explains why Perl is the way it is... the underlying philosophy. Once you know that, it starts making a lot more sense. You usually didn't get that with books like "Learn Perl in 21 days" or something.
As for the Camel book, what I liked about it is that it explains why Perl is the way it is... the underlying philosophy. Once you know that, it starts making a lot more sense. You usually didn't get that with books like "Learn Perl in 21 days" or something.
I get that. My gold standard for technical writing was (and mostly still is), the C programming language by K&R. Brief, to the point and not missing anything. It's what I expected from the Perl book but didn't get.
You will look up how to interpret `match` whenever you see it and you will like it.
One way to do things? Pfffft.
One way to do things? Pfffft.
Oh, it lost that a long time ago. (e.g. string formatting methods).
However, this was around 2005 or so and at the time, Python was significantly smaller (conceptually) than Perl. Atleast to me.
However, this was around 2005 or so and at the time, Python was significantly smaller (conceptually) than Perl. Atleast to me.
There's always Perl Cookbook if you need somewhere to look up solutions.
regarding 2., are you sure you're referring to the Camel book and not the Llama book? To me, Programming Perl (Wall, Camel) is closer in spirit to K&R than Learning Perl (Schwartz, Llama)
Ah.. I'm not sure now.. It was a long time ago and i can't really remember which it was. The name Schwarz is familiar. Maybe it was that.
[deleted]
I decided to switch from sed to Perl for all my string replacements and at the time it made my life so much easier! Eventually I started expanding my Perl use to a few lines of code at the time, and now I write a few larger (100+ LOC) scripts in it a year.
Funny how my personal journey matches the story of Perl back in the 80s: it was born to replace more primitive tools.